WYSIWYG

Dries said (again) in his State of Drupal keynote this past week that a whole lot of people want WYSIWYG editors in Drupal. He also highlighted FCKeditor as the most popular one used for this job in the Drupal community (based on call-home data from Update Status module). So you'd say this is just too easy, move FCKeditor to core and we are done. Well, going the simple and quick way would just alienate those from RTEs (another nice acronym for these editors), because these editors are just too aggressive when it comes to pushing themselves to your face.

The assumption in these editors is to treat all textareas as fields with HTML input by default, so you'll obviously need the HTML editor on them. But this is not the case. In previous times, if you installed an RTE, and went to a block's configuration page, the textarea where you can provide a list of paths on where the block will show/hide was taken over by the RTE. Through time, the RTE authors realized this is a problem and built in tools to limit their reach. If you look FCKeditor's profile editing interface (image on the right), you'll find settings to exclude certain form item IDs from FCKeditor's work. But who knows the form IDs? Well, FCKeditor authors built a tool which tells you about the form IDs on forms, eg. on the block configuration page, it says: The ID for excluding or including this element is: edit-pages - the path is: admin/build/block/configure/user/1. Then if you need to modify your configuration on this field, you need to remember these values, go over to the linked "excluding or including" page and alter the list of items there.

There are a couple of flaws with this approach:

• End users need to deal with (internal) form item IDs to configure their site for forms which are not covered by the default settings.
• What guarantees that "edit-pages" will not be used as a form ID for HTML input in another form? Nothing. If we block it out, we block it out in all forms.
• Blacklisting keeps textareas open to FCKeditor by default, so if a contrib module comes requiring text input in a field, there is no way to tell RTEs not to process that field, the user will face the pushy RTE and submit a bug against the contrib module such as http://drupal.org/node/293502 (and will get users hack as hell).
• If this all was not enough, FCKeditor also has a simplified toolbar view, which is used for text input using the filtered XSS admin processor (when input format is not selected, but some HTML is still allowed). Again end users set up which textareas are using this method (beyond some defaults included). How they get to know that? Well, trial and error, or they need to look into the code.

All these ugly hassles for the end user, while we programmers know exactly that input from a textarea will be plain text (eg. email text, a list of paths), passed through filter XSS admin or filtered via one of the input filters set up. Not only that, but we know if a textarea is passed through input filters and the particular input filter used escapes HTML, it is pointless to display an RTE for HTML. So it is not only the page the textarea was displayed on, it is not only the ID of the textarea, it is also the properties of the selected input format for that textarea (when applicable) which defines whether FCKeditor should be there or not.

These are all things programmers can tell Drupal about without any user interaction, completely removing these settings and making WYSIWYG editing really seamless for the user. How do we tell Drupal what type of input is on the textarea? Well, we tell it to use a specific format. There are two competing proposals on how this should work, both in the issue: Textarea with input format attached. If you care about WYSIWYG editors in Drupal core (for Drupal 7), please help do quality reviews and provide feedback on the approaches proposed. This is a prerequisite to making RTEs integrate seamlessly to Drupal.

As I explained in an earlier blog post, I was tasked by Acquia (specifically Dries) to identify and propose fixes to issues around integrating visual content editors (WYSIWYG = What You See Is What You Get or RTE = Rich Text Editor). Instead of rushing to select an RTE, the focus of my roadmap is to solidify input format support in Drupal so that integrating a visual editor becomes a peace of cake at the end hopefully.

Textarea and format identification

Drupal is very flexible and this makes integrating an RTE harder compared to one-purpose systems. First I tried to deliver a solution for RTEs to identify the form fields to attach to. For this to work, we need input format metadata attached to form elements, which is implemented in issue #125315 with the new #input_format Form API key. This suffers from some parenting issues still (does not support multiple format selectors in one form), which we need to solve before being able to commit. On the same angle, the RTE should know whether that format has anything to do with the format supported by the RTE, be it HTML, wiki markup or bbcode for example. Drupal uses HTML by default, and administrators need to explicitly disallow HTML. This setting however was tucked down in the "Filter HTML" filter, which made it non-intuitive to identify. So issue #24988 deals with breaking that out to its own filter for easy non-HTML format identification. This way we can easily disable HTML RTEs on such formats.

Putting permissions to place

Simplifying input format setup is quite important. Right now, there is a disconcert between setting up general permissions and input format access settings. Although the later configuration maps input formats to user roles, it is implemented in its own custom permission system. By leveraging the core permissions system for this in #110242, just like the node permissions are implemented with their dynamic names, we clean up the user interface, bring in consistency to permission setup and also simplify the API.

More fun with blocks

Finally, there are quite a few textarea based input interfaces without format support in Drupal core still. For some site settings, like the contact page help or the user registration help, I think it makes a lot of sense to just use blocks. By making the help area an official theme region, we can put the help text there as a block, and allow users to add any number of blocks to the help region to add more custom help to any page. The one-off solutions for contact page help and user registration help can be easily generalized to an admin-configurable custom help system in issue #240873. By using blocks in the help region, admins can limit and share help between different pages, provide different help for different roles and use any format for their help input. If this sounds a lot like the helpedit module or somewhat like the helptip module, that's not a coincidence, this simple change would move some of the features of these modules to core.

Many of you know that I am employed by Acquia to work on Drupal 6 full time right now, but since Drupal 6 is nearing a release, you might have wondered what I am going to work on next.