Saturday, July 11, 2015 - 19:15
Written by

At the code sprint after CiviCon Denver, Tyrell Cook and I tackled some much-needed updates to Civi's wysiwyg system. A wysiwyg editor (what you see is what you get) is the mini word processor you use to compose emails, activities, notes, and other rich-text in CiviCRM forms. The old integration was written back in the days when CiviCRM wasn't so flexible (before extensions, or core resources) and aside from letting you pick between two editors, offered no other configuration options (e.g. to decide what buttons would be in the editor's toolbar). Plenty of room for improvement there, here's what we accomplished:

Configurable CKEditor

CKEditor is the most popular wysiwyg for the web and CiviCRM 4.7 now ships with the latest version. Better yet, I've just finished incorporating the new CK Configurator directly in CiviCRM and expanded it to allow selection of plugins and themes as well. It's pretty awesome if I say so myself, and you can take it out for a spin on the CiviCRM demo site. Under Administer -> Customize Data & Screens -> Display Preferences, click on Configure CKEditor and away you go.

TinyMCE in an Extension

Including more than one editor in the main CiviCRM download seemed excessive, so we moved TinyMCE into an extension, which you can download to keep using that editor in 4.7+. But we didn't stop there - the new wysiwyg framework in CiviCRM is totally extensible. Want to integrate a different editor? Just package it in an extension and off you go! (don't forget to share your work on the extensions directory).

No More Drupal/Joomla editor?

Ok, it's true, we got rid of the "Use Drupal/Joomla default editor" option. It was a maintanance headache for the core team and a pain for integrators too. I'm guessing that most reasons for using it had to do with configurability, which we've addressed with the CK Configurator, so maybe there isn't so much need for it anymore.

But that doesn't have to be the final word. If the Drupal or Joomla wysiwyg editor is a "must-have" feature for you, the code we removed could be easily added back into a module/extension. Want to help create or maintain that extension? Give me a shout on irc or email, or leave a comment below, and I'd be happy to help get you started.


Sounds great Coleman. I can't wait to check this out. These kind of usability improvements are key for making Civi more user friendly and thereby expanding the user base. Thanks for taking this on!

This looks like a great improvement. I already tried it out in the demo sandbox and am impressed.  Question: Where are the settings stored? I would like to automate (via Drush, or API, or hacking) turning on the "center" button/plugin (and a few other buttons) for multiple environments.

Thanks for this improvement for 4.7. 

Looks like the plugin that enables centering is called "Justify" and it's available in the plugin list so you can just pick it through the UI.

To answer your question, the settings are written out to a js file (which ought to be in /sites/default/files/civicrm/persist/ or thereabouts). You can edit this file manually (just don't use the configurator UI again or it will get overwritten) but sorry there isn't (yet) a way to load different config files conditionally. Let me know more about what you want to do and maybe I can help.

Coleman - What I am currently doing within a script for multple environments:

  • The plugin files named "", "", "" get extracted to  <drupal home>/sites/all/modules/civicrm/packages/ckeditor/plugins/
  • custom versions of "config.js" and ckeditor.js"  are dropped off at: <drupal home>/sites/all/modules/civicrm/packages/ckeditor/    (The only changes are those needed to enable the "find", "justify", and "colordialog" plugins. for the user

I am trying to plan what I would need to change in my script for version 4.7.

I would actually prefer to disable end-user access to the CKEditor "configurator" area, or at least have a permission to restrict who can access it. (If a techie user enables a bunch of plugins, other less-savy end-users will be confused and need additional training/help)   One of the nice things in the Drupal CKeditor configuration, is that I can have different editor configurations per role.  Since the CiviCRM editor can shown to anonymous visitors in a profile form, the editor config may be essential to control by roles. 



Sounds like 4.7 would allow you to simplify your script. The bower ckeditor package we use in 4.7 already includes those plugins, so your script doesn't have to touch anything in the /civicrm directory :) Just edit the custom config file generated by the configurator, and you're done. OR... better yet, you could not overwrite that file, just create a few copies of it with different names, and then use a simple hook to decide which file to use -- the way to tell Civi which config file to load is by doing:

 * Implements hook_coreResourceList
function myextension_civicrm_coreResourceList(&$items, $region) {
  // Override the CKEditor config file location
  $items[] = array('config' => array('CKEditorCustomConfig' => Civi::resources()->getUrl('', 'js/my-ckeditor-config.js')));

Bottom line - now you can swap CKEditor configurations on the fly using a hook without ever hacking or overriding any core files!

Maybe you could write an extension that implements this hook to provide a per-role config feature; might be useful to lots of users :)

You just made my day Coleman! I have exactly the same issue as Sarah and the hook is a BEAUTIFUL solution! Can't wait for 4.7 to be LTS now ... ;-)

Great idea to add the configurability -- the reason to add the use the default CMS editor is for staff training - if you have staff that is using an editor and was trained on it - adding yet a different editing interface could be challenging - 

That being said if it is an issue to handle the default editor so be it... 

Great work ...

Tyrell and Coleman, thanks so much for adding the configurability. 

Instead of creating a separate extension for each wysiwyg script why not create a geneic extension that would recognize any of the wysiwyg scripts and allow them to be dropped into a folder similar to the wysiwyg drupal module does.

That's an ambitious idea for an extension. The extensiability of wywiwyg editors in 4.7 would certainly allow you to do that. Could be quite a time-consuming project for you to write and maintain though. I'd say the maintainers of the Drupal wysiwyg module have spent quite a bit more than a weekend on it. Good luck!

Thanks, Coleman and Tyrell. I think this will greatly improve CiviCRM and hopefully solve a number of editor issues we have been struggling with. Very much appreciated!

CKEditor and links to Joomla articles

Although using the Joomla default editor has some drawbacks (templates, tokens not working right), one of the compelling reasons to use the Drupal/Joomla editor is that some of those editors are CMS-aware. E.g. JCK knows how to create a canonical link to an article, category etc. by selecting it in the "insert link to Joomla item"-menu.

Cross-operation between CiviCRM and the underlying CMS is important to us and limiting to CK does not solve that problem. I can't find a Joomla-aware add-on to CK which would solve it for real.

@thoni56 as I said in the blog, the code that was removed could be fairly easily added back into an extension. It sounds important to you, would you like help getting started with it?


just updated civicrm to 4.7.11 (in drupal). My wysiwyg in drupal is fine, but in civimail and civievent it is gone. I do see the display preferences and the option to select CKeditor. When I click configure the drop down menu is there, but nothing happens when I select.

permissions look fine..

any idea what the reason for this is?