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

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