When it comes to using a WYSIWYG editor in Drupal, TinyMCE and FCKeditor are the heavy weights in the contributed module arena. TinyMCE seems to have more supported plugins and modules, while FCKeditor seems to have the community’s love (as much as any web developer can possibly love a WYSIWYG editor, that is). To complicate things, Drupal is moving towards using the WYSIWYG API module as the future for WYSIWYG editing, requiring more to consider than simply the TinyMCE (or TinyTinyMCE) and FCKeditor modules.

Here is a list of features of each:

WYSIWYG API

This API module supports adding TinyMCE and FCKeditor very easily as a plugin. In fact, you could use both modules at the same time without a hitch.

It controls all aspects of the editor via input format. For each available input format, you choose one of any installed editors, or none at all. If there is no input format attached to a textarea then no editor will appear, solving some of the historic problems of the editor appearing on inappropriate textareas.

Editor appearance and such are also all configured on an input format basis. This allows you to limit the display of buttons to only those the input format will actually support.

This system will allow you to support non-WYSIWYG mark up syntaxes rather flawlessly, such as using Markdown for anonymous users, and attach a WYSIWYG editor to the full HTML input format for your power editors.

There is a catch to this method. All users must have access to the same input format (filtered HTML in a default installation), and that globally accessible input format is the default input format whenever you create new content. This can cause a lot of inconvenience, so you may want to consider the Better Formats module to control the default input format.

The Better Formats module will allow you to:

• Set a default format per role and content type
• Set a separate default format for comments of a content type
• Limit which filters are available to a content type
• Expand the input format fieldset to make it more obvious
• Hide the input format fieldset to force the default

Coupling those features with attaching a WYSIWYG editor to an input filter will make controlling the editor’s display settings quite fine tuned to your site’s needs.

TinyMCE

The TinyMCE module has been abandoned since last March. Although it has been successfully ported to Drupal 6, it would be best to use a more supported version for new web development.

There is another module, though, called Tiny Tiny MCE, that strives to make things simpler. It strips away many of the configuration options, offering just two modes: simple and advanced. I am going to assume that most developers want something they can tailor to the needs of their website and users, so I am not going to recommend this solution.

TinyMCE as a plugin for WYSIWYG API

TinyMCE is fully supported in WYSIWYG, allowing you to do everything you could do in the old TinyMCE module. This is an adequate replacement for the abandoned TinyMCE module.

• Default view: enabled, disabled, allow user to decide, show toggle
• Pick and choose which buttons to enable
• Editor appearance
  • Toolbar location
  • Button alignment
  • Path location
  • Enable resizing
• Cleanup and output
  • Verify HTML
  • Preformatted
  • Convert <font> tags to styles
  • Remove linebreaks
  • Apply source formatting
  • Force cleanup on standard paste
• CSS
  • Block formats
  • Editor CSS

Display would be controlled by the WYSIWYG API, and access control via input formats.

The TinyMCE UI

This is all individual preferences, but I find I much prefer the TinyMCE UI. It is very clean, simple and straight forward. The editing area can be resized at will as well to accommodate a user’s preference, which is just darn convenient when editing a large document.

TinyMCE Output

If you enable “Apply source formatting”, new markup rendered through the editor will each be on a new line, with no line breaks between them. This will help you avoid the dreaded all-HTML-on-one-line blob of unreadable text. To avoid common conflicts with the “line break converter” filter, add <p> and <br> to the allowed HTML tags.

To have more control over white space, you could disable the “remove linebreaks” option, however, the “line break converter” filter will cause conflicts and a messy output if it is not removed from the input filter.

FCKeditor

When compared to TinyMCE, there is significantly more configuration options. The significant ones are emphasized.

• Configuration by role, and control which roles take precedent over other roles
• Allow users to create a custom configuration
• Manual control over which text areas will have the editor, and whether to display a “simple” version or not
• Editor appearance
  • Default view: enabled, disabled, show toggle, show as pop up window
  • Collapsible toolbar, display expanded or collapsed by default
  • Choose which buttons are displayed through preset options (can create your own preset through editing a file)
• Cleanup and output
  • Control action on enter and shift+enter
  • Font formats
  • Apply source formatting
  • Format output
• Editor CSS
• Custom Javascript

The downside is that you have to edit a file in order to customize the button display, as opposed to TinyMCE’s web-based configuration. Plus, that file is one included with the module, and not one that has an “example” file which you can copy to prevent you from overwriting it when upgrading the module.

FCKeditor as a plugin for WYSIWYG API

At this time FCKeditor is not fully supported. The configuration options available in the FCKeditor module are not available here, and appears to be tailored for TinyMCE instead. Although it shows a lot of the same options that TinyMCE had, most of them do not work.

The editor works, there just is not a way to configure it through the web browser (I am sure you could hack the code, though). As such, my recommendation would be to not use FCKeditor with WYSIWYG API until its configuration is supported.

The FCKeditor UI

Again, individual preferences, but I find the FCKeditor to be cluttered. I dislike that each button is rendered a button, adding many more lines and gradients than is necessary. There are three “skins” to choose from (so I suppose I could create my own skin!), which are: glaringly yellow, painfully MS-office, and so-close-yet-not-simple silver. Of the three, I prefer the silver one.

Unlike plain text textareas and the TinyMCE editor, you cannot resize the editing window.

Behavior issues:

• Cannot right click to paste in FF3
• Toggling the editor causes you to lose your text

FCKeditor HTML output

The configuration options “apply source formatting” and “format output” help to create readable code. When you use the “source” button to view the source, or switching to plain text editor, the HTML is nicely formatted with line breaks and tabs. Upon submission, the same line breaks remain, but the indentation is removed. In my tests, I did not notice any conflicts with the “line break converter” filter.

Unfortunately, there is no way to configure this behaviour within the WYSIWYG API.

Overall, though, the FCKeditor module is giving the clean output web developers long for.

Conclusions

If possible, using the WYSIWYG API module is preferred since it is where the Drupal community is moving towards. Attaching the editor and configuration to an input format, coupled with the Better Formats module is a superior means of control. The alternative is attaching the editor to a user role, and fine-tuning the editor’s display by enabling or disabling its rendering on a textarea by picking each textarea or path individually.

TinyMCE

Pros:

• Fully supported by WYSIWYG API
• Configure visible buttons through the web interface
• Minimalist interface

FCKeditor

Pros:

• Nicer HTML output with indentation

Cons:

• Not fully supported by WYSIWYG API
• Configuring the visible buttons by editing a file
• Some UI bugs (can not right click to paste, loses changes if you toggle to plain text)

The nicer source HTML formatting was quite good on FCKeditor, but using WYSIWYG API is also very important to me, so I am going to have to call it for TinyMCE.

My final decision, however, will depend upon my review of Image Assist (compatible only with TinyMCE) and Image Browser (compatible only with FCKeditor).