From Aloha to CKEditor

In the summer, I announced that we would adopt Aloha Editor as part of Drupal 8. The primary reason was that Aloha was the only WYSIWYG editor that supported in-place ("true" WYSIWYG) editing; something we need to accomplish our vision for in-place editing. The Aloha Editor developers have been excellent in their attention to Drupal's needs. However, due to the nature of their editor being based around the concept of "true" WYSIWYG, we've run into some issues (which the Aloha Editor folks are actively working on) surrounding the user experience and accessibility of Aloha Editor when using it on the back-end.

Since that announcement, CKEditor has caught up, and now offers feature parity to Aloha Editor when it comes to our needs. Frederico Knabben, creator of CKEditor, has reached out to offer whatever support he can to make CKEditor and Drupal work together better. They already prototyped a convincing alternative to Aloha Editor's killer "Blocks" system (which is an excellent match for Drupal's need to manage content within text content in a structured manner). In addition to that, we found that CKEditor is more mature in terms of APIs, documentation, and ecosystem around the project. Hence, after days of research and weeks of further discussion, the consensus is that CKEditor is now our best choice.

Therefore, we are going to switch from Aloha to CKEditor for Drupal 8 core. By making this switch, we will not only have a more mature WYSIWYG editor, but we also free up resources to work on other parts of Drupal's authoring experience. The CKEditor team has committed to fix the 8 functional gaps that we've identified in their two next upcoming releases.

Last-minute decisions like this are never easy. But we make them in order to do what is best for Drupal. I'd like to thank both the Aloha Editor team and the CKEditor team for helping us evaluate both editors and working with the Drupal community on closing functional gaps. But don't take your eyes off Aloha Editor; it's an editor that continues to hold a lot of promise for the future of the web.

Comments

Wesley John-Alder (not verified):

This is an insane decision! There is absolutely no logical or modern rationale for this. There is no reason that your choice of *FRONTEND* text editor depends on *BACKEND* concerns.

If this is a "legitimate rationale", then there is a serious design flaw in either the backend or the frontend or both. If not, then please explain your "legitimate rationale".

The choice of text-editor should not be dictated by anyone except for the designer, and it should be a seamless operation to change vendors. To anyone who thinks otherwise: KNOW YOUR ROLE!

January 2, 2013 - 22:38
Jakub Suchy (not verified):

Wesley, we are discussing a default config. You will still be able to just take out CKEditor and install whatever editor oyu want.

January 3, 2013 - 09:35
marcvangend (not verified):

You are right, as long as you think about a text-editor as a stand-alone UI to insert arbitrary blobs of backend-independent HTML into a textarea. Personally, I am happy that Drupal core developers aim for a tighter integration that will really work. I think you will find more than enough rationale in the drupal.org issues.

January 3, 2013 - 09:59
Anonymous (not verified):

As choice in WYSIWYG is very much a developer choice as it is designer, this comment is ridiculous.

Aloha simply wasn't as pluggable into Drupal core as CKEditor as mentioned.

January 3, 2013 - 16:03
nod_ (not verified):

This isn't true. Please look up the comparison and the issue queue. Aloha is just as pluggable as CKEditor (one would even argue it is more so).

This particular criteria was a tie as far as Drupal is concerned and was not critical in the decision.

January 5, 2013 - 14:23
webchick (not verified):

Woah, there. :) Simmer down a bit, eh? :)

Dries's post refers to the default editor included out of the box in Drupal 8, in the Standard profile. You can still use Aloha, TinyMCE, Markdown, or "none" on your own site or in your own distributions. Drupal remains as flexible as ever for designers, site builders, developers, whoever, to make decisions that make sense for their own sites.

And I think there might be a misunderstanding about the term "back-end" in Dries's post. This is referring to the text editing form on pages like node/1/edit as opposed to the "click to edit here" in-line editing capability that's new to Drupal 8. It's important to have an editor that's strong in both, because you definitely don't want to have two different WYSIWYG editors (although you still could, if you really wanted ;)).

January 3, 2013 - 16:41
Ryan (not verified):

Well, if you intend to include one in D8, you may as well ship with the more mature option, right? Not that insane when you drop the caps and take a deep breath.

