Thread

We ran into the same issue in this thread ( http://ellislab.com/forums/viewthread/150381/ ) when we wanted to add some elements to the safe HTML list.

The fix for this can be applied around line 615 in the EE_Typography.php file (we have a few hacks in place). Rather than replacing the opening and closing tags at once, split them into two regular expressions so that nested elements of the same type don’t get skipped over. We ran into this issue with nested unordered list elements.

// $str = preg_replace("#<".$val.">(.+?)</".$val.">#si", "[$val]\\1[/$val]", $str);
$str = preg_replace("#<".$val.">#si", "[$val]", $str);
$str = preg_replace("#</".$val.">#si", "[/$val]", $str);

Hi Benjamin Kohl,

Thanks for the solution! I don’t see this reported in the Bug Tracker. Can you give me some details to replicate, or would you like to file the report?

Cheers,

Hi Dan,

I’m not really sure this is a bug. This problem only seems to arise when other HTML elements are added to the safe_encode and safe_decode arrays in the EE_Typography class, which is a core hack anyway. Also, we found that the code I provided was only part of the solution because it broke <a> tag parsing which was normally handled by a regular expression that was a few lines below the change we made.

In the end, we disgarded the hack provided above and added a function to the “allow all html” channel preference logic that stripped tags like script, embed, object, etc. It also removed HTML attributes like onclick, onfocus, onblur, etc. That way, we avoid modifying those existing regular expressions that were dependent upon the order they were being called.

Hey Benjamin,

Thank you for the update.

So where are things now? Are you pass this issue?

Cheers,

Yes, thanks.

Hey Benjamin,

Awesome!

If you need anything else, please just let me know by opening a new thread.

Cheers,