[#6850] htmlspecialchars_decode in cbcontentbot.php

In line 151 in the cbcontentbot.php plugin, it's doing an htmlspecialchars_decode() on the entire text of the content. So if there is any markup in the content that relies on encoded text, for example tooltips ...

... that get decoded into ...

... which breaks the markup.

I'll admit this is a very corner case, but happens to affect some users of the extension I author (Fabrik). And in general, the assumption would have to be that if you are processing HTML which is being sent to the browser, you should assume that if anything is HTML encoded, it should stay that way.

Thanks for reading! And thanks for a long standing awesome extension.

-- hugh

We don't have a choice. Joomla and various extensions fiddle with the encoding (which causes us to have to fiddle with the encoding, lol) so we have to reverse it or we can't match our substitution shortcode. Have added a feature ticket to see if I can get a workaround implemented that avoids messing with the original markup.

forge.joomlapolis.com/issues/6850

Are you sure it's CB causing this? I've tested your example in a Joomla article with all of our content plugins disabled and it still gets mangled. I'll need an example that I can reliable reproduce in Joomla for me to test potential fixes. In Joomla articles at least our content plugins work fine with and without the decode and don't really recall what situation required us to add it as its been so long.

Thanks you for the prompt responses.

In Joomla articles at least our content plugins work fine with and without the decode and don't really recall what situation required us to add it as its been so long.

Lol, I know that feeling.

Are you sure it's CB causing this?

Yup, positive. I've tested on the user's system, and if I remove the htmlspecialchars_encode() from that line, the markup is good, and I've never run in to any other issues with our markup getting un-encoded.

I'll be doing some integration work with CB soon, as I need to rewrite the Fabrik plugin for it, so I'll take a closer look when I have the code out on the slab in the lab.

One thing that confuses me is that the user is positive they don't use the {cb} tag anywhere, so I'm puzzled as to how it reaches line 151 in the first place.

-- hugh

One thing that confuses me is that the user is positive they don't use the {cb} tag anywhere, so I'm puzzled as to how it reaches line 151 in the first place.

It should only ever reach that if they've a substitution shortcode or {cb} tag present in their content. There is an exclude context parameter though so if you set a specific context like com_frabrik.field when using Joomlas content prepare API you can set that in our plugins parameters so it won't run for that context at all as a workaround for time being.