January 3, 2013 - 17:20
alexverb (not verified):

+1, I've been using CKEditor forever. I'm glad to hear I might be able to keep it with inplace editing ...

January 2, 2013 - 22:42
Dave.Ingram (not verified):

I'm excited about the change. I spent some time recently looking at CKEditor for a project and love what they're doing with in-place editing. D8 will be out of this world.

January 2, 2013 - 22:45
juan_g (not verified):

So CKEditor will be the default for Drupal 8, and it seems that Aloha Editor will still be one of the other available options via the aloha module.

January 2, 2013 - 23:05
Praha (not verified):

Sad for Aloha team but looking forward for next Drupal version. :-)

January 2, 2013 - 23:12
Dimitrij (not verified):

Good to know that, I like CKEditor, however is it still supports elfinder as well?

January 2, 2013 - 23:13
Chris Kirby (not verified):

I've always used CKEditor so I'm looking forward to it being included in D8!

January 3, 2013 - 00:08
androider (not verified):

Good to hear. Most sites use CKEditor.

January 3, 2013 - 01:54
Susan MacPhee (not verified):

Good choices, thank you!

January 3, 2013 - 04:31
Anonymous (not verified):

I for one am sad and happy at this news. CKEditor is a great WYSIWYG and is pretty solid. It has been my go to editor for my sites for the last few years. However it has a lot of baggage and feels like an editor of 10 years ago. Aloha had a modern look and feel. Feature wise they are comparable too. It feels like we are taking the easy road on this one. Furthermore CKEditor because of its prevalence has had more security exploits. Adding all of the new Drupal sites to these numbers means mops subtly more security threats. On a final note there was a recent release to the stand alone CKEditor module and 4x library that was an absolute mess. Resulting in broken sites everywhere. I know the CKEditor team maintains the stand alone CKEditor module so I expected a bit more testing before they pushed out ther latest release. If this happened when CKEditor is a part of core the result would have been disastrous. Just my two cents.

January 3, 2013 - 05:03
fredck (not verified):

As for "security exploits", I believe there may be some confusion here. CKEditor itself (not the CKEditor module) has never had such issues, especially considering that we're talking about a JavaScript application, which produced data is then sanitized at the server side.

I think the confusion is on understanding that CKEditor in D8 means merging the CKEditor module into Drupal as is. This will not happen, even if the quality of the module is great. That's because D8 has very different needs.

What is being developed is a brand new integration from scratch. In the Drupal side, the integration is to be handled (as it is now) by the Drupal community. So the quality of it is guaranteed. The CKEditor team will be the one working on the editor code only... so the quality here is guaranteed as well :D It's the best part of both worlds working together for the same goal.

January 4, 2013 - 18:51
greggles (not verified):

The ckeditor suite has had a security issue, in my humble opinion: the example code that ships with it included XSS. The cksource organization claimed that the example directory should always be deleted but if you look at various cksource websites (especially at the time I reported this vulnerability to you) you can see that they use the entire package including the examples directory. If the provider of the code doesn't follow this advice, who does?

In terms of this comparison: I didn't review Aloha to see if they also suffer from that problem. I did look at plupload and they also did suffer from it.

January 7, 2013 - 16:41
Anonymous (not verified):

I think security concerns are valid. The way CKEditors API's are built means the interactions with Drupal's filtering system are subtle and very difficult which what has lead to the module's problems. I know this has been a concern of the WYSIWYG team though for a very long time so I feel they are probably confident these are resolved.

January 7, 2013 - 17:21
Psy (not verified):

CKEditor is large and painful to configure for simple use in its current form. I should have a look at Aloha again.

If you are going to bake CKEditor into D8, please do something about the config, so its just a HTML editor and not a Word clone.

Anyhow I remain optimistic all things D8, which is looking very good already.

Psy

January 3, 2013 - 06:02
fredck (not verified):

Can you give us more details about the issues you are talking about? Is it about the amount of features of CKEditor? I'm sure Drupal will not drop all possible features there, having the optimal setup available by default.

In the other hand, what would be the Aloha features that you would propose CKEditor to have? The CKEditor team is certainly interested on making everybody happy here.

January 4, 2013 - 18:55
Alex Malkov (not verified):

