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.
Comments
thanks for doing this. this will go a long way to quell complaints about an inconsistant wysiwyg experience when using CiviCRM vs. Drupal.
I've heard some folks express significant frustration about not being about to upload images from their local computer while composing CiviMail messages, creating Event pages, etc. Now folks using Drupal (with the additional modules documented by Matt) can do that, as well as browse and select from a library of previously used images on their webserver. AWESOME.
Note that this brings to Drupal installs a feature that has been available for Joomla installs as of 3.3. :-)
Hi,
Something I'd love to see it to inline some style when doing a mailing. Eg by default, a paragraph is without any styling and inherit from the css in the preview. However, some special mail client (outlook, I'm looking at you) is unable to apply styles and default to a lovely Times (or courrier) that makes everyone puke.
if I'd know that it's for a mailing, I'd add a style="something sane" on each paragraph that doesn't have it.
X+
Quickform knows about the form it's in but not the data to which it's connected unless you somehow add that meta onto the element itself. As a result you'd pretty much have to change every spot in the codebase where it creates a wysiwyg control.
As for the inline style convertor, I can't agree more. I've been trying to find some time to build something like that but just haven't gotten to it yet. I think it's best done as an editor plugin since you can easily find computed css through jquery for every relevant element.
This was one of the Make It Happens to which I contributed and I am really grateful to all the others who also did, as well as to the people who actually did the work. What would the scope of the project be to modify CiviCRM to support Drupal style input formats and filters? I would love to contribute towards that and would be willing to contribute seed funding.