WYSIWYG Editors In Drupal 7: Conflicts & Solutions

March 2013

Text editors are convenient tools for content contributors because they provide a quick means to add text (or media) to a web page without having to manually write HTML markup. The content contributor simply inputs their text into a text-editor, publishes the page, and the text is automatically converted to the HTML required for a web browser to display it. The primary advantage is time savings and these text-editors are especially useful for content contributors who do not know how to manually code HTML.

Unfortunately, there is not a single editor/solution for all content editing scenarios. Depending on the skill level of your content creators and requirements particular to your site, a “one editor, fits all” solution is very hard to achieve.

Winning Core Editor for Drupal 8

So far, Drupal 7 and earlier versions have not had a WYSIWYG (acronym = “what you see is what you get”) editor available to use “out of the box”. In order to add a text editor to a Drupal site it had to be manually installed via a contributed module. However, In Drupal 8 this will change and there will be a WYSIWYG editor available within Drupal core.Many requirements were considered and compared between various WYSIWYGs for inclusion into Drupal 8 core with CKEditor being chosen due to its advances in accessibility, semantic markup, and inline editing capability. However, depending on content editing scenarios and user skill level, CKEditor will still have limitations and unexpected results to some degree. Luckily, Drupal 8 still remains flexible enough to install another WYSIWYG editor that better suits your particular requirements.

Top WYSIWYG Editors for Drupal

The most popular WYSIWYG editors for Drupal are CKEditor (formerly called FCKeditor), TinyMCE, and Aloha. Of course there are others such as YUI editorjWYSIWYG, etc. but CKEditor and TinyMCE, are two of the more popular editors within the Drupal community for a variety of reasons.  As a developer with experience working on a large number of Drupal projects since version 5 and higher (ranging from small to enterprise level sites), I have also found these editors to be the most common, serving a wide range of needs for most content contributors.

WYSIWYG Limitations

Regardless of which editor is used in your Drupal site, various factors will have an impact on how your content contributors are able to access WYSIWYG features, as well as how content created in the WYSIWYG appears within a Drupal theme after it is saved.

Missing Functionality

I often get complaints from clients that they do not have all of the functionality they need when creating or editing content within their text-editor.  For example, the client may want to change the font-style of a particular line of text or do something more complicated such as embed media, but cannot because the buttons they expect to see in the text-editor’s toolbar are not available.

Depending on the requirements the site’s developer adhered to when setting up the text-editor, the absence of such functionality may have been intentional in order to safeguard the site from things like styling text in ways that conflict with the site’s theme and/or company branding. The exclusion of media embed functionality may have been intentional to avoid legal issues relating to copyright and content sharing restrictions.

In situations such as these, you should speak with the client to fully understand what it is they are trying to do and why they need to do it. If you find that the request does not violate any visual standards particular to the site, or that the media content they wish to embed is legal to share, then you can enable the buttons (plugins) the client needs.Typically, additional features can be enabled under the WYSIWYG module’s settings for a particular WYSIWYG profile (assuming the site is using the WYSIWYG module and a common text-editor that includes such features). To do this, simply go to the configuration page for the WYSIWYG profile. Drupal path = “/admin/config/content/wysiwyg”. Find the input format that your client is using (often restricted by user role), click the “edit” link under the “Operations” column. On the following screen expand the “Buttons and Plugins” tab, then check the options related to the functionality they need. Save the page to enable the selected features.

User Roles & Input Formatting Conflicts

There are a few things that can go wrong when content contributors with varying permissions (different user roles) collaborate on a given Drupal node where a text editor is assigned to specific input formats and integrated with the WYSIWYG module.

One such scenario may be where you have two different content editors working on the same page (user “A” & user “B”). Let’s say that user “A” is assigned to a role that can only access the Filtered HTML input format. User “B” is also contributing to this page but is assigned to a user role that also allows them to edit under the Full HTML input format. Collaboration between these two different users can certainly create conflicts and even loss of data because the HTML markup that is saved between the two users will vary as the page gets saved under the different input formats.

Specifically, if user “A” (who only has access to the Filtered HTML format) edits and saves the page after user “B” (with access to Full HTML format) has applied particular changes that have generated HTML markup that is excluded from the Filtered HTML format, the excluded markup will get stripped out when the user “A” saves the page. User “B” will return to this page and see that some of their work has been lost and will have to manually apply their edits again in order to restore them. If user “A” returns to edit the page again, then the restoration performed by user “B” will have been in vain.

There are ways to prevent this sort of conflict from happening. However, the solution will vary depending on how many different content contributors, user roles, and the number of input formats your site is working with.

One option may be to utilize the Better Formats module to restrict particular node types to only use particular input formats. Another option may be to add to the list of allowed HTML tags within the Filtered HTML input format. You may also consider restricting the editing of particular node types to only certain user roles with the Content Access module.Also, consider the use of Workflow along with defining a strategy for your site’s content editing process. If you have a simple site with a minimal amount of user roles, with only a few content contributors, then consider using Drupal’s Node Revisions as a safety catch to easily review and revert content changes between multiple saves.

Theming Conflicts

