I've always tried to avoid using WYSIWYG except for the main body field, thinking that it was better to try and keep as much as possible as plain text in the database.

But the conflicting methods/styles could confuse content editors, so I'm now thinking it might be better to use a constrained version of WYGWAM for all textareas instead of the Rich Text Formatting buttons/toolbar.

Is there any performance loss or a problem further down the line that may cause me to regret going down this road?

  • I've been happily using it since it was released, with no issues. @Jérôme mentions what I think are the biggest advantages under his "additional factors" list: good integration and plentiful, easy to use customization options. – Alex Kendrick Feb 21 '13 at 17:19
  • ...but see my answer for a potential drawback to using it as a complete replacement for the native textarea fieldtype. – Alex Kendrick Feb 21 '13 at 17:38

The only downside I've ever run across is the lag when loading Wygwam on the publish pages, especially if there are more than one on the page. Wygwam is still using CK Editor 3 so it's possible that when they eventually update this to CK Editor 4 (like Wyvern has) the performance issues will be reduced or eliminated altogether. The upside for me, however, far outweighs the downside. I have FULL CONTROL over the toolset I can give clients and pretty much anywhere I would use a text area, I use a Wygwam field.

The UX benefits are important to me so when clients see a field where they can enter a paragraph they see the WYSWIG field. The tools they are given are applicable to the content they are entering. If it makes sense to allow them to add bulleted lists they get the bulleted list menu. If I want to only allow them to bold or italicize text, pretty much everything is removed from the toolbar.

The only buttons that are consistent across ALL Wygwam fields for me are the source code button, the show outline boxes, and some form of the format drop down menu. The format drop down ALWAYS contains the normal style so if a paragraph somehow is removed they can easily fix it without having to deal with the source code. The show outlines is only there so they can turn off the default state of the outlines being on and the source code button is there for emergencies.

A lot of this applies to using Wyvern but I prefer the control panel Pixel and Tonic has provided for working with CK Editor and the advanced features much better then Wyvern. While I like the effort put into Redactor, I am not all that impressed with the results in use compared to Wygwam or Wyvern so I avoid Redactee and Editor. I stopped using Tiny MCE after figuring out what I can do with the advanced config settings in Wygwam.

  • I agree about the fact that there are many easy ways to control the WYGWAM experience and limit the damage that users can do. I did suspect that page load times might get extended if there were multiple WYGWAM fields, I may need to have 8. I also tend to use one custom field group and then hide the fields that are not required for some channels, so guess it will slow down the page even when they are not shown. Perhaps if defer the initialization until the field is clicked on that will solve that problem? – Paul Frost Feb 21 '13 at 19:16

I usually install a very stripped down version of any WYSIWYG editor, Wygwam included. That's usually less confusing for the client than seeing the code produced by the Rich Text Formatting buttons. If all you need are basic tags, the source code formatting is not that bad

Aside from the RTE shipping with ExpressionEngine, here are the popular solutions. All of these have options to customise the formatting options available to the end user.

  • NSM Tiny MCE (built on Tiny MCE - free)
  • Wygwam (built on CK Editor - commercial)
  • Wyvern (built on CK Editor - commercial)
  • Redactee (built on Redactor - commercial)
  • Editor (built on Redactor - commercial)

Additional factors to consider:

  • integration with other add-ons (Structure, Matrix, Low variables)
  • ease of customisation
  • responsiveness in the CP (if you use many of them in one publish form).

I can think of one potential drawback when using a wysiwyg for all your textarea needs:

There are times where even though you want the user to have bold, italics, or link buttons, you don't want them to be able to add multiple paragraphs!

If you find yourself in that situation when replacing textareas with wysiwyg fields, one reliable way around that is to use an html stripping plugin to strip p tags. Wygwam has a built-in parameter to do just that (Text-Only Mode).

But if you're only worried about extra paragraphs in Wygwam, not line breaks, you can approximate the EE textarea's "Auto <br>" format by creating a Wygwam editor configuration that uses CKEditor's enterMode config. Wygwam has a handy UI for setting CKEditor configuration options.

enter image description here


One thing I don't like about Wygwam (although I assume it's really to do with CKEditor) is that the source code formatting is a mess. I've been told that can be corrected, but the fixes I've read about didn't work for me.

  • As long as the source code is valid though, formatting shouldn't make any difference since your client is never going to see it. – Adrian Macneil Apr 16 '13 at 2:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.