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.
a little off-topic
I have noticed on many sites that use FCK Editor that it breaks the principle that user input should not be messed with-- that Drupal applies formatting on output, and stores exactly what you enter in the database.
Many FCK Editor implementations strip all white space and add the paragraph tags and make text all but unreadable when viewed and edited without the rich text editor – and when text is entered with the editor turned off, there are no automatic line breaks – and some tags and characters are lost.
I know that with some extra steps TinyMCE could be configured to play well with Drupal's default input format and remain readable in code, and I think it's important we try to do the same, by default, for any rich text editors that can work with core. Just throwing this issue out there!
benjamin, Agaric Design Collective
#wysiwyg
Maybe offtopic: Wysiwyg API already provides a #wysiwyg FAPI property, which can be used by contrib modules to prevent a Wysiwyg editor from showing up.
I'll try to review those patches as soon as possible.
not the right path IMHO
Having a #wysiwyg property is NOT the right path as far as I see. You should attach useful metainformation and then let the system do whatever it can with it. Attaching formats to textareas is not only a WYSIWYG thing, it could be a CSS styling aid, it could help JavaScript dynamically swap WYSIWYG editors based on the format you choose, etc. You don't tell "this should use WYSIWYG", you tell "this textarea input will be processed with this input format" or "this textarea is plain text" and then the system puts on WYSIWYG if it wants to.
Form controller!
Uh oh! I almost forgot: http://drupal.org/project/form_controller was another approach on controlling forms, without having the user know about ugly form ids.
It's still a proof-of-concept module, which actually provides the administrative UI for Journal module (http://drupal.org/node/228244).
In a nutshell, it adds a link to open a modal dialog via JavaScript to all forms, in which the user is able to enable/disable available form additions. The form is immediately reloaded after changing its settings.
Journal as well as #translatable were the first candidates I initially thought of when writing Form controller. Both modules add extra fields and data to a form, which might not be desired or might even be required for certain forms.
And I guess the situation for Wysiwyg API/Editor is similar - instead of communicating a form id, the end-user wants to configure/control form additions, without touching code.
Of course, access/visibility configuration of client-side editors requires some additional logic (see relevant issues in http://drupal.org/project/issues/wysiwyg), but I do not see a reason why this could not work out.
Forget about #wysiwyg and this blog post! 8)
Wysiwyg API has been completely rewritten and supports multiple editors and editor versions now. TinyMCE 2.x, TinyMCE 3.x, and (rudimentary) FCKeditor 2.6 are already supported.
But the most interesting improvement in terms of your blog post is probably:
Attach client-side editors to input format enabled textareas only
Already tested with default content-types, CCK, and plenty of textareas that SHOULD NOT be wysiwyg-enabled, YAY! Another step closer to have Wysiwyg API in core for D7 :)
Cheers!
Daniel F. Kudwien
WYSIWYG project
I've been impressed at the progress the WYSIWYG project has been making into making an elegant and working implementation that I think would be a great integration into core.
Seen it
I've described my thinking on a #wysiwyg property VS. more fine grained metadata which can be used for other purposes as well in another comment. The goals of the WYSIWYG API project are great, and I hope they'll look more on what is going on with Drupal 7 and contribute there! My blog post is about getting attention to the base problem of attaching to textareas and getting it solved once and for all in core not in a contrib module you'd need to install.
New #type?
What about just adding a new form element #type called 'editor'. Keep textarea the way it is, then module developers can decide if an editor should be allowable for their intended use of a field.
With the 'editor' type, allow a hook-in for modules to provide an editor like TinyMCE or FCKEditor. Have the default for this fieldtype just create a textarea, as handled by Drupal (the default setting can be a variable). Then, something like the #wysiwyg option, or #editor, or whatever it will be called can be used to override the default editor with an editor that you want (e.g. if you have both TinyMCE and FCKEditor, they each define an editor-type string that could be specified with #editor='tinymce' or #editor='fckeditor', respectively). I know I use two different editors on one site (XStandard for internal users, and FCKEditor for external users), so the ability to select which one would be helpful. Something like hook_editor($type, $element) could be used for this hook, or hook_editor_#type($element), or even #type_editor($element).
not only textareas
Well, some people are already using format support for one line text (eg. node titles, short quotes, etc), and we were asked not to introduce a single field type, but instead add format support as metainformation to existing fields. This is also useful, so you don't need to replicate properties of a textarea/textfield on more types. Plus you can also easily switch to other input types, when needed, without switching between special form elements.
Again, as I said about #wysiwyg, we are not about to tell, how the form element should be displayed, but what format we are going to expect in there. This also helps with services, since you can expose your input requirements (multiline text, single line text), and maybe even an external program can display the interface for you.