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.
Beautiful
This would be a wonderful thing to have.
I really do hope that if we have a WYSIWYG editor in core it's more than just something that helps you with the html.
I'm liking how Acquia has you spending your time. Working on those little things that make a big difference. :-)
I dont agree with WYSIWYG editor as core
It will be much better in the long term, and fit the module behaviour of Drupal better, if there is instead a WYSIWYG API. Otherwise it will be even more difficult to have your own choice of editor and the temptation to communicate by means not available to other editors will e great.
By all means have a made for Drupal editor once an API is in place, but it should use the same interface and mechanism that are made available to other editors.
DRUPAL CORE
(WYSIWYG API)
/\
||
\/
Editor Module
/\
||
\/
Editor
WYSIWYG in core
I have to disagree and say there should be a WYSIWYG in core. But, there should be a core API that this module and contrib editors use. And, the contrib editors should be around and held up. But, having one in core will make a huge difference.
Now, I reserve the right to entirely change my mind when we get a packaging system :-). At least about packaging an editor in core.
Yea!
I am so excited that Drupal is moving in this direction and I know its not just a pipe dream because they have a "big name" on it and are moving forward. The wysiwyg editor is not only helpful for when you are developing a site for a client that has no programming or development background, but its also helpful for people like me that know how to develop websites but that love to have a quick editor for things like my tutorials and my Visual Basic Source site. I have struggled through patching all the necessary modules together to handle code highlighting and such. This would be so much easier if there was a main WYSIWYG editor within Drupal that all the modules worked for. Instead of multiple editors with modules split between supporting different ones. YEA! thank you for working on this and keep it up!
Off to a good start
You've nailed one of the two big issues I have with RTEs on Drupal. On our most recent launch, we're using FCKEditor instead of TinyMCE because the latter's integration module does not appear to give us control over where the editor insinuates itself. Profile interests blow up rather spectacularly when they're tangled up with auto-generated HTML.
The other big issue is not necessarily Drupal-specific, but needs to be fixed in order for a core implementation to succeed. In the real world, users cut and paste from an unpredictable variety of applications, and of course the Evil Empire keeps changing its "standards," making it very difficult to filter MS-garbage out of the HTML.
At the moment I'm looking at pasted content from one of our writers in which there are no p tags, only div tags. Arggh!
WYSIWYG API
We've been discussing this on #drupal-ghop after this insane task and we concluded that an API change is needed so that the RTE has to know what stuff the input format allows. The reason is two fold:
We thought that it would be good to provide another level of abstraction by mapping semantics to HTML tags, such as mapping
<em>to "emphasis,"<a href="">to "link," mapping<ul>to "unordered list,"<li>to "list item," and so on.With that, any input format would have to declare what semantic elements it allows, so that any RTE module would programmatically know that in order to provide corresponding toolbar buttons and filtering mechanisms.
complex
This is indeed complex, and modules provide things like "insert a node teaser here" or "insert an image node here" or "insert an image from the image gallery with these options here", and the number of semantic building blocks (and their config options) you might need to configure explodes. I don't think we can achieve full RTE agnostic configuration. Most of the current RTEs support as specific markup language, eg. HTML or bbcode, so they should understand filter settings for HTML or bbcode without an intermediate semantic layer. Unless we can find easy ways to map the "arbitrary" contrib filters to semantic meanings.
Putting the burden on RTE integration modules
I worry about the complexity of the system suggested, and I think its roots are in some of the rigidity of FAPI itself.
Perhaps a convention for writing an RTE integration is in order -- I think it could be the job of an RTE integration module to figure out how they want to translate to and from the input formats available for a given field where the RTE is enabled. That still requires input formats to be able to tell us about themselves in a useful way, and requires RTEs to be able to adequately handle all the use-cases they define as being able to handle. On the other hand, it still allows for dynamic editor swapping when the user switches the input format.
The world of RTEs and the world of input formats are both highly heterogeneous. I think the burden should be on the RTE itself for handling that, or admitting that it is not appropriate for a given input format.
Inline / Wysiwyg API
That is correct. Displaying contents inline and supporting markup languages are often treated as separate topics - unfortunately. I have studied both topics and more importantly many relevant contributed modules (including their code and bug reports/feature requests in their issue queues) for more than one year now.
The time for a change has come - I've just released my battle plan at http://groups.drupal.org/node/8707, which already incorporates your valuable thoughts here.
Allow user to disable wysiwyg
Please also add support to disable wysiwyg editors per user (tinymce module does it). Sometimes, an admin/knowledgeable people has the same role as an editor, but he doesn't want wysiwyg, altough the editor need it, on the same textareas...
Just to be sure it will be possible to choose full html filter and still not have a wysiwyg editor loading by default. Wysiwyg editors slow down pages rendering a lots on older computers.
But I guess this could also be provided by the editor module itself.
I have similar thoughts...
See #205160 - Filter options based on CSS attributes, not just HTML tags for an issue I started about this. By "CSS attibutes", I'm refering to form and field.
I think I've done a good job of making nicedit configurable in this way. The next step I was planning on taking (see my "Drupal 7 Battle Plan") was to refactor nicedit into two modules, one that was a prototype for core that had all the administrative stuff you needed, and one that was specific to the nicedit editor. I don't know if nicedit is THE editor, but I do believe that we need a better framework. And I hope that the two days I spent working on nicedit, is a good starting point.
markitup module
Gabor,
I'm excited to see your thoughts on this subject, and since I began working on the markItUp! module, I understand just how essential improvements in this area of Drupal are.
Tying editors to input formats just makes sense. That would do a lot for simplifying the configuration needed for editors.
(BTW, I should point out that it's not quite WYSIWYG, but the markItUp! module may be of interest to folks here. It's an integration of the jQuery-based markitup content editor. Further discussion on it can be seen at http://drupal.org/node/97948#comment-801486 ).