Configure an awesome WYSIWYG content editor in Drupal 7 with TinyMCE or CKEditor

In Drupal, there are actually a number of ways to add a WYSIWYG editor to a text area. The new “Drupal way”, used on over 150,000 Drupal sites and arguably not so “new” anymore, is to use the Wysiwyg integration module, which has support for several of the editor libraries. I would personally suggest using it, if your needs can be met by it, since it's becoming more and more powerful and offers a fair bit of flexibility to easily change the configuration or editor used. That said, there may still be reason, in Drupal 7, to use one of the single-library integration modules, such as the still-popular CKEditor project. The TinyMCE integration module development has already been abandoned in favor of Wysiwyg, but it's good to have alternatives. Note: In this post, we assume you already know your way around Text formats. Text format configuration can be one of the most tricky parts of properly setting up your WYSIWYG experience, so if you don't already feel you know your way around this common stumbling block, be sure to read our recent post about Text formats / Text filters, too. This article is a companion-post to that one, but it also includes some degree of overlap, since when we turn on the Lightbox and Image Resize Filter modules, we have new filters we'll want to use in some text formats and we will want to pay attention to the order in which they are applied, so we will briefly revisit this topic here.

If you happen to like the more “minimalist” editors, and your site's users won't be freaked out by having to see actual HTML code, you may wish to consider using BUEditor instead of any of those which integrate with Wysiwyg. We will cover using it in another post, since I've personally been convinced that it's maybe even more awesome than a “WYSIWYG” editor. This post will simply cover setting up TinyMCE or CKEditor with the Wysiwyg integration module.

First we'll add and activate the Wysiwyg module

Put all contributed modules in the sites/all/modules directory

Please start by downloading the latest stable release of the Wysiwyg module. Contributed modules like this are usually added to the sites/all/modules directory. It's activated on the Drupal admin/modules page in the “User interface” fieldset, which you should see near the bottom of the page. Since it's common to want images within posted content, we are also going to demonstrate using IMCE and the IMCE-Wysiwyg Bridge to upload and insert images and we'll also add Lightbox2 and the Image resize filter module for improved display of images. You can add all four of these image-related modules to your sites/all/modules directory and also activate them at admin/modules. This blog post will not delve deeply into configuring images or associated modules — this can be a rather complicated topic, so it should also be covered in a separate post. So, while we'll be integrating IMCE and Lightbox2 for display of embedded images in this tutorial post, the full configuration of these modules will be covered separately.

Add editor library(ies) to your sites/all/libraries directory

admin/config/content/wysiwyg/profile
If you aren't already sure that you want to use TinyMCE or CKEditor, it's a good idea to take a little time to experiment with at least some of the different alternatives to determine which you like the best for your use case. CKEditor and TinyMCE are the two editors which integrate best with the Wysiwyg module and IMCE (to allow uploading and adding images to text areas). You could try some of the others, but bear in mind that, at least at this stage, many of the editors are not very fully supported by the Wysiwyg integration and may not have support for the full button sets available, nor for integrated image upload, etc.

Editor code, once downloaded, is extracted in sites/all/librariesEditor libraries are added to Drupal by extracting their code files and putting them in the sites/all/libraries directory, which you should create if it doesn't already exist. In a few odd cases you may need to rename a directory or add/remove a level of hierarchy, so it's best to read the installation directions on the Wysiwyg profile page, which you'll find at the bottom in a collapsed field-set. Click it open and find the directions that apply to your editor of choice. For TinyMCE or CKEditor, you should be able to simply download the latest stable version of the Javascript libraries for the editor and extract the archive (.zip file) into the sites/all/libraries directory, as per the directions:Download and extract the TinyMCE javascript library in the sites/all/libraries directory

One of my long-time personal favorite editors for embedding in browsers is the Markitup editor. It's simple, light-weight, and technically is not truly “Wysiwyg”, but it offers some nice features you won't normally see in the really fancy-looking editors. If your target audience could be described as “HTML-savvy” (or BB-Code-savvy / Markdown-savvy, etc), they may prefer such an editor since they always have access both to editor buttons and to a view of the generated code. And where other editors may add a dozen lines of in-line CSS styling when you paste text from a styled document, Markitup will only copy the text, not the styling. Even better, you can wrap a tag-set around selected text with just a simple keyboard shortcut.

What the Markitup editor normally looks like

I like the nice combination of simplicity and power that Markitup offers, but you can't get it with Wysiwyg module and Drupal 7.

As you can see it offers most tags you'd want for any HTML content and you'd only need to hand-code a few tags, here and there. You can experiment with this configuration on the Markitup "examples" page.

