Answers.Body: <p>Redactor fields are not meant to process twig both for security reasons (as they can be changed by any user) and for usability (you cannot expect authors to remember / preserve twig tags).</p>
  
  <p>In your specific example, the site url is probably not necessary (starting a URL with / will link to the current domain just fine) - so you would not actually need twig.</p>
  
  <p>However I cannot think of one good reason to build a menu in a redactor field. I would either include it directly in the page templates (.twig files) or use a matrix field as a <a href="https://nystudio107.com/blog/creating-a-content-builder-in-craft-cms" rel="nofollow noreferrer">content builder</a>. </p>
  
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-04-02T14:04:05.047Z
Answers.Text: Yeah, it isn't clean, but it's actually part of data we are migrating over from client's older project.
Answers.UserDisplayName: Davina Leong
Answers.ContentLicense: CC BY-SA 4.0
Answers.CreationDate: 2019-04-02T07:45:26.430Z
Answers.LastActivityDate: 2019-04-02T07:45:26.430Z
Answers.UserDisplayName: Udo
Body: <p>I have a redactor field whose HTML contents contain links to other parts of the website.</p>
  
  <p>How do I render variables located in the HTML content of a Redactor field in Twig?</p>
  
  <p>Sample redactor content:</p>
  
  <pre class="lang-html prettyprint-override"><code>&lt;ul&gt;
    &lt;li&gt;&lt;a href="{{ siteUrl }}about"&gt;About&lt;/a&gt;&lt;/li&gt;
    &lt;li&gt;&lt;a href="{{ siteUrl }}contact"&gt;Contact&lt;/a&gt;&lt;/li&gt;
  &lt;/ul&gt;
  </code></pre>
  
  <p>In output of this results in the braces being encoded:</p>
  
  <pre class="lang-html prettyprint-override"><code>&lt;ul&gt;
    &lt;li&gt;&lt;a href="%7B%7B%20siteUrl%20%7D%7D/about"&gt;About&lt;/a&gt;&lt;/li&gt;
    &lt;li&gt;&lt;a href="%7B%7B%20siteUrl%20%7D%7D/contact"&gt;Contact&lt;/a&gt;&lt;/li&gt;
  &lt;/ul&gt;
  </code></pre>
  
  <p>But I want it the output to be whatever <code>siteUrl</code> is. Eg on <strong>localhost</strong>:</p>
  
  <pre class="lang-html prettyprint-override"><code>&lt;ul&gt;
    &lt;li&gt;&lt;a href="http://localhost/about"&gt;About&lt;/a&gt;&lt;/li&gt;
    &lt;li&gt;&lt;a href="http://localhost/contact"&gt;Contact&lt;/a&gt;&lt;/li&gt;
  &lt;/ul&gt;
  </code></pre>
  
Tags: <templating><redactor><string>
Title: String interpolation in Redactor
ThreadText: # String interpolation in Redactor
  
  (Asked by: username_0 on 2019-04-02)
  
  I have a redactor field whose HTML contents contain links to other parts of the website.
  
  How do I render variables located in the HTML content of a Redactor field in Twig?
  
  Sample redactor content:
  
  ```html
  <ul>
    <li><a href="{{ siteUrl }}about">About</a></li>
    <li><a href="{{ siteUrl }}contact">Contact</a></li>
  </ul>
  
  ```
  
  In output of this results in the braces being encoded:
  
  ```html
  <ul>
    <li><a href="%7B%7B%20siteUrl%20%7D%7D/about">About</a></li>
    <li><a href="%7B%7B%20siteUrl%20%7D%7D/contact">Contact</a></li>
  </ul>
  
  ```
  
  But I want it the output to be whatever `siteUrl` is. Eg on **localhost**:
  
  ```html
  <ul>
    <li><a href="http://localhost/about">About</a></li>
    <li><a href="http://localhost/contact">Contact</a></li>
  </ul>
  
  ```
  
  **Tags:** templating, redactor, string
  
  
  ---
  
  ## 1 answers
  
  ### Answer by username_1 on 2019-04-02. Score: 1 | Accepted answer
  
  Redactor fields are not meant to process twig both for security reasons (as they can be changed by any user) and for usability (you cannot expect authors to remember / preserve twig tags).
  
  In your specific example, the site url is probably not necessary (starting a URL with / will link to the current domain just fine) - so you would not actually need twig.
  
  However I cannot think of one good reason to build a menu in a redactor field. I would either include it directly in the page templates (.twig files) or use a matrix field as a [content builder](https://nystudio107.com/blog/creating-a-content-builder-in-craft-cms).
  
  > **Comments:**
  > **username_0**: Yeah, it isn't clean, but it's actually part of data we are migrating over from client's older project.  
  
  ---
  
  