Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reconsider the inclusion of HTMLPurifier #6

Open
allen opened this issue May 30, 2011 · 5 comments
Open

Reconsider the inclusion of HTMLPurifier #6

allen opened this issue May 30, 2011 · 5 comments

Comments

@allen
Copy link

allen commented May 30, 2011

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:

  1. The extension is subject to an external library's release schedule. Incidentally the version of HTMLPurifier in the current version of the markdown extension is outdated.
  2. HTMLPurifier is a generic text filtering library. Including it as a submodule (I am using this term generically and not in terms of git) means other text formatter extensions that want to use the same library will have to include their own version.
  3. HTMLPurifier is very large, bigger than Symphony's core itself.

The solution is to abstract HTMLPurifier into an event filter, rather than having this included as part of the extension.

@brendo
Copy link
Member

brendo commented Mar 6, 2012

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)

@allen
Copy link
Author

allen commented Mar 6, 2012

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.

@nilshoerrmann
Copy link

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.

@designermonkey
Copy link
Member

As we leave lots of things to the front end developer, why not purification too?

@allen
Copy link
Author

allen commented Jun 11, 2012

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants