entities in caption

colak · 2016-09-28 17:08:45

In the latest 4.6 release html entities are replaced with their glyphs upon save. ie č is replaced with a Č. I remember we had a similar problem with the custom fields a few years back. I am also not certain if this bug was there on the previous release.

> Edit: Found the previous bug here

Edited to correct my self that it is not the entities but the numeric character references which are replaced.

Last edited by colak (2016-09-29 05:27:50)

etc · 2016-09-29 08:11:36

Hi Yiannis,

I can fix it (and we should fix it, actually), but then people that used, say, non-breaking spaces in captions will get the literal  . Do we care? On the other hand, these   are currently converted into simple spaces on the second image save anyway…

colak · 2016-09-29 08:26:55

etc wrote #301812:

Hi Yiannis,

I can fix it (and we should fix it, actually), but then people that used, say, non-breaking spaces in captions will get the literal  . Do we care? On the other hand, these   are currently converted into simple spaces on the second image save anyway…

Would this also happen with the ampersands? ie would & be converted into & in the back end and by extension to the front end which would result in non valid html?

etc · 2016-09-29 08:42:57

Currently & is converted into &, yes. With the fix I propose it would stay as is.

colak · 2016-09-29 08:51:05

etc wrote #301814:

Currently & is converted into &, yes. With the fix I propose it would stay as is.

So as to clear things up:) The html encodings will remain visible in the back end but they will appear properly in the front end. The   being an exception. Right?

etc · 2016-09-29 09:04:38

No :-) They will all appear the same on front and back ends. Unless we patch <txp:image_info type="caption" /> too. But then you won’t be able to display a literal   in captions. Weird!

colak · 2016-09-29 11:03:44

etc wrote #301816:

… Unless we patch <txp:image_info type="caption" /> too.

Then this is what should be patched then:) The whole issue I raised was to achieve html validity.

etc · 2016-09-29 12:59:20

So, after some tests:

Image caption and file description transform (after few saves) & into &, both public and admin side;
Article/link descriptions preserve &, both sides;

Needed behavior: keep & in admin-side textareas, but output it as & public side?

phiw13 · 2016-09-29 13:14:39

If the page uses UTF-8 there is rarely, if ever, a need to use entities in the source code. And you should never use anything then UTF-8 else nowadays. > and < are probably the two exceptions, & could be considered an edge case.

colak · 2016-09-29 14:11:13

phiw13 wrote #301829:

If the page uses UTF-8 there is rarely, if ever, a need to use entities in the source code. And you should never use anything then UTF-8 else nowadays. > and < are probably the two exceptions, & could be considered an edge case.

I use utf-8 but I had to use entities to validate this page which is generated purely from the images interface. Check the publication on the top where you have &, ä, č, Ç, and ğ. The strange thing is that on first save (using entities) all validates ok but on returning to an image, to edit it again, the validation goes out of the window unless I re-write all the entities again.

etc · 2016-09-29 21:38:29

colak wrote #301835:

The strange thing is that on first save (using entities) all validates ok but on returning to an image, to edit it again, the validation goes out of the window unless I re-write all the entities again.

This should be fixed in 4.6.1, but now to output č as č public side, you’ll need to call <txp:image_info type="caption" escape="" /> (note escape="" attribute).

colak · 2016-09-30 06:03:17

Hi Oleg, I have the escape attribute already

<figcaption class="grid_17 prefix_1">
<txp:image_info type="caption" escape="" />
</figcaption>

Textpattern CMS

Textpattern CMS support forum

#1 2016-09-28 17:08:45