The most common complaint I get from clients is that the content they create and see within the WYSIWYG is not always what they get after they save. There are all sorts of factors that can contribute to these visual discrepancies. Most often, they are the result of the text-editor inheriting particular CSS styles when in edit mode and the content inheriting different CSS styles after it is saved and rendered within the site’s theme.

One example of this sort of conflict could be the positioning and display of unordered lists within the text-editor versus the way it appears after saving and you view the final page. Typically, this difference is caused by either the difference in CSS between the theme being rendered while in administration mode versus the CSS particular to the theme used on the front-end of the site. Some text-editors even provide their own style sheets so it may be that the editor is still using its default CSS instead of the CSS from the desired theme. Fortunately, the WYSIWYG module provides an option to override the editor’s default CSS with the theme’s CSS. This option is available under the “CSS” tab of the WYSIWYG profile configuration page. Example: /admin/config/content/wysiwyg/profile/full_html/edit

Another common theming conflict that occurs is when content contributors use a text-editor and they have the ability to apply inline styles to the text using buttons that can change the font color, font size, underlining, indentation, etc. Since the text-editor writes these changes to the HTML as inline CSS, when the content is saved it overrides the CSS rules set within the theme. This can be a Drupal Theme Developer’s nightmare because no matter how well the themer has defined his or her style rules in the theme’s CSS, the inline styles applied by the text-editor will always override them.

For example, the theme developer may have intended that all body text within a page be set to a 12px font-size and only be the color black. However, if the content contributor has applied inline styles to the text within the editor to make the font-size 21px and the color red, it totally overrides the styling standards set within the site’s theme and can create a very bad presentation in the content.The best way for a theme developer to ensure such overrides do not occur to the theme’s CSS is to limit the styling options available to the content contributors within the WYSIWYG. If the theme developer does not have the ability to disable styling options within the WYSIWYG profile then the only other option would be for the theme developer to educate the content contributors about the negative effects such overrides can have on the appearance of the site’s content.

Copy/Pasting Content From External Sources

Content contributors often copy and paste text from external sources into Drupal in an effort to save time required for manually entering the content into the text-editor. Depending on the configuration of the WYSIWYG, unintentional formatting may be carried over from the source in which the text was copied. This is especially true if the content contributor copies text from another web site where inline styles are applied to the text beforehand. Pasting this text into the editor may still retain the inline styles from the external site when saving the content in Drupal, creating conflicts with the site’s intended CSS.

To prevent unintentional inheritance of these inline styles, the WYSIWYG profile can be configured to cleanup and remove formatting from pasted text. Under the “Cleanup and Output” tab on the WYSIWYG profile configuration page, there is an option to “Force cleanup on standard paste” that can be enabled to remove undesired styles and formatting. Example: /admin/config/content/wysiwyg/profile/full_html/edit

You can also enable the “Remove formatting” button within the WYSIWYG profile to provide a button within the text-editor’s toolbar. This button has an icon that looks like an eraser. After pasting text from an external source into the editor, select the text with the cursor and click the eraser (“Remove formatting”) button to clean the HTML markup associated with the text.

If you are unable to set these configuration options within the WYSIWYG profile, then another approach would be to inform the content contributors about these potential conflicts and ask them to paste the copied text into Notepad first. Next, have them copy it from Notepad and then paste the text into Drupal. Notepad will convert the original paste into plain text (with no formatting), cleaning it up for pasting into Drupal.

Other content contributors may be using Microsoft Word (or a similar word processing application) to draft their text first. The reasons for doing this can vary, but the most common reason I hear from clients is that they are comfortable using MS WORD because of its grammar and spell checking features. For those who rely on MS WORD to draft their content before entering it into Drupal, there is a “Paste from WORD” plugin (button) that can be enabled and added to the text-editor’s toolbar from within the WYSIWYG’s profile configuration page. Clicking the “Paste from WORD” button before pasting the text into Drupal will remove the unwanted MS formatting that occurs.If the content is simply pasted into the text-editor without the use of the “Paste from WORD” plugin, then the MSO (Microsoft Office) inline styles will be inherited into the HTML markup and conflict with the CSS that is intended for the Drupal theme. If the “Paste from WORD” plugin cannot be enabled, then ask the content contributors to paste the text copied from WORD into Notepad before pasting it into Drupal. This will also remove the unwanted MSO styles.


“Out of the Box”

Definition: functionality, particularly in software, is a feature or functionality of a product that works immediately after install without any configuration or modification.
Source: http://en.wikipedia.org/wiki/Out_of_the_box



Aloha Editor

YUI editor


Better Formats Module

Content Access Module

Node Revisions

Drupal WYSIWYG Module
http://drupal.org/project/wysiwygReview of Drupal rich text editors

Additional Resources

What You See Is (not always) What you Get (but it can be)

Relieve the pain of using Microsoft Word with WordPress or Drupal

WYSIWYG in a MS Word World

Why Microsoft Word and your Drupal website are not friends

Drupal WYSIWYG editor configuration tricks

Configuring Input Formats


This post authored by former Isoveran Trent Wyman.