It is a good choice though this editor is difficult for beginners. Two important points are to which it is necessary to pay attention, in my opinion:

  • Maximum-friendly manual is required in order to quickly set up the editor.
  • And also attentive testing is required from the CKEditor developers before making the following release.
January 3, 2013 - 09:52
fredck (not verified):

Most of the setup is supposed to be done through Drupal admin pages, so I'm sure that Drupal guides will be available for that.

As for "attentive testing", what exactly you mean with that? Every CKEditor release is preceded by an extensive testing phase, which includes automated and manual testing. Is it what you're looking for?

January 4, 2013 - 18:59
Angry Dan (not verified):

This is great news!

I had already started on something similar myself but stopped when a) I couldn't get it feature complete enough and b) I thought that at such a late stage in D8 dev you wouldn't want to be making such a significant change.

I'm happy to help with development on this, where do I start?

January 3, 2013 - 09:54
Kristian (not verified):

I am a bit divided on this issue.

On the one hand, I do not like such a last minute decision to change the editor. Everybody was getting into Aloha, learning to use and extend it. It seemed promising.

On the other hand, CKEditor has for the longest time been a great to use editor on Drupal and the new inline editing works great. It has more proven track record than the newcomer Aloha.

Now we'll just wait for the CKEditor team to finish the gaps and off we go!

January 3, 2013 - 09:54
fredck (not verified):

When it comes to the gaps, the CKEditor team is following that list strictly and working hard to have things clear with CKEditor 4.1. You can follow the work involved on it here:
http://dev.ckeditor.com/roadmap

January 4, 2013 - 19:05
yareckon (not verified):

Very sad for the Aloha team who changed their license to be included in Drupal. They can't take that back now, as there is now GPL2+ forks of their code out there. That's kind of a disaster for a previously AGPL project. I can imagine they are feeling betrayed and jilted. We as the Drupal community are not particularly reliable to work with, apparently.

On the other hand, I know that Dries has to do what is best for Drupal, and that CKEditor has promised (and delivered for the last 6 months at least) a lot of support and development resources. I just hope that we get the best user experience and code base out of this if we are going to be actually rolling a default editor into core.

About the frontend / backend comment above, I do have to point out that we do need to find one that works for both. Why would we try to include one codebase for frontend editing and another for backend editing? These are huge codebases, and we would do very well to pick ONE and stick with it. Sure they should be pluggable, but there's nothing worse than having two official solutions.

January 3, 2013 - 10:47
Dries:

It was a difficult decision, but the Aloha team has been part of every step in the decision making process. That process was very transparent, collaborative and collegial. In every way, the Aloha team was a pleasure to work with. They also recognize and support that we have to do what is best for Drupal 8.

Given more time, I believe Aloha could have closed the gaps with CKEditor. Unfortunately, we don't have the luxury of time at this stage of the Drupal 8 development cycle. First, helping Aloha mature is not the best use of our time and, frankly, very few Drupal contributors stepped up to help. Second, other important work is dependent on having a WYSIWYG in core and it wasn't smart to hold that up. By switching to CKEditor we can make more progress faster.

Depending on how Aloha and CKEditor evolve, we may reconsider Aloha for Drupal 9.

January 5, 2013 - 16:51
Ian (not verified):

Anything else then CKEditor would be a better choice. Ever looked at the front end code it generates?

Good for anyone annoyed by this: you will be able to turn it off!

January 3, 2013 - 11:18
fredck (not verified):

Can you point us the issues you have faced with it? Things seem to look fine, but maybe you're talking about some specific tc and this is not clear.

January 4, 2013 - 19:08
Dries:

There are many other factors to consider and we spent many days vetting and weighing many different criteria. The Aloha and CKEditor teams were part of that process along with various other experts. While I'm sure there is room for improvement when it comes to generated front-end code, it is shortsighted to reject CKEditor based on one criteria.

January 5, 2013 - 17:02
ảnh cưới (not verified):

I like CKEditor. I try using Aloha but don't like.

January 3, 2013 - 11:31
lolandese (not verified):

As long a GUI is offered (not yet) to set for using classes instead of inline styles.

Inline styling is usually the biggest drawback of Rich Text (WYSIWYG) editors.

Some related D.O. posts:

