Symphony.

In Symphony 2.0.7, ampersands in input fields will be

• saved to the database as HTML encoded ampsersands (&)
• displayed as HTML encoded ampsersands (&) in the input field (see screenshot)

Both is wrong.

Attachments:

Bildschirmfoto 2010-01-02 um 17.15.54.png

We had long discussions over this. The biggest problem with the input field pre-2.0.7 was that is did not validate the data during save, but instead encoded values when rendering to the XML. The issue here is you have no feedback in the admin letting you know that the data you’ve just entered will be different when it hits the front-end. It could be as simple as a & becoming & (like it should), or if Symphony cannot correct it, the entire string gets HTML encoded (an all or nothing approach). The behaviour was confusing and inconsistent (especially if you then compare it to how a text area works).

In 2.0.7, the data is validated and pre-processed when saving in the admin. There are 3 steps in the pre-processing. 1) Validate as is, 2) Encode just ampersands, 3) Encode the entire thing. It is also inline with how the text area field works and removed some other inconsistencies.

What you see in the admin, is what you get on the front-end. No more unexpected changes. Here is an example of what I mean:

2.0.6

• String: One & Two <p>I don't want this encoded thanks...</p>
• After Saving (as it appears in the admin): One & Two <p>I don't want this encoded thanks...</p>
• XML: One & Two <p>I don't want this encoded thanks...</p>

2.0.7

• String: One & Two <p>I don't want this encoded thanks...</p>
• After Saving: One &amp; Two <p>I don't want this encoded thanks...</p>
• XML: One &amp; Two <p>I don't want this encoded thanks...</p>

In my mind, the way 2.0.7 handles text is much better.

Does this allow something like:

I like bacon > I like cheese

Or even

No more <b> tags!

Both are invalid XML…

Also, does this mean when exporting data into CSV etc (extracting using raw SQL rather than a DS->XML->XSLT) that ampersands will be HTML encoded?

While I think the XML result in 2.0.7 is much better, displaying ampersands as & after saving looks like an error to anybody besides developers. No one besides us knows what this cryptical letter thing means … so authors will think something is broken.

… so authors will think something is broken

That’s what I think.

I agree that authors would like to see what will get on the front-end, but: The latter is the text in the browser (not in the HTML code).

Does this allow something like: … Both are invalid XML…

It will, however the string will be HTML encoded.

No one besides us knows what this cryptical letter thing means

Good point.

Also, does this mean when exporting data into CSV etc (extracting using raw SQL rather than a DS->XML->XSLT) that ampersands will be HTML encoded?

Hmm, you’re right. That’s not really ideal.

I’ll chat with the team. I am happy with how Symphony handles text input data as of 2.0.7, but I think the point at which it is doing the processing will need to change slightly.