This is Markitup integrated by Drupal 7's latest version of the Wysiwyg module

Markitup has very limited support with Wysiwyg integration in Drupal 7.And that's with ALL available buttons selected… so Wysiwyg integration supports only a fraction of Markitup's standard Filtered HTML button set. Most disappointing! Well, having read up on the topic, I believe that it's just some work, currently, to integrate each button, so some editors that many people use are much better supported while others may still be more of a “development stub” example that the community can build on. It may just be that those of us interested in Markitup will have to help complete its integration with Wysiwyg (or help complete the port of the Markitup module to Drupal 7). But the search for a better “non-WYSIWYG” editor (text editor) did lead me to the BUEditor, a nice alternative which can be used with Drupal 7.
 

The safest solution is to use one editor

It's probably best to adopt just one editor for all text formats. Otherwise if you have privileged users with access to more than one format, that will mean two different libraries of Javascript code are added to the text areas and you can start to run into weird conflicts… like no editor showing up for a text format which is assigned to an editor… or no ability to properly switch between “rich text” and “code” views. It also means a lot more Javascript is added to each page, so it can delay initial page loads. So we strongly suggest choosing one editor which is sufficient for all your needs. To my knowledge, since only TinyMCE and CKEditor are supported by the IMCE-Wysiwyg bridge (which you may want if you'd like to add images to posts), it might be worth trying out both, before selecting one. From this point on, in this article, we are assuming you have settled on TinyMCE (or CKEditor), so some steps will include tips or screenshots which apply only to TinyMCE (but CKEditor is very similar in terms of the configuration).

We'll start by configuring the Filtered HTML button-set

Select TinyMCE as editor for Filtered HTML and saveFirst we need to select an editor to use for “Filtered HTML”. Select “TinyMCE” (or CKEditor, or whatever) from the select list for “Editor” and then click “Save”.

But wait… you still have to select the buttons

If we stopped now, we would only have an empty editor, one with no buttons — which would be much like no editor at all. Don't make the mistake of stopping now and thinking the defaults are probably good enough. Unfortunately, they aren't. Be sure to click on the “Edit” link which is now active for Filtered HTML and TinyMCE in the “Operations” column.

Select appropriate buttons when configuring your editor for a "filtered" text format

Select appropriate buttons when configuring TinyMCE for the Filtered HTML text formatJust select buttons which will be useful and appropriate for the limits of the text format. In this image, you can see what should be an appropriate selection of buttons for a Filtered HTML text format. I would be sure to add the <p>, and to be safe, both <br> and <br /> tags to the allowed list of tags for your Filtered HTML text format. (See related article for more info about configuring text formats). Why? Now you can turn off the “turn line breaks into HTML” filter (which turns double line-breaks into <p> tags and single ones into <br />). You will probably find that any WYSIWYG editor is going to add those tags, anyway. And people will try to add them (in code view) and be annoyed by having them stripped out on output. Plus, you'll probably find that your code gets re-formatted, no matter what settings you use in configuring the editor.

Tweak the settings for “Cleanup and Output” (optional)

Adjust settings for Cleanup and Output of HTML code from TinyMCEI personally can normally accept all the other default settings, but change the Cleanup and Output settings, as shown. Verify HTML should be good, but I don't like the editor to add lots of styling when people paste. Let's try to keep that in the CSS files. I also don't like all the linebreaks removed, since I tend to look at the code, and I'm sure many others are like me and will also want to see or adjust the code. Assuming you don't have the “convert line breaks to HTML” turned on (you shouldn't if using a WYSIWYG editor), it’s safe to leave “Apply source formatting” on. It will give you some appropriate line breaks (hopefully) so that it’s easier to read through the code. The “Force cleanup on standard paste” option helps clear out some of the garbage that people might attempt to paste in. I’ve seen no reason to disable that feature.

Now your editor should look something like this

Your TinyMCE editor should now look something like this.

Provided you are configuring TinyMCE and selected the same buttons I did, your editor should look something like this, at least to your regular users who probably will only have a limited set of HTML tags they are using.

Make sure selected buttons correspond to allowed tags