Thanks.

January 3, 2013 - 13:02
fredck (not verified):

Just to make it clear, the conclusion on the posts you have listed show that it is possible to do so with CKEditor. Even the video link shows how to do it properly, with CKEditor :)

January 4, 2013 - 19:13
Kevin Oleary (not verified):

Woot! I was an early adopter of Aloha and championed it for Spark but I have been really won over by the breadth an polish of the latest CK release. This will really dramatically improve the authoring experience for Drupal 8.

January 3, 2013 - 14:47
Anonymous (not verified):

I just understand what happened under the hood after reading the comparison chart, I'll miss Aloha a lot.

But people love Aloha editor at first sight. And the first impression last. Those stylish and cutting edge feeling on the front end.

To me it is hard for most users to feel that Aloha feel like ribbon UI and CKeditor look the same as the old Microsoft Office.

Please tell CKeditor to improve the design; its look is way too outdated and too monolithic. We are going to touch era, those design would look very outdated just when D8 is release!

January 3, 2013 - 15:40
fredck (not verified):

I'm sure this is all about personal opinions... but I love the new CKEditor 4 design (disclosure :D).

Anyway, it looks like the CKEditor will be well integrated in the D8 design itself, so it couldn't have a better fit.

In any case, CKEditor is skinable, which means that a Drupal dedicated skin designed by the Drupal community would eventually make sense, if necessary. Still this is to be checked once the integration will be in place.

January 4, 2013 - 19:26
Adam DiCarlo (not verified):

Dries,

I think you'd do well to more strongly call out the issue link where the decision was discussed, maybe with a summary, or at least guidelines for which range of comments are most relevant. I read the article and promptly forgot that link was there (I came back here to say you should add the issue link).

I know that the people involved are all brilliant and put a lot of thought and research into these decisions, so I trust it's well-thought out and is a long-term best interest for the project.

But -- simply from reading this post, I think we're not getting enough insight into the why of this decision; and most people are likely not to dig deeper into the issue link, or will be overwhelmed at the long page of comments if they do.

January 3, 2013 - 19:12
JOsh Beauregard (not verified):

After putting my hope and dreams, (and time) into Aloha, it's is dashed by the ever bloated CKeditor.

This is a poor and politically motivated decision. I hope what ever business this brings acquia is worth it.

January 3, 2013 - 21:11
deh (not verified):

CK Editor has almost gotten me fired because of the way it inconsistently mangles input from MS Word. The way it removes some spaces and alters text causes me to flow everything through Dreamweaver first, which always accurately converts the word format to basic HTML properly.

Maybe the problem is in Drupal config, maybe its CK Editor, either way its a pain, not easily solved and I'm sad to see Aloha go before it even had a chance.

January 3, 2013 - 23:10
fredck (not verified):

Still you're not pasting your word docs in Aloha :) That's because dealing with Word pasting is one of the hardest tasks for every browser based editor.

The CKEditor team has taking discussions with the Drupal community about this feature. New developments are already taking place around this, targeting CKEditor 4.1. This will be in good part handled at this ticket:
http://dev.ckeditor.com/ticket/9829

Still, feedback will be important after that, because shaping up the Word pasting feature is a continuous process. Very good support for it should land on D8 though.

January 4, 2013 - 19:34
webchick (not verified):

A lot of these negative comments seem based on the older CKEditor 3.x release. It's definitely worth taking a look at the newer CKEditor 4.x release, which radically cleans up the UI, introduces inline editing, and a host of other features. Similarly, the demo of the CKEditor 8.x code

It's also worth pointing out that this was definitely not a decision that was made lightly, nor was it "politically" motivated, nor any of these other things.

Discussion around this started over a year ago in DrupalCon London (August 2011) with quicksketch's core conversation: http://london2011.drupal.org/coreconversation/wysiwyg-editor-module and ensuing sandbox discussion: http://drupal.org/node/1260052

When we kicked off Spark, we did a similar analysis, but based around in-line editing capabilities: http://drupal.org/node/1580210 We did this separately, because at that point we weren't actually sure if we could pull off inline editing in Drupal, and didn't want to derail WYSIWYG in core efforts. And at that point (May 2012), Aloha Editor was the clear winner, and only logical choice. And the Aloha Editor team has been fantastic to work with, very responsive to our needs. This change in direction should not be seen as ungratefulness for their work at all.

