Open allen opened 13 years ago
If the HTML Purifier is abstracted as an event filter, then backend users can still paste in HTML that won't be purified.
I think that's why it was included in this formatter and not as a separate extension.
(The most recent release of Purifier is 4.4.0, so we are a little outdated)
Good point. Existing issues still stand though.
The only solution I can think of that could solve all the above mentioned problems would be to allow text formatters to chain (Markdown -> HTML purifier) but that brings architectural changes and raises questions that fall outside the scope of this particular issue at hand.
If event filter is definitely not the answer, then the best course of action is to keep it as-is and look at a proper alternative that we can implement down the line.
Why don't you implement purification as a general add-on: it could be a separate extension that - if enabled - purifies the values of all backend textareas via delegates. This way purification would work with any text formatter. Furthermore it could be offered as event filter for front-end interactions.
As we leave lots of things to the front end developer, why not purification too?
@nilshoerrmann: There could be situations, albeit rare, where certain textareas shouldn't be passed through the HTML purifier, i.e. fields that stores raw text or snippets of JS/CSS code. Do you think this warrants the extension to be selective of the textareas that the purifier will apply to?
@designermonkey: Not exactly sure what you're asking. In any of the scenarios: as part of the Markdown extension, as an event filter, or as a generic extension), it's all left up to the developer's own devices.
This is a continuation of the discussion here: http://symphony-cms.com/discuss/thread/63/3/
The inclusion of an external library causes several issues:
The solution is to abstract HTMLPurifier into an event filter, rather than having this included as part of the extension.