Posted by Wim Leers on
adds support for WYSIWYG editing of core text fields! A requirement of that issue is to add two new capabilities to the filter system:
- Have check_markup() run some, but not all, text filters when sending text to a WYSIWYG editor. In particular, we want to run all filters that protect against XSS exploit or otherwise limit the allowed HTML. But we do not want to run token expansion or similar kinds of transformation filters, instead leaving it up to client-side WYSIWYG plugins to handle those.
- Enable the Aloha module (or alternate contrib module) to determine when to not enable WYSIWYG editing for a text field. For example, some filters (e.g., Markdown) are (to varying degrees) incompatible with WYSIWYG editing.
This issue is about addressing the Filter system changes needed to support the above.
With great help and inspiration from, this patch proposes adding a 'type' key to hook_filter_info() information that must be set to one of the following:
- FILTER_TYPE_MARKUP_LANGUAGE: The filter converts something that's not HTML to HTML in a way that is not compatible with WYSIWYG editing.
- FILTER_TYPE_HTML_RESTRICTOR: The filter restricts the HTML allowed, for example, to protect against XSS.
- FILTER_TYPE_TRANSFORM_REVERSIBLE: The filter performs a transform for which a WYSIWYG plugin exists to perform the same transformation (and its reverse) client-side. For example,
<img data-caption="Druplicon">may be (reversibly!) transformed to
- FILTER_TYPE_TRANSFORM_IRREVERSIBLE: The filter performs a transform for which a WYSIWYG plugin does not exist to perform the transformation client-side (especially, the reverse of it); instead, the WYSIWYG editor displays the unfiltered text. For example, Token Filter.
User interface changes
No direct UI changes.
- New function
- New optional $filter_types_to_skip parameter in
- New required key 'type' in
- A design goal for this issue was to classify filter types as generically as possible, rather than focus on just a WYSIWYG (or particular WYSIWYG editor) use case (see #37). However, a perfect decoupling of type from use case has not been achieved. Whether a filter is FILTER_TYPE_MARKUP_LANGUAGE, FILTER_TYPE_TRANSFORM_REVERSIBLE, or FILTER_TYPE_TRANSFORM_IRREVERSIBLE depends on the desired WYSIWYG experience, and the WYSIWYG plugins available (see #38). Other ways of classifying filters were explored in this issue, but none were considered substantially better.
- When using a WYSIWYG editor, any filter of type FILTER_TYPE_HTML_RESTRICTOR runs both on "output" (from server to browser) and on "input" (by the WYSIWYG editor prior to submitting the form). This results in data loss (if disallowed HTML is in the text to begin with, the process of editing it in WYSIWYG strips it from what is then saved back). But, we think that losing disallowed HTML is a reasonable and logical consequence of WYSIWYG editing.
|#58||drupal_wysiwyg-in-core-round-one-1782838-58.patch||14.47 KB||Wim Leers|
|PASSED: [[SimpleTest]]: [MySQL] 42,800 pass(es).|
|#45||1782838-45-wysiwyg-round-one.patch||14.09 KB||Lars Toomre|
|PASSED: [[SimpleTest]]: [MySQL] 42,616 pass(es).|
|#45||interdiff-1782838-44-45.txt||5.5 KB||Lars Toomre|
|#44||drupal_wysiwyg-in-core-round-one-1782838-44.patch||14.31 KB||Wim Leers|
|PASSED: [[SimpleTest]]: [MySQL] 42,630 pass(es).|