Status of Wysiwyg support in Drupal
Patch Spotlight
Write documentation/handbook pages
- Provide a tutorial for installing Wysiwyg API + an editor (including screenshots).
- Extend handbook pages with a FAQ.
Donate
To complete the big picture, this project requires a large amount of community funding. If you want to see better support for client-side editors/WYSIWYG in Drupal or have a project/client that demands it, consider to contribute some bucks. Remember: Drops make an ocean.
Other ways to contribute:
Write a review · Improve handbook pages · Help other users · Review/test patches · Improve Drupal core
Improvements to core
public
group: Wysiwyg
In progress
- Remove the teaser splitter: Yes, we can.
- Default input format per role and make access to filters first class permissions: Simplifies the input format configuration by moving input format access permissions to the regular user permissions form.
- Filter options based on CSS attributes, not just HTML tags: Allow to configure HTML attributes in HTML filter to allow and/or strip only certain tag attributes.
See also all issues tagged with 'wysiwyg' and 'FilterSystemRevamp'.
Todo
- Limit available input formats by "type of widget" used (node type body, comment, block, etc)
- Bring consistency into how we apply formats and provide more format support where it is missing
- Add context for check_markup(): For example, Inline API needs context about the piece of content that is filtered. If a field in a node is filtered, the node should be passed to the filter, so inline macros can be expanded to display a file attachment download link for an upload attached to the passed in node. The same with users, comments, aso. so this is not limited to nodes.
Fixed
- Move custom help settings to blocks: Allows to control/add custom help blocks to arbitrary pages (including input format support like any other custom block).
- Text format widget: Redesign the input format widget.
- Allow behaviors to detach from AHAH/AJAX contents: Adds Drupal.detachBehaviors(), so (not only) Wysiwyg API can invoke editors to save contents back into form elements before a form is submitted via AJAX/AHAH.
- Textarea with input format attached: Allow Wysiwyg API to identify input format enabled textareas via the FAPI property #input_format.
- Make input formats reorderable
- Break out HTML escaping filter to make non-HTML input formats (instantly) recognizable
Wiki pages: Issue lists
Improvements to Wysiwyg API
public
group: Wysiwyg
In progress
- Allow to configure advanced editor settings: Move most of the current profile configuration form into a callback function for each editor.
- Allow to sort editor buttons: Provide a jQuery based UI to sort editor toolbar buttons via drag'n'drop.
- Handle compatibility of (native) editor plugins to expose certain plugins for certain editor versions only.
- Implement Drupal.detachBehaviors() into Chaos Tool Suite to support editors in dynamic AJAX/AHAH contents (CCK "multiple" fields, Panels, etc) and add a dependency on CTools.
Todo
- Integrate with input filters to limit available editor commands, buttons and plugins to allowed markup for an input format.
- Integrate with Inline API to allow editing of rich content in Wysiwyg Editors, provided by plugins that interact with Drupal core and contrib modules.
- Performance optimization.
- Upgrade to Drupal 7.
- Advanced code review.
- Move Wysiwyg API into Drupal core. (Needs discussion and consensus about to which extent)
Fixed
- Use a separate location for editor libraries in the filesystem to make module updates easier.
- Rewrite editor plugin API: Provide a generic plugin for each client-side editor exposing interaction hooks for Drupal contrib modules.
- Disable editor for specific textareas: Allow to configure input formats for certain content-types or other criteria.
- Associate editors/profiles with input formats: Display editors on configured input formats only.
- Replace wysiwyg_editor.module with wysiwyg.module: Move module functions from wysiwyg_editor.module into wysiwyg.module; drop wysiwyg_editor.module.
- Attach client-side editors to input format enabled textareas only: Bind client-side editors to input formats instead of textareas; introduce JS support to switch editors; re-attach Drupal core behaviors to a textarea if no editor is attached.
- Add support for TinyMCE 3.x and FCKeditor.
- Rewrite Wysiwyg API: Support multiple editors and editor versions
- Add hook_wysiwyg_plugin() to allow contrib modules to add plugins/buttons for editors (f.e. for Inline API, Image Assist, Link to content, IMCE, Paging, etc.)
- Refactor TinyMCE module to use jQuery, and fork into Wysiwyg module
Wiki pages: Issue lists
Ideas, battle-plans, background info on Planet Drupal
public
group: Wysiwyg
In reverse chronological order:
- List of current editor integration modules in contrib
- Gábor Hojtsy: Do not let WYSIWYG editors rule our textareas!
- Fields and places in Drupal core that should support input formats
- Comparison of contrib modules to control input formats
- sun's vision for handling embedded/inline content and Wysiwyg in Drupal
- Gábor's battle plan on Wysiwyg support
Wiki pages: Background info
