CiviCRM versions 3.4.2 and 4.0.2 include a new feature allowing administrators to configure CiviCRM to use Drupal input formats along with their associated WYSIWYG profiles as the WYSIWYG editor. This provides some great benefits for users:

• A consistent WYSIWYG experience for administrators who use both Drupal to work with content and CiviCRM
• The ability to write and use Drupal input formats to process text in a way already familiar for lots of developers
• When paired with a few other modules, a way to provide an integrated file browser and uploader right in the Wysiwyg editor when working with mailings, events, etc.

There's more complete documentation on the wiki, but I'll mention a few prereqs here. You'll need to have WYSIWYG API installed at a minimum. Also highly recommended are IMCE and IMCE WYSIWYG Bridge to enable a great integrated file browser, and pathologic to force absolute URLs (very important for CiviMail).

An important point to note is that using Drupal input formats in this context is a little different compared with how it works in native Drupal in a very important way. Drupal input formats are really output formats, which is to say generally speaking Drupal saves your raw input and applies the input formats when the text is output or displayed. This works great because it allows one to preserve editing hooks in the persisted code, like placeholders for images or templates, etc.

In CiviCRM however we don't have any way to facilitate that two-step process. If we want the benefits of input format processing at all, we have to apply the input formats to the submitted values and persist that value. There's two reasons for this: first, the editor is implemented purely as a Quickforms component, and there's no information in that context to allow us to persist the input format matched to a specific entity type, instance and field (for example, the html field of mailing ID 4). Second, there's no universal code path we could interrupt when the value is used. In order to use input formats and filters the same way Drupal does, we'd have to rewrite a lot of Civi code. Oh well...

The real downside of this gotcha is that many input filters won't work as expected because they'll only work one way. For example, turning on the pirate filter on international talk like a pirate day is great fun. In Drupal, you can simply turn it off the next day and all is back to normal. With Civi's Drupal-ish editor, you wouldn't affect any existing content by turning on the filter, and all content saved that day would be pirate-y, permanently.

I'd love to hear some feedback about people's experiences with using input filters and Civi together, or any ideas on how we could make this feature behave in a way more closely aligned with the native Drupal behavior.

This feature was sponsored by Kilpatrick Design.