We had already let you know that we would be using Aloha Editor as the WYSIWYG editor in Spark. In short: it has a very complete feature set, a proven plug-in system, solid cross-browser support, it can do “nested editables”, and so on; but most notably it’s the best WYSIWYG editor out there that can do “true WYSIWYG”.

Sprint

To accelerate the integration of Aloha Editor into Spark’s Edit module, we decided to do a code sprint with the Aloha Editor developers. Acquia flew out Théodore “nod_” Biadala and Wim Leers to Vienna (Daniel “sun” Kudwien unfortunately wasn’t able to make it), to hack three days (July 16–18) in a row to get us as far as possible. Three of the Aloha Editor developers were working full-time with us.
We’d like to thank Aloha Editor’s parent company, Gentics, for their generous contribution and amazing hospitality.

The most notable goals were:

• “perfect images + captions”: ability to easily add captions to images and align images, with the caption moving along with the image as the alignment changes (as described aptly by Nate “quicksketch” Haug in his DrupalCon London talk). This involved building a new “Aloha Block”.
• A proof-of-concept implementation of how editable “macros” (small pieces of text that are rendered into something else) in text fields would work. This again involved building a new Aloha Block, and we applied it for the most simple macros we could think of: Tokens, so we forked the Token Filter module.
• Integrate with their new version that stopped using ExtJS in favor of jQuery UI, which was also supposed to be much smaller (bytewise).
• Figure out how to reconcile Aloha Editor’s dependency management and Drupal’s dependency management.
• Figure out licensing issues.
• If sufficient time left: start building a custom UI.

I’m happy to say that we met all of the goals, and even went further!
We also built a working prototype of a custom UI. The awesome Aloha Editor folks also made it possible to simply type keywords when creating a link, which then uses Drupal’s node search to suggest links to the content that you’re looking for. They also wrote a plug-in for us that mirrors the HTML tags filtering mechanism Drupal uses — thus guaranteeing the same behavior1.
They kept their promise of about a month before the sprint: the jQuery UI version was ready, and the size was indeed significantly smaller2, more or less on par with other WYSIWYG editors.

Licensing

Also very noteworthy was the licensing question — Aloha Editor was using AGPLv3 and that was a problem. A FOSS license exception was already going to happen, but we wanted to make sure that that was going to be sufficient to support Drupal’s various SaaS products and seamless integration into existing sites.
At the sprint, Wim sat down with Haymo Meran (the director of the Aloha Editor association) and discussed the strict policies enforced on Drupal.org and how that has helped make the Drupal ecosystem thrive. Because that’s really what the Aloha Editor folks are after: making sure the Aloha Editor project is alive and well and getting contributions to make sure it remains relevant in the long term. They had chosen the AGPLv3 to ensure it would receive contributions. However, they already had been considering moving to GPLv3 (partially because many companies don’t want to touch anything AGPL).
On our side, we had understood the “FOSS exception” to effectively be a relicensing of Aloha Editor under the GPLv2+. But that turned out to be wrong: Aloha Editor would remain AGPLv3, with an exception that would allow us to include it and not “infect” the rest of Drupal.
To avoid licensing problems afterwards, we made sure not to commit custom Aloha Editor plug-ins we wrote during the sprint to drupal.org — we had a fork of th Edit module on GitHub were everybody had commit access to ensure maximum velocity.

After the sprint, further research within Acquia confirmed that if Aloha Editor would remain AGPLv3 then it would be impossible to use it in Drupal, even with the FOSS exception. It might have been technically possible, but we explained the importance of being able to say that everything on d.o is GPLv2+ — Dries felt it was paramount that this simplicity of licensing would continue to hold true.
A few days later, we got the happy news that they would switch to GPLv2+! Soon, they released their jQuery UI-based version 0.21.0, licensed under the GPLv2+!

We really want to thank Haymo and Gentics for their commitment to maximize the chances of Aloha Editor + Drupal being a happy marriage.

Ongoing collaboration

In the weeks after the sprint — and still ongoing — we’ve been working closely with them to fix bugs. All Drupal-related issues are tagged accordingly in their issue queue. They’ve again committed several of their developers to work full-time for a while to everything in tip-top shape.

Both Acquia and Gentics want to make sure this will be the best possible WYSIWYG experience for Drupal users, or really, of any website!

Please try out the latest version of Edit module and report feedback — the easiest way to do that is by installing the latest Spark alpha.

1. It is impossible to make security guarantees on the front-end (in JavaScript) — a malicious author/user can change any and all JavaScript. So this measure is not really for security, but rather to make sure that benevolent authors will see exactly what the end-users will get to see. ↩

2. In the pre-0.21.x releases, they used ExtJS instead of jQuery UI for their UI needs. An unminified Aloha Editor core + jQuery + ExtJS + require.js + no plug-ins, none of those gzipped, used to be a whopping 2.6 MB!
   Today, with their 0.21.x releases, they’ve finished the migration to jQuery UI and the sizes are down significantly: ±128 KB for Aloha Editor core, ±110 KB for browser compatibility libraries (that will no longer be needed when browsers get better), ±64 KB for the most important plug-ins (format/link/table). The sizes reflect ungzipped, minified (Google Closure Compiler’s simple optimization mode) JavaScript.
   That’s a total of ±300 KB, gzipped that goes down to ±80 KB. On top of that, there’s jQuery (±90 KB minified, ±33 KB if also gzipped) and jQuery UI (±450 KB minified) that are needed. Drupal already loads jQuery anyway, and Aloha Editor can use the same version (though it needs jQuery >= 1.7), so that doesn’t add weight on most Drupal pages. Only jQuery UI remains, and there we will also work with the Aloha Editor folks to make sure that if Drupal already loads it, that Aloha will reuse it. ↩

• Acquia
• Drupal
• JavaScript
• Spark
• WYSIWYG