However, due to the nature of Aloha Editor, whose focus is on making "true" WYSIWYG (in-line editing) as seamless as possible, there was quite a bit of catch-up work to do in terms of having it work well as a "back-end" editor as well (e.g. on node/1/edit and the like). Not every property in Drupal is visual (node published status, URL alias, etc.) and so you still need those back-end forms. Not being able to use the same WYSIWYG editor on both the front-end and the back-end is a critical, release-blocking consideration. And Aloha Editor had some work to do here; for example, in areas such as accessibility, providing mechanisms for deep customization of the UI, UX of insertion of images, etc.

Then around DrupalCon Munich (August 2012), CKEditor came out with the 4.x release which included inline editing and a new UI. CKEditor has approximately a 9 year head-start on making a great WYSIWYG editor to use on the backend, with a lot of these tough problems were already figured out, plus a huge number of community extensions already available, etc. So when we found ourselves more-or-less at feature freeze (November 2012) with many oustanding issues remaining with Aloha Editor's back-end integration, we were forced to take a hard look at what was realistic for Drupal 8.

We embarked on a feature-by-feature comparison between the two editors (https://docs.google.com/a/acquia.com/document/d/164Bm2KPAPelQj2fKauWlajD...), which involved representatives from both projects, as well as major Drupal contributors in the area of WYSIWYG. The results were basically that both editors have strong points and weak points. We still resolved to stick with Aloha Editor at that point, since it wasn't an open-and-shut case for moving from it.

However, the one blocking feature that Aloha had that CKEditor hadn't (a "blocks/widgets" system that allows for editables within editables, such as image captions) was addressed by the CKEditor team shortly after this comparison was put together, as well as a commitment from the project lead to do whatever was necessary to get CKEditor to work well for Drupal. Then the choice became a lot more clear: if we chose an editor for D8 with the back-end stuff already figured out, we could spend more of the remaining timeframe doing really deep, well-done integration in core or doing further UX improvements for Drupal itself, rather than spending that effort instead on improving the WYSIWYG editor in Drupal.

So this is mostly a timing / level of effort decision at this point, as it relates to D8's release timing. I have absolutely no doubt that Aloha Editor will close the gaps here in the coming months, and will be a very compelling alternative. And because of the investment both they and Acquia have put into Aloha Editor to this point, people can freely choose to use it instead of CKEditor in their Drupal sites if they prefer it (this would not have been possible without the license change, since AGPL and GPLv2+ are incompatible). But in the meantime, we the Drupal community can focus on making the out of the box WYSIWYG experience of Drupal as great as it possibly can be by choosing the more mature solution that removes a bunch of work from our plate.

Thanks a lot to the couple of people who've offered to help with this initiative. Here are the main jumping-off points:

- http://drupal.org/node/1833716 Blocking issue for CKEditor in core.
- http://drupal.org/project/wysiwyg_ckeditor D8 CKEditor code (requires that patch)
- http://drupal.org/node/1878344 Core issue for adding CKEditor to core
- http://quicksketch.org/wysiwyg D8 CKEditor demo site to try it out

January 4, 2013 - 10:05
alexverb (not verified):

Just wanted to point out it's still impossible to submit an HTML5 required field that's making use of CKEditor. I'm hoping this comment will get some attention on this popular discussion :)

http://dev.ckeditor.com/ticket/8031
http://drupal.org/node/1338956

January 7, 2013 - 09:55
adubovskoy (not verified):

We are using ckeditor for the last four years, out corporate drupal distributions have ckeditor "as default" for any user role.

I'm asking "why not ckeditor" last November - and answer was "haven't inline-editing". And then, in December we got ckeditor 4.x - with inline edit. I'm glad to read about ckeditor in core.

p.s. and in ckeditor we have already translate buttons and documentation for our language, in aloha we haven't yet. +1 for ckeditor

January 7, 2013 - 18:13

Add new comment

© 1999-2014 Dries Buytaert Creative Commons Attribution-NonCommercial-ShareAlike 3.0 License.
Drupal is a Registered Trademark of Dries Buytaert.