Note: This is a braindump issue right now.
- Two phases: Text processing (e.g., DOMDocument) and filtering (processor-specific).
- 1 format has exactly 1 processor + 0-n filters.
- Assume HTML for output, but not for input.
- HTML/DOM processor eliminates HTML corrector filter. (also: HTML5 eliminates or will eliminate HTML corrector filter.)
- Other text processors (e.g., markdown) have their own parsers and security filters.
- Convert URL + Local image + line-break filters into DOM-based filters, eliminating all the buggy PCRE nightmare.
- Text processor has settings, each filter can have settings.
- Simplify format settings UI into vtabs categories à la "Security", "Macros/Replacements", "Enhancements", etc.
- Make processors and filters available outside of Filter module? (e.g., Text field summary, drupal_html_to_text())
Text processors in core:
- HTML/DOM
- Plain-text (all HTML escaped)
Add-on gimmicks:
- Add a HTML/DOM setting to control PHP DOM $formatOutput property (producing pretty HTML).
Comments
Comment #1
wim leersThis is essentially what's been said in #807996: [meta] Input filters and text formats, and specifically in #807996-19: [meta] Input filters and text formats (in terms of underlying architecture, not in terms of UI).
I'd love to see this happen. Seems like D9 material though.
Comment #14
smustgrave commentedWith almost 12 years of inactivity wonder if this is still a needed task?
Comment #15
wim leersIt kind of is still relevant. It would help make the filter system much more robust, because it'd no longer be up to the site builder to configure filter plugins to run in the exact right order.
Comment #17
smustgrave commentedSo probably should be re-opened?
Comment #18
smustgrave commented