To make sure that your editor and corresponding text formats are properly configured, you should test the different buttons and pay attention to the preview. Here, we can see that the <strike> tag is not allowed by the current format (Filtered HTML) and should be added to the list of allowed tags for Filtered HTML if we want to have that button available for use*. Nothing is much more confusing and annoying to users than when they add the proper code, can see it in the code view, but don't see the same result in the saved output. Look at what tags are output by the editor (for each button used) and either disable the button or add the corresponding tag to the text format's allowed tags. Use the node preview button (at the bottom of the page, next to the “Save” button) to check [*Note: Actually, in the current TinyMCE, the “strikethrough” text treatment is accomplished by wrapping text in <span> tags with a style attribute which achieves the same effect. In the current version of CKEditor, it's <strike> tags. In other editors, you may find the “same” button adds <del> tags. All three achieve the same effect and if you want to include the strike-through button, you may wish to add more than one of these tags to those allowed for your text format.]

Don't enable the “preview” button

Don't add the preview button to your editor for a filtered HTML text format. It will render tags that are removed by Drupal's filter system. There is a common issue across various editors integrated by Wysiwyg. If the editor provides a “preview” button, and most do, the preview will render any HTML, regardless of tag limitations imposed by the current text format. For example, this means that images and <strike> tags used for strikethrough text will work as expected in a preview, but since the tags are not part of the default “Filtered HTML” text format, the <strike> or <img> tags will actually be removed on output instead of displaying an image or the text between the <strike> tags with “strikethrough” styling. You can still preview by clicking on the “Preview” node button, before saving, but the “preview” provided by the editor can be misleading. Hopefully future development of the Wysiwyg module might implement something like Ajax markup, which integrates with BUEditor (but not with the Wysiwyg module) to display text with correct output, i.e., according to active text format filter settings, etc.

Repeat for other text formats, but keep it simple

It should be easier to set up your editor for Full HTML. You may also wish to create a filtered html text format for trusted users, e.g. a “Filtered+” HTML. Just follow the same steps. Add a few more tags to the allowed set (perhaps you trust these users to add images or sub-headings). My only advice is to follow the KISS principle and “keep it super simple”. It's easy to get carried away and add all buttons available for Full HTML. Resist the urge. You are more likely to run into bugs and you'll end up with an overwhelming user experience. I'd suggest keeping the button-set limited to the most useful tags.

This is what the button-set looks like if you select them all:
TinyMCE and CKEditor are overwhelming if all buttons are selected for Full HTML

My recommendation would be to add just a few more buttons to the set you created for Filtered HTML. If you want users to be able to simply add images within their text and you've turned on the IMCE module, be sure to select both the Image and IMCE checkboxes. Working with images and IMCE is complex enough that we'll cover that in the next post.

Make sure the text filters for the format make sense and are in logical order

Minimal filters for Drupal's FIltered HTML text format

admin/config/content/formats/filtered_html
Now you should check your filters. Make sure the appropriate filters are enabled and that text is processed by the filters in a reasonable order. The Filtered HTML Text format normally includes the “convert line breaks to HTML” filter, which doesn't make sense if you are using a WYSIWYG editor (just be sure to include the <p> and <br /> / <br> tags in your allowed set). For Full HTML or other text formats with images, you'll probably want to include other filters, such as the Image Resize Filter and/or Lightbox. Again, we'll cover image-related tips in the next post.

Congratulations, you now have a killer WYSIWYG editor configured!

Be sure to test that everything works the way you want it to. Be sure to test that all of your user roles have the expected access to the editors and text formats and that features are working as expected. If you are working on a local development environment, it can be helpful to turn on the Devel module's “switch users” block and give all user roles permissions to use it. This will allow you to easily switch between a user of one role and your user-1 admin to tweak permissions or other configuration.

Be sure to check back for our next post about working with images in a WYSIWYG editor, which should be posted in the next few days.

Comments

Filtered HTML

Great Tutorial, I've got everything set up and even though the process has proven to be much more complicated than anticipated I now feel like I know my way around it pretty well. I'm still having two issues though: 1. When using Filtered HTML none of the images and formatting done through the wysiwyg is displayed on the finished page, although this is resolved when set to Full HTML, and 2. When Uploading images the upload process goes on forever, I've learned that if I wait 5 minutes or so and close the pop-up window and look in the images filter it is often there already, but not always. I would also like to learn more about controlling the folders that uploaded files go to, such as adding, deleting, renaming, and organizing. Thanks again for the great tutorial!

See the companion article

Have you also looked at the companion article, “Configuring and adding images to Drupal 7 content with Wysiwyg, IMCE and Lightbox2”? That article gets into using images and setting up directories for the uploaded files using IMCE_Mkdir. Regarding images being filtered (removed) by the "Filtered HTML" format; that is because the <img> tag is not allowed, by default, in Filtered HTML. What you might want to do is create a text format which is somewhat less permissive than Full HTML, but includes a few more tags, such as those for images… at least if potentially malicious users will have the ability to post any kind of "Filtered HTML" (in comments, etc). Otherwise you can edit the tags which are allowed by "Filtered HTML" to include the <img> tag.

By Jove!

That was exactly it, I've added <img> <p> and <br> tags in my filtered html configuration and now all of those formats are being displayed. However the css styles that are being used for alignment and such are still not working. I've since installed the wysiwyg filter module but playing around with that hasn't worked yet, have you done an article on that?

I suspect you would need to add <span> and/or <div>

You will have to look at the HTML code output by your WYSIWYG editor, but I suspect that to allow for "align" and other such properties you would need to allow <span> and/or <div> tags, as it seems that the WYSIWYG editors tend to add those tags and the styling to them. For layout controls, I would strongly recommend *not* allowing untrusted users (those who can use the default Filtered HTML format) to have access. Really, I would maybe only add the basics to Filtered HTML (not even the IMG tag), for security reasons, and to prevent broken layout on your site.

Really, I would recommend keeping the "Filtered HTML" tagset very limited and add another, less-limited "Filtered HTML-Plus" for "trusted users". We aren't using the WYSIWYG Filter module here and so far I have not felt I required it, but it does look like it could be useful, perhaps especially if you are allowing potentially malicious users to use more than the most basic tags.

Really useful information on Drupal wysiwyg editor setup

Just want to say thank you. I've been using Drupal for 4 years and I can say that this is about the clearest advice I've read on setting up TinyMCE or CKEditor. Congrats on a super how-to!

Adrian (Zevonjunior)

default editor settings

hi, i wonder something about default settings. how can i set default settings for editors (ckeditor, tinymce...) in WYSIWYG (like text align ="justify") i want the setting is valid for all editors i use.

Best done in your site's theme (CSS)

The inline styling that WYSIWYG text editors add for things like this is pretty ugly and I don't think you can easily set defaults like this anyway, especially not for multiple editors. But it would be relatively easy to make changes to your site's CSS stylesheet (style.css in your theme) so that appropriate content is styled to your liking, by default. Then you would need to use inline styling to override the general stylesheet if you ever wanted an exception. You could apply the same (or different) styles for comment and content display. Of course you wouldn't see this styling in your WYSIWYG text entry (when editing content) unless you also themed that to match. I know less about that, but I think it could be done if that bothered you.

Best done in your site's theme (CSS)

The inline styling that WYSIWYG text editors add for things like this is pretty ugly and I don't think you can easily set defaults like this anyway, especially not for multiple editors. But it would be relatively easy to make changes to your site's CSS stylesheet (style.css in your theme) so that appropriate content is styled to your liking, by default. Then you would need to use inline styling to override the general stylesheet if you ever wanted an exception. You could apply the same (or different) styles for comment and content display. Of course you wouldn't see this styling in your WYSIWYG text entry (when editing content) unless you also themed that to match. I know less about that, but I think it could be done if that bothered you.

how to configure one line of text

Hi
I have several node types with fields of one line of text, just 255 characters, but I allow to work only in full HTML mode with CKedior. In this case my one line becomes 20 lines of height and I cannot change it to be real one line, one line with toolbar of CKeditor above it.

Can you help me ?
Best regards
AR

For this use case, maybe a WYSIWYG editor is not appropriate?

I don't think I would want to use a WYSIWYG editor on such a field. Maybe BUEditor or another simple code editor would be more appropriate? Getting the actual code to be the way you want it, with most WYSIWYG editors, can be a real pain. Since the time of this article, of course, we have a number of other simple WYSIWYG solutions that might generate more "pragmatic" output. I don't think I would even choose CKEditor right now, for most Drupal projects.

Thanks , I will try to use

Thanks , I will try to use BUEditor,

Configure an awesome WYSIWYG content editor in Drupal 7 with

This is helpful!

WYSIWYG in Drupal 7

Hi,

I've been trying to get the WYSIWYG module installed for Drupal 7 by carefully following the instructions. I've gone through the whole process various times for both Ckeditor and TinyMCE, but without any luck. When I want to add a new article and select full HTML, the editor does not appear :(
I don't understand what the problem is.
Could someone help me please...
Thanks!

Napa Real Estate

That had been specifically this, I and my younger brother learn Web Design. We have added in <img> <p> and <br> tags around my strained html setup and now all of those types are increasingly being exhibited. Nevertheless the css types that are being utilized intended for positioning and these kinds of things continue to be not working. We did not succeed, please any help.

If the goal is learning...

I suggest reading up and experimenting more with CSS and theming. Without knowing any specifics of your code and what, exactly, is not working, I can only say it sounds like you need to try again. Is your CSS being included at all? If you are working with Drupal, the CSS should be in the active theme. If you need help with code, I'd also suggest posting on StackOverflow or somewhere with a lot of peer-based support and be sure to include plenty of detail about what you have tried and what result you are attempting to achieve. Best of luck.