For the solution see Edit 2 below

I've used the Builder plugin to create front-end text panels from back-end input.

The text is in MySQL text columns (length 65535).

I started by using plain text ('Text'/'Text area') input boxes (controls), but then decided to use 'Rich editor' so that I can have bold text, links, etc.

Using 'Rich editor' the output ( from eg {{ text.intro }} ) contains html tags:

<p>Some text <strong>some bold text</strong> some more text.</p>

When I copy the text from the chromium inspector and paste it into a text editor, it displays as:

<p>Some text <strong>some bold text</strong> some more text.</p>

Which is probably why the tags are not being interpreted by the browser but are simply displayed.

I can remove the tags by filtering through striptags: {{ text.intro|striptags }}

But this removes all the wanted formatting tags such as <strong>

Reading Non-english characters not displaying properly in pages made me think maybe something is wrong with my MySQL collation settings? Collation: utf8_unicode_ci

Looking at the database with Adminer shows that the tags (<p> etc) are in the database -- and there are a few unwanted   and <span>&nbsp;</span> in there too.

The 'bug' has changed since updating from Build 318 to Build 346:

In Build 346, when a text field is empty it displays as empty.

In Build 318, when I 'emptied' a text field in the back-end Builder form, the display in the browser was <p></p> which, when copied from chromium inspector and pasted into a text editor, turned out to be <p>&#8203;</p> (​ is the zero-width space character).

This concurs with item 1) in this question from @Newbie1 : Simple newbie questions - Editor empty tags and snippets

What am I/we doing wrong?

Edit 1

It occurs to me that the only problem is that the tag angle brackets are being injected into the html of the final web page as < and > respectively. Other than that, the text is correct.

So the question is, what is causing the tag brackets to be 'converted'?

Is it,

1. the Builder Rich editor,
2. some other part of the process of passing the text to the database,
3. a conversion being performed within the database,
4. some part of the process of getting the 'data' from the database,
5. the process of rendering the text data in the html/php page.

Edit 2

It turns out to be a newbie error.

The < and > are effectively escaped characters -- they cause <p>, for example, to be seen by the browser as <p> and hence not interpreted as an html tag.

The solution to the overall problem is to be found here:

October > Documentation > Filters > |raw

Output variables in October are automatically escaped, the |raw filter marks the value as being "safe" and will not be escaped if raw is the last filter applied.

So, replacing {{ text.intro }} with {{ text.intro|raw }} solves the problem.

Last updated 8 years ago

Thanks, it has helped me fix the same error on my site

Last updated 4 years ago