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. Well Dries asked me to look into supporting WYSIWYG editors better in Drupal 7 first, and although it would have been better to post this after Drupal 6 is out and fine, a discussion is heating up on the development mailing list, so I figured I'd rather go ahead and post my findings / thoughts to accelerate the discussion. I was pondering with opening an issue or two about this, but this needs a few distinct issues coordinated, so I thought an initial blog post will do better.
There is a huge list of WYSIWYG editors (RTEs) for Drupal out there. Yet most of them (if not all, I honestly did not have the time to deeply look into all of them) get the basic question wrong: how and what textareas to attach to. The fundamental problem is that they are tied to textareas not input formats.
On a Drupal site, you could have as many input formats as possible, and these might wary in what they allow you to do. One might be full HTML input, another might be limited HTML input, or bbcode or textile markup. All these need different RTEs or at least different configs of an RTE. So basically, RTEs should attach to an input field with a suitable input format, not any textarea. That said, previous ideas to introduce a #wysiwyg form element type does not look reasonable, since what happens in an input field is largely up to the site implementor with the input formats present on a site, it is not part of Form API (but better coupling between input fields and input formats is a Form API improvement to make IMHO).
A battle plan to make this work is as follows:
- go through all inputs (textareas) in Drupal core and check what format they support (some do check_plain(), some do filter_xss(), while others use the default input format and then others offer a format selection on the UI)
- find out how to make some of the crucial inputs format aware (eg. site mission)
- make space (an API?) for RTEs to tie into input formats (so we can set up an RTE or different configs of an RTE per input format); this should be the primary interface for setting up RTEs
- make the RTEs use / obey the settings already present in input formats, not duplicate it (ie. set up their available buttons based on allowed HTML tags)
- make the RTEs attach dynamically to inputs, so if I switch from HTML input to filtered HTML, the RTE config changes or if I switch to bbcode, the bbcode RTE appears (if available; this is client side functionality)
- look into misc issues, like integrating default input format per node type support
Better APIs for WYSIWYG editor makers could result in a much more satisfactory experience and eventually an RTE which looks like ready for core, if the kinks are worked out. One of the killer features wanted by the community for Drupal 7 is an RTE after all.