Poll: useful 'escape' transforms

etc · 2017-12-21 16:46:56

Bloke wrote #308388:

For example, if an Italian editor wrote an article and inadvertently put into a custom field the value 1.234.567,89 (meaning: one million, two hundred and thirty four thousand, five-hundered and sixty-seven point eight nine)

That would be a bad idea, even if we enable localized (here Italian) numbers input parsing. Suppose that an American author on the same site has put 1,234. Does it mean 1234 or 1.234 now, how to tell? An extra parameter is needed, and this is more <txp:evaluate /> or plugins territory.

michaelkpate · 2017-12-21 16:56:59

I googled and found LC_MONETARY mentioned in this comment.

etc · 2017-12-21 17:38:06

michaelkpate wrote #308390:

I googled and found LC_MONETARY mentioned in this comment.

Yes, but it requires an extra parameter '%.2n' (impossible in escape atm), unless we decide that $666 is the only valid format in US and get blamed for Russian interference :-)

etc · 2017-12-21 17:42:54

Bloke wrote #308388:

I was curious about your use of str_replace().

It is applied to floatval() which does not output thousand separators (afaik), but localizes the decimal separator.

Bloke · 2017-12-21 17:45:22

etc wrote #308389:

That would be a bad idea, even if we enable localized (here Italian) numbers input parsing.

Yes. bad idea. But we’ve just opened up this Bad Place because we’ve allowed people to use the admin-side UI in their own language, which may be different from the front-end language! Caveat utilitor…

Suppose that an American author on the same site has put 1,234. Does it mean 1234 or 1.234 now, how to tell?

Exactly. That’s why I was curious about your str_replace() usage. If you replace commas with dots when formatting number, we’re essentially stripping off the “decimal” part of any value expressed in a European format. Are we? Or have I misinterpreted what it does?

Should we leave it alone and let the risk lie with the site admins that their authors might use a variety of number formats (and it’s therefore up to the admin to enforce a common input number format so that the output of such transforms is guaranteed).

As it stands, with us stripping out commas from the strings, could that inadvertently alter the output? Or is the str_replace() there to try to ensure consistent input to the NumberFormatter?

Bloke · 2017-12-21 18:28:20

etc wrote #308392:

It is applied to floatval() which does not output thousand separators (afaik), but localizes the decimal separator.

Ah, right. That explains it.

etc · 2017-12-21 20:49:43

Bloke wrote #308393:

Should we leave it alone and let the risk lie with the site admins that their authors might use a variety of number formats (and it’s therefore up to the admin to enforce a common input number format so that the output of such transforms is guaranteed).

I think we should strongly advise the site admins to use the decimal-point-only-no-thousand-separator format if they intend doing some maths (arithmetic, comparison) with numbers. They will still be able to output them as they wish.

phiw13 · 2017-12-29 00:54:20

Putting this here as an example of “weird things can happen”. Be careful.

escape="textile, p" can sometimes have crazy consequences. Take this string, input in an image caption field: Bells for the South Side CD cover (ECM)

In a TXP form (for an image gallery, code trimmed to the minimum):

<a href="<txp:image_url />" class="image-lightbox" data-caption="<txp:image_info escape='textile, p' />">

output:

<a href="http://txptest.dev/images/12.jpg" class=" image-lightbox" data-caption="Bells for the South Side cover (<span class="caps">ECM</span>)">

Pay attention to the sequence of " in the code above [1]…

Two work arounds:

use single ' quotes for the data-attribute: data-caption='<txp:image_info escape='textile, p' />'
I think for my use cases, this will suffice: escape="textile, p, span".

PS – I never liked that habit of Textile to wrap sequences of 3 or more capital letters in a <span />.

¹ the browser closes the data-caption attribute after the opening " of class="caps", then threats the word caps as an attribute. The rest is rendered as content of the @<a />.

jakob · 2018-07-18 15:59:32

Earlier in this thread, there was mention of escape="strip_tags" but couldn’t find it in the docs, only the reference to “some tag”. After looking at the code, it seems it is there but is now escape="tags". Is that correct?

If so, it needs adding to the docs on tag escaping. I can submit a PR for that if you like.

This neatly consigns etz_striptags to the list of no longer needed plugins.

etc · 2018-07-19 14:37:25

jakob wrote #313065:

… it seems it is there but is now escape="tags". Is that correct?

If so, it needs adding to the docs on tag escaping. I can submit a PR for that if you like.

Yes, please. Thanks!

And the poll is still open for the next round of plugins deprecation.

jakob · 2018-07-20 09:42:45

Thanks for the clarification.

PR submitted and already online (thanks Phil!): tag escaping.

Textpattern CMS

Textpattern CMS support forum

#61 2017-12-21 16:46:56

Re: Poll: useful 'escape' transforms

Bloke wrote #308388:

#62 2017-12-21 16:56:59

Re: Poll: useful 'escape' transforms

#63 2017-12-21 17:38:06

Re: Poll: useful 'escape' transforms

michaelkpate wrote #308390:

#64 2017-12-21 17:42:54

Re: Poll: useful 'escape' transforms

Bloke wrote #308388:

#65 2017-12-21 17:45:22

Re: Poll: useful 'escape' transforms

etc wrote #308389:

#66 2017-12-21 18:28:20

Re: Poll: useful 'escape' transforms

etc wrote #308392:

#67 2017-12-21 20:49:43

Re: Poll: useful 'escape' transforms

Bloke wrote #308393:

#68 2017-12-29 00:54:20

Re: Poll: useful 'escape' transforms

#69 2018-07-18 15:59:32

Re: Poll: useful 'escape' transforms

#70 2018-07-19 14:37:25

Re: Poll: useful 'escape' transforms

jakob wrote #313065:

#71 2018-07-20 09:42:45

Re: Poll: useful 'escape' transforms

Board footer