quicksketch identified the following WYSIWYG editor libraries during his Core Conversation. Should any other editors be considered for evaluation? If so please provide an objective evaluation of why the editor should be considered.

  • TinyMCE
  • CKEditor
Members fund testing for the Drupal project. Drupal Association Learn more


webchick’s picture

http://aloha-editor.org/ (an HTML5 editor) has been getting a lot of buzz lately. Not sure at all about its accessibility and all that, or if it even makes sense. :)

webchick’s picture

And some code at http://drupal.org/project/aloha which I have not looked at.

mgifford’s picture

I've asked about accessibility - http://getsatisfaction.com/aloha_editor/topics/how_accessible_is_aloha

Great that it's HTML5 native.

mgifford’s picture

Also in thinking about other editor choices, the jQuery ones may be worth considering:


quicksketch’s picture

I should point out explicitly, that even if we did use Aloha or some other editor that touts "inline editing", I'm not going to be investing time into solving inline editing. This is an editor to replace textareas, not to provide inline editing. The problems of inline editing go far beyond the scope of what we're trying to accomplish, at least initially. Considering Drupal is "field based" more than other systems out there, inline editing would need to handle tons of things other than just a rich text editor. Inline editing of menu items, titles, authoring information, simple (text, select, checkboxes) and complex (date, time, file, image) fields and many other problems. Now, considering that's the actual scope of the problem, I don't think Aloha is a very natural fit anyway.

NikLP’s picture

Strongly recommend referring to an accessibility geek at the earliest convenience; @ezufelt is very switched on about such matters. I used to have a good skill set here but it's waned a little of late unfortunately.

For WYSIWYG in core I think two things are important; accessibility (natch) and simplicity. If the editor can be extensible with plugins etc (in /sites/*/libraries, of course, right?) then all well and good, but it really outta be ultra easy to use with minimal markup output. TinyMCE and CKeditor are both well used and supported, but I personally think the feature set is overly rich and cumbersome.

Other junk: "more info" about formatting options (on all textareas as we know) has been irritating in the past, enabling/disabling rich text formatting might want a permission (some users just can't cope with seeing source), mobile friendly of course would be helpful!

Just doing my usual trick of emptying my head into a core issue... :P

Everett Zufelt’s picture

+1 that the editor must be mobile friendly (whatever that might mean objectively).

Hanno’s picture

@quicksketch we don't necessary need the Aloha editor on the node view page, if we include this editor on the node/edit page only, I assume it will behave the same as the other candidates.

effulgentsia’s picture

The problems of inline editing go far beyond the scope of what we're trying to accomplish, at least initially.

I agree.

Now, considering that's the actual scope of the problem, I don't think Aloha is a very natural fit anyway.

I disagree. I second #8: unless someone can explain why Aloha is inferior to TinyMCE and CKEditor in the limited use-case of replacing textareas, I'd like it to be a contender in this discussion. If we're about to add an editor to core, it would be great to use one that is lightweight, html5 optimized, and capable of supporting inline editing via future D8 contrib modules or D9 core. However, if Aloha *is* inferior to these other two for textarea replacement, then ok, let's stick to one of the other two, and let people swap in Aloha via contrib.

quicksketch’s picture

I second #8: unless someone can explain why Aloha is inferior to TinyMCE and CKEditor in the limited use-case of replacing textareas, I'd like it to be a contender in this discussion.

Until Aloha matures, I think we will encounter some significant issues with implementation. Take a gander through this forum post for example. Not being able to insert an image seems like a pretty big problem. http://getsatisfaction.com/aloha_editor/topics/how_do_i_insert_images_an...

The most recent commenter:

Well, got my hands on aloha and now im stuck with images, seems after one year inserting and basic image manipulation is still buggy as hell, will require a lota of jQuery acrobatics before i get it work. I'm testing it in 3 different browsers (Safari, Chrome and FF) and the behaviour of the image plug-in is un-predictable, and possibly unusable for production purposes, that's a pit because aloha is a nice editor ...

Aloha will probably be a very nice editor eventually, but I'm worried about the maturity of the project at this point. But that said, I don't really want to eliminate it as a choice either without some solid reasons.

droplet’s picture

- Core files too large. over 1.6MB
- missing plugins
- too young

klonos’s picture

...I'd like to point two facts that make me lean towards CKEditor:

1. User base:
- 6.x counts ~100k users (including the old FCKeditor ones) - that's a little more than 30% of D6 installations.
- 7.x counts ~60k users - ~20% of D7 installations

TinyMCE counted ~10k installations for D5 or D6 at its maximum if you take a look at the history of its usage graph.

I am aware that a huge amount of users have switched to using WYSIWYG API and there currently is no way to tell which editor its ~200k user base prefers. In cases like this, I wish that this series of features were implemented:

#1036780: Drupal.org should collect stats on enabled sub-modules and core modules
#1274766: Collect stats on enabled sub-modules, not just projects
#1273344: Establish heuristics for core feature evaluation
#1439316: Provide means for module maintainers to collect heuristics on certain settings of their modules.

...so we could eventually enable some kind of anonymous feedback on which WYSIWYG editor library most people actually use. Which brings me to point #2...

2. They built their website on Drupal!

jerryitt’s picture

31.73 KB
66.6 KB

My personal choice is CkEditor but TinyMCE is equaly as good in my opinion. It comes down to personal taste I think.

I have used http://drupal.org/project/aloha on several projects and while it is bigger than other editors and I agree needs some work. It is a way easier to extend and theme than Ckeditor or TinyMCE. Plus as far as I have seen there is no issues as far as mobile is concerned. Where as with Ckeditor & TinyMCE there is. Also it is much quicker a much more plesant experience to use.

I dont see why we need to pick one content editor to be included in core at all. My Understanding is that the Drupal 8 Core Initiative's is to make core as lean as possible, adding an editor to it is in my opinion going backwards. For one not everyone will be happy with whatever editor we choose. Sure we can swap the default editor out for another editor but is this just adding an unnecessary step?

Just to clarify

    WYSIWYG in core. YES.
    CkEditor,TinyMce or any other editor in core. NO

    What I would like to see is something like this.

      When installing Drupal users are presented with a recomended WYSIWYG editor but are also given the choice to install any of the other editors supported by the WYSIWYG Module.

      To list a couple currently supported

        YUI Editor

        When they choose there preferred editor it will be installed to the "sites/all/libraries/" folder.
    Would this be a better way going forward to handle this?
    Take a look at the mockups i have.
webchick’s picture

No, that choice will make absolutely no sense to the vast majority of humans, and even more technical people probably don't even understand the difference between all of those options. (I've never even heard of two of them, myself.)

Additionally, it's much more challenging to code, maintain, and support multiple editors than a single one. So Drupal core should be opinionated here and pick one, but make it easily disablable so if someone wants a different editor they can.

jerryitt’s picture

Correct me if I have made the wrong assumption here but just to clarify are we talking about having wysiwyg "http://drupal.org/project/wysiwyg" and which ever editor library in core or just the editor module itself?

crimsondryad’s picture

My understanding two years ago was that TinyMCE's team only consisted of 2-3 people and wasn't releasing on a regular schedule. CKEditor had a larger team and was releasing more often. That was why we chose CKEditor at the time. However, looking at their site, it looks like they've been releasing pretty consistently on a monthly basis the last 2 years. I was not aware that Wordpress was driving this development.

I do agree with webchick that the community will drive the decision. All I really want is a secure, scalable solution that will be well supported. At this point I don't really care which it ends up being, so long as it is easy for me to change my mind if needed. Whichever one gets chosen, we will all need to commit to pushing the dev of that solution and keep it viable.

CKEditor 3.6.3 put this out on a release (http://ckeditor.com/blog/CKEditor_3.6.3_for_Drupal_released):

Starting from this release, a new security filters policy that protects you from executing malicious code that is already in your database was introduced. In order to configure the security filters, enter the profile configuration for the CKEditor module and go to the Security section. The CKEditor for Drupal module includes built-in support for some popular security filter modules which you will need to download and install by yourself first. Detailed information about the security filters policy as well as supported modules is available in the CKEditor module documentation.

I really like that option. What I don't like is that there are parallel modules and that CKEditor does not put their CKEditor for Drupal module on the Drupal.org site. Duplicate efforts and confusion, not to mention it doesn't allow the normal community security review process. Does it alert on the available updates page if there is a new release?

mariomaric’s picture

@crimsondryad: Well, as far as I can see (by diff) there are really small diferences between http://drupal.org/project/ckeditor and http://ckeditor.com/ckeditor-for-drupal.

With module from their site you get also CKEditor library...

Anna_CKSource’s picture

I really like that option. What I don't like is that there are parallel modules and that CKEditor does not put their CKEditor for Drupal module on the Drupal.org site. Duplicate efforts and confusion, not to mention it doesn't allow the normal community security review process. Does it alert on the available updates page if there is a new release?

Just to explain, the CKEditor module comes in two flavors, as explained here: http://docs.cksource.com/CKEditor_3.x/Howto/Drupal_Installation

The Open Source version is (and will always be) available directly on the Drupal.org site, see http://drupal.org/project/ckeditor
The module itself is fully available for community review and the new security filter policy was in fact introduced under the scrutiny of the Drupal security team.

The second, commercial version consists of the very same Drupal module and the only difference is in including CKFinder and customer support. The reason for this is that CKFinder itself is not Open Source, so it would not be possible to add the whole package to the Drupal.org repository and some people simply prefer to get both pre-configured and working out of the box.

To sum up, both modules are really the same code, with the same bug fixes etc., including the new security filters policy.

crimsondryad’s picture

Thanks for clearing that up. Maybe a note on the Drupal.org project page explaining the difference would be a good idea.

effulgentsia’s picture

Correct me if I have made the wrong assumption here but just to clarify are we talking about having wysiwyg "http://drupal.org/project/wysiwyg" and which ever editor library in core or just the editor module itself?

If you have an hour to spare, please watch quicksketch's London talk that's on this issue's parent project page. His vision is not just adding wysiwyg module and an editor, but about solving some major current usability problems by adding Drupal integration code: a client-side filter system to complement our server-side one, unifying wysiwyg toolbar and filter system configuration, and solving the problem of having image captions move with the image when an image is moved within wysiwyg.

My Understanding is that the Drupal 8 Core Initiative's is to make core as lean as possible, adding an editor to it is in my opinion going backwards.

Different people have different interpretations of lean. A lot of work is being put into refactoring core subsystems and modules to not be unnecessarily coupled with each other. Work is also being put into making more code lazy loaded, so that on any given page request, only the code that's needed is loaded into memory and executed. Related to that, people are working on routing and caching improvements. For mobile device optimization, people are working on ways to make our markup, JS, and CSS lighter. And we have, and will continue to have a Minimal install profile and a Stark theme for people who want a bare-bones starting point from which to build their site.

However, regardless of how lean we want core to be, it needs to solve its primary intended use-case: managing content, and for a very large number of people, that requires wysiywg editing. I don't see that as going backwards, I see it as Drupal maturing at solving its primary use-case, just like when D7 core finally added the ability to add an image to content and have it displayed as an image.

Seb_CKSource’s picture

In the end it comes down to preference, but this preference can be unjustifiably biased, especially when your argument is wanting a "lite" editor. CKEditor's default package shows its full potential but the editor can be as lean as you want it to be. I'm in a position to know just how often people find crazy new ways to use CKEditor. Lean? Ya, it's that too. The question is: do you want users to have something lean that's inherently customizable or something inherently lean?

crimsondryad’s picture

The question for me is what will people want to use the most. If they're just going to ignore the default and install another one the majority of the time, then it defeats the purpose. Also, how can you get the most bang for your buck? If the leaner solution won't fit the larger number of use cases, I don't really consider that to be a win.

I was just reading webchick's new Using Drupal book and in it she mentioned that CKEditor was chosen after an extensive review as the most full-featured editor. So it seems like a win to me. Kind of like Views....you get 3 or 4 modules with it. The vast majority of people are only going to use Views and ViewsUI and they can enable just what they need. Drupal comes with syslog capabilities in core too...and the user can choose to turn it on if they need it.

lightsurge’s picture

In terms of Aloha, there's some discussions around compatibility/accessibility here #1018352: Add editor: Aloha Editor where it seems there might be degradation problems in older browsers, and some talk on inline editing here #1514272: Inline Editing and the WYSIWYG module

@quicksketch #10

Not being able to insert an image seems like a pretty big problem.

As far as aloha itself goes, I think this issue has been resolved now, see end of comments in http://getsatisfaction.com/aloha_editor/topics/how_do_i_insert_images_an...

Of course I suppose that doesn't mean it's going to be easy to hook it into a Drupal media management system, though #1502670: Image support

@droplet #11

- Core files too large. over 1.6MB
- missing plugins
- too young

In terms of size - I can see how this might be an issue for users on slow connections, or mobile data, especially roaming... But in terms of performance, even if the core files for the other editors are smaller, the techniques of other wysiwyg editors around using iframes etc have their own performance pitfalls that aren't represented in the length of the code? Aloha's own analysis shows good comparative performance http://aloha-editor.org/benchmarks/analysis.php

I like aloha and from a UX point of view at least, and in my not particularly expert opinion, it rather feels like the future of wysiwyg editors... perhaps that means the other editors will follow suit and future versions might be taking a similar direction, although I can't find any reference that suggests this. In any case, with WYSIWYG, because it seems to be an especially difficult thing to make anywhere near fine art, it would be good to see Drupal weight this particular decision with a riskier than usual splash of innovation along with plain stability, being as whatever it chooses to take on will likely get a boost of investment in bug-fixing and improvement anyway.

But there is that download size issue with aloha :/

lightsurge’s picture

Some info on compatibility here https://github.com/alohaeditor/Aloha-Editor/wiki/Browser-Support

I don't think that's a bad range of compatibility. I think IE7, for example, has to be supported by Drupal, but to only offer WYSIWYG editing to users of newer browsers seems perfectly reasonable to me.

David_Rothstein’s picture

Drupal 8 will no longer support IE7 (except in an extremely minimal way), so having the WYSIWYG break there should not be a problem: http://drupal.org/node/1569578

droplet’s picture


No, other editors are more lightweight:


488.7KB (non-GZIP)
163KB (GZIP)

Original Size: 364.62KB (116.43KB gzipped)
Compiled Size: 352.49KB (110.54KB gzipped)



It's crazy, there demo page loaded 3818.8K JS files

(it may need 2 or 3 required files, im not sure)

** Compilation did not complete successfully. See errors pane for details.
Original Size: 1.6MB (352.75KB gzipped)
Compiled Size: 0 bytes (20 bytes gzipped)

uglifyjs: 765KB
gzip -9: 217KB

lightsurge’s picture

More lightweight in size of code, but by its nature because the code only needs to load once, rather than in each iframe as with many other editors, if we have say 3 or 4 iframes on a form with wysiwyg content (for fields), a gzipped aloha in your example could potentially be better performing only taking javascript into account (and loading the CSS in each iframe will also have a performance hit, as well as using iframes at all having a performance hit on the browser).

I agree though the code is unusually bloated. However, it looks like the intention is to make it possible to minify https://github.com/alohaeditor/Aloha-Editor/issues/493 and also swap extjs for jqueryui, aiming to reduce the file size further by June https://github.com/alohaeditor/Aloha-Editor/issues/55


@quicksketch #5

Considering Drupal is "field based" more than other systems out there, inline editing would need to handle tons of things other than just a rich text editor.

For the above reasons, perhaps aloha is actually a better choice for field-based systems like Drupal, since iframe based editors are most in their element when only used sparingly on a page?

lightsurge’s picture

Might also be worth mentioning that I've read there'll be (or may already be, off-hand I only have an old reference to it here http://www.drupal4hu.com/node/292#comment-1550) a standalone core aloha where a custom, simplified UI could be added... which may have benefits in terms of drupalising the interface. Although, I suppose that would mean another core submodule and maintenance burden.

lightsurge’s picture

Another HTML5 editor (which I've only demoed) http://jejacks0n.github.com/mercury/

Edit: but doesn't support IE8, so not feasible

lightsurge’s picture

I've been playing with Whizzywing (new version of Whizzywig)... no iframes... For 17kb, I'm really impressed, and it's not at all far from delivering an interface like the one in #1586404: Revamped WYSIWYG designs.


Wim Leers’s picture

For the Spark project, we're also looking for a WYSIWYG editor. However, for the Spark project, the WYSIWYG goal is somewhat different. Please see #1580210-4: Figure out what WYSIWYG editor to use and give your feedback!

Thanks :)

medden’s picture

Can I put in a recommendation for https://github.com/xing/wysihtml5

What you see is HTML5.. I made a patch for a plugin for this in the wysiwyg issues queue, so it works in drupal.

Cleanest, and most semantic WYSIWYG editor I know.

cosmicdreams’s picture

for wysihtml5, the speech input is awesome

bartvdputte’s picture

*untested*: http://redactorjs.com/ looks nice too. At first site it depends on an iframe as well.

wysihtml5 gets my vote, but as stated above: it should be easy to toss out the "default wysiwyg" for another you'ld like to use for some kind of reason...

RobW’s picture

Another vote for wysihtml5.

  • Toolbar at and buttons are extensible and very easily themeable (they're just HTML links in a list),
  • it produces html5 output (which CKEditor and tinymce don't right now),
  • it's very light kb wise,
  • which makes it mobile friendly.
  • All of this seems line with key initiatives set out for D8.

There are some issues, the biggest of which is that it produces br's instead of p's by default right now, but there's a very active request to reverse that and a couple forks working on it.

Aloha is a non starter for me -- whatever else it does, the floaty toolbar's poor usability and the +1mb size make it completely unusable on my client projects. There's a lot of love for it over in the Spark issue queue (the issue in #31), which mentions that the goal is to roll Spark and the editor chosen there into Drupal core. Should these conversations be combined if one is eventually going to overwrite the other?

crimsondryad’s picture

@RobW Are you sure about that? CKEditor announced initial support for HTML5 in version 3.6.1 http://ckeditor.com/node/572

So my preference would be to go with a better known solution with the more active community. I don't think HTML5 output should be the deciding factor because by the time D8 releases ( earliest 8/2013 ), the gap will likely be a lot smaller or non-existent.

quicksketch’s picture

Yeah both CKEditor and TinyMCE can output "HTML5" (that is, code without <font> or <align> tags). It's all a matter of configuration. I regularly configure TinyMCE to use classes for left/right aligning instead of style attributes, but you really can make just about any button use any format. Copy/paste is the real pain in the bum for any WYSIWYG, since they have to "cleanup" the bad HTML that something else generated. Both editors also include cleanup routines, though effectiveness still varies based on your configuration.

RobW’s picture

You're both right, I conflated my editor and sanitizer experiences. Sorry about that.

mori’s picture

I am very satisfied with the CKeditor and besides the CKfinder.

In mind that D8 should have a much better media/file/asset-managment, the editor should work fine with it.
In my opinion these topics are important:
- internal linking to nodes (autocomplete & preview)
- preview of media-assets e.g. pictures, nodes

seutje’s picture

Not sure if it's been noted, but Aloha supports textarea editing just fine.

Another thing worth noting: Aloha will only become smaller, not only because of refactoring of the code, but also as browsers start implementing a standardized and extensible execCommand system, a bunch of the polyfilling/normalizing code will most likely be dropped.

Regarding the floating menu thingy: This is purely cosmetic and rather easy to override.

crimsondryad’s picture

I don't recommend adding CKFinder into core. That particular piece of software is not GPL'ed and requires a license.

Better media/file/asset management is a benefit. Media seems to be maturing rapidly in that role. However, I don't know that Media is ready to hit core. So perhaps try to ensure that enabling Media ( or anything else ) is easier to do is sufficient.

One of the biggest pain points for me has been doing text format config and then having to do it AGAIN for the WYSIWIG. If we can integrate those or at least make the experience more seamless it would be truly awesome. At the risk of hi-jacking the thread, brings up another point. With many WYSIWIG editors, the input format options are either "everything" ( ie, full html ) or don't use it. Is there a way to allow the WYSIWIG to do what it needs to without allowing inline script tags? And/or js? I've been looking at HTML purifier ( and several others ). The config is heinous.

mori’s picture

lightsurge’s picture

Raptor editor got some interest in the Spark wysiwyg issue #1580210: Figure out what WYSIWYG editor to use, might be worth considering that here if there's still time?

crimsondryad’s picture

Aloha was chosen for Spark, but Quicksketch has some legitimate concerns about the maturity level including package size and bugs with image insertions.

I have a very serious concern about Aloha. I just checked the license and it's under the AGPL. Our corporate policy patently prohibits the use of any software under an AGPL license. Is Aloha going to change their license to run as GPLv2 or GPLv3 for inclusion into Drupal core? Or is Drupal going to change their license to AGPL? Corporations do *not* like AGPL licenses because it blankets everything it touches under that license. This license was specifically designed that way after Linksys used Linux on its routers but it reaches way too far.

If that does indeed happen, many companies offering Saas type products are going to go to another content management system because legally we won't have any other choice.

RobW’s picture

Aloha maintainers have agreed to grant a Drupal specific Aloha GPL license. It's in the Spark thread somewhere.

webchick’s picture

The package size concern is being addressed with a move of Aloha to jQuery UI instead of ExtJS. My understanding is this is very close to completion and under active development at https://github.com/alohaeditor/Aloha-Editor/tree/dev-jqueryui-ultra.

License-wise, we'll need to apply for a "FOSS license exception" to distribute the code under "GPLv2 or later" (same as Drupal's license), but they offer such exemptions to open source projects. See http://aloha-editor.org/license.php for examples.

Members of the Spark team and Drupal core JS maintainers are going to be meeting with Aloha developers next week in Vienna for a three-day sprint to work through a variety of architectural issues, including image/caption insertions as well as tokenized strings and other challenges. We'll post a public status report after the sprint, and likely a crap-ton of issues in the queue. :)

lightsurge’s picture

@RobW I might be getting confused here but as I understood it, the FOSS exception only allows Drupal to ship Aloha+Drupal as a single package, with Aloha remaining AGPL, and Drupal remaining GPL, without it becoming a derivative of Aloha and therefore being consumed by AGPL as well.

AGPLv3 has that protective clause against hosted web services such that even if they're not distributing their code (because they don't have to, they're remote, no actual file downloads involved just responses from some server side beast), they still have to make their source code available in some form. Crazy example - if the installable binary OpenOffice were GPLv2, and I made some derivative of it that which was like GoogleDocs, a public hosted web service, I probably wouldn't have to cough up the source code, because I'm not distributing the code. If it was AGPLv3, I would.

So any modification directly to Aloha by a site-owner I imagine would still mean having to make downloads of that particular bit of Drupal available. But I'm guessing this FOSS exception means any plugins or code that interacts with the Aloha API via Drupal would be immune from this, though I find that a bit confusing :/

Edit: Edited 2nd paragraph with example.

RobW’s picture

Thanks for the clarification. When I read "Drupal GPL exception" on the Spark thread I didn't realize it was that complex.

lightsurge’s picture

@#48 yeah it is a bit weird. Its made difficult to explain because of the difference between say a C++ application compiled into binary (if I make a derivative of a GPLv2 product, if I distribute the binary publicly, I also have to make available the source), and say an application built on php code (if I'm 'distributing' a web service publicly, i.e. running a public website, if it's a derivative of a GPLv2 product I don't have to make the source available, but under AGPLv3, I do.). The GPLv2 license protects well against 'compiled' or 'minified' derivatives that are being publicly distributed, but doesn't protect amply against public remote services, which I suppose is why the clause was added in AGPLv3.

crimsondryad’s picture

lightsurge, I agree. AGPL is a legal morass that will likely result in companies not using Drupal because they don't have the time / funds to figure it out.

It's also a pain in the rear to have to provide links to source code to the public if Aloha ( for example ) is only being used by internal site editors.

Additionally, most security experts recommend you *don't* advertise what version / program you use as it can be a backdoor into systems.

I had hoped that the agreement with Aloha would prevent this mess, but it doesn't sound like it will.

webchick’s picture

I'm not sure where lightsurge is getting his information, but "Sort out legal BS" is officially on our sprint agenda, so we'll report back what we hear from the Aloha folks.

Wim Leers’s picture

What Angie said. We want to make sure there is total clarity about this, with no room for FUD left :)

lightsurge’s picture

I'm not sure where lightsurge is getting his information

Indeed, I may be getting it completely wrong, I tried to absorb as much as I could without giving myself indigestion, but given the complexity of licenses I don't think on a personal level anybody could be blamed for getting the wrong idea, but they certainly could be blamed, if they broke the license ;)

Certainly it's clear on the Aloha website that Aloha remains AGPLv3 in a FOSS exception package:

You need a FOSS license exception to distribute Aloha Editor with BSD, MIT or similar licensed software. Eg. Locomotive CMS is MIT, Aloha Editor is AGPLv3, with the FOSS exception, Locomotive CMS can distribute Aloha Editor and remain MIT, but Aloha Editor will remain AGPLv3.


Having said that, the above FAQ is confusing in terms of:

Do I need to publish modifications to a GPLv3 server side component?
No, you do not need to publish those changes. The GPL does not require you to release your modified version, or any part of it. You are free to make modifications and use them privately, without ever releasing them. This applies to organizations (including companies), too; an organization can make a modified version and use it internally without ever releasing it outside the organization. But if you release the modified version to the public in some way, the GPL requires you to make the modified source code available to the program's users

It's confusing because it's right in one way, under GPLv3 you don't, but under AGPLv3, surely you do, even if it's server-side, using them remotely is counted as distributing those server side components publicly, effectively:

In 2007, the Free Software Foundation released a variant of the GPL called the GNU Affero GPL (http://www.fsf.org/licensing/licenses/agpl.html)[31]. Its purpose is to enforce GPL-like sharing provisions on the growing number of companies that offered hosted services—software that runs on their servers, that users interact with only over the network, and that therefore is never directly distributed to users as executable or source code. Many such services had been using GPL'd software, often with modifications, yet didn't have to share their changes with the world because they weren't distributing any code.

The GNU AGPLv3's solution to this was to take the regular GPL and add a "Remote Network Interaction" clause, stating "...if you modify the Program, your modified version must prominently offer all users interacting with it remotely through a computer network ... an opportunity to receive the Corresponding Source of your version ... at no charge, through some standard or customary means of facilitating copying of software." This expanded the GPL's enforcement powers into the new world of application service providers. The Free Software Foundation recommends that the GNU AGPLv3 be used for any software that will commonly be run over a network.


crimsondryad’s picture

Definitely don't want no FUD. :) I'm just asking that we help folks who will have justifiable questions be comfortable with this decision.

The problem is that AGPL is very broad in what it labels as a "derivative work". For web sites, the line between what is content and what is code is pretty clear. However, when you start talking about Drupal as a framework for web applications, that line blurs very quickly. Being forced to distribute our server side code to customers would seriously impact our revenue.

I need to be able to convince executives (and our legal counsel) that AGPL doesn't represent a risk to our business.

mgifford’s picture

I added a few issues to the Aloha-Editor issue queue. It's got some serious accessibility limitations. It's not clear that you can use it without a mouse. Certainly a screen reader user would have to be just guessing if they can navigate it at all.

Wim Leers’s picture

Please don't try to spend too much time analyzing Aloha Editor in its current state. Soon they'll release a new UI (based on jQuery UI), which is likely going to change everything. Hopefully in a good way :)
Don't get me wrong, I'd *love* to see your thoughts and analysis. It just doesn't make sense to spend a lot of time analyzing their current release, that's all!

Could you perhaps link to those issues here?

mgifford’s picture

I took a quick look of the demo. Looking forward to seeing the new code. Just wanted to raise it as an issue to be watched. I'll wait to post the issues against the new version when it is out.

Wim Leers’s picture

Great, thanks! :)

effulgentsia’s picture

crimsondryad’s picture

I saw that! Thanks to the Aloha team for changing the license. :) It seems like Webchick really really likes Aloha. They're committed to using it for Spark. I haven't actually used Aloha, so I can't say if I like it better than CKEditor at this point.

So now that the license issue has been resolved, we're back to the original questions:

1. Concerns about Aloha size: According to the link above by effulgentsia, the new release got the size down to under 764K with the entire package unpacked. They switched to using JQuery UI, which means the core version won't need to load that separately, which gets the size down a lot further. So we're calling this myth busted!

2. Concerns about Aloha maturity: Well, this still seems like a valid concern, but it also seems like Angie and others are forging ahead and whipping Aloha into shape. Will Aloha in core go into feature freeze at the same time as everything else? If it does, there are 4 months to shape it up. If Aloha doesn't go into feature freeze, it will have a year to solidify. Considering the current momentum, maybe this won't be a big deal by then.

Soo....thoughts? How can we get this moving towards a final decision?

quicksketch’s picture

@crimsondryad: I've been participating with the Spark team on WYSIWYG implementations (led by Wim Leers), and I'm also coming around to the Aloha camp, though maturity is still a big problem. @sun (the maintainer of WYSIWYG module) also seems to be warming up to it based on its API an implementation (though adequate documentation is a serious problem). It's looking increasingly likely that Aloha is going to be the way forward, though that punches huge holes in the approach I'd proposed in London (as seen on the project page http://drupal.org/sandbox/quicksketch/1088256). My approach had been a "let's get what we know works into core". The new approach is more like "let's rewrite everything entirely". Given Drupal's history of taking the more aggressive "rewrite/reinvent" approach, I can't say I'm too terribly surprised.

The new approach isn't necessarily a bad thing. It's certainly more ambitious and will require significantly more work. Also because it's being implemented as part of Spark (which means it'll have to run on Drupal 7), we can expect that the WYSIWYG integration will be more loosely coupled than had we taken my approach, which was to integrate deeply into the filter.module.

Right now I'm having a hard time building any motivation for my approach, considering Acquia is putting significant resources into Spark and the Drupal 8 WYSIWYG approach that derives from that project. Considering Spark *must* move forward because there are resources dedicated to it, there's little reason to attempt to compete with the WYSIWYG approach it is implementing.

That said, I think the Spark approach *is* probably better. It's just less likely to be completed on time because it's a lot more work. However they also have a lot more resources, so those could balance out and we'd end up with an awesome system in Drupal 8.

My recommendation for this project is that we collaborate in the Spark issue queue http://drupal.org/project/issues/spark, and help move that project forward as quickly as possible to overcome the increased effort required. Though we may still use this project as a staging area for improvements that need to be made regardless of the WYSIWYG chosen, I think pursuing my original approach further will be a dead end in the Drupal 8 release cycle.

Wim Leers’s picture

I'm happy that you're warming up for Aloha Editor, quicksketch, but at the same time I'm saddened that the time and work you've already invested may be in vain. Please know that we've learned a lot from that DrupalCon London talk you did; our approach to get image captions done right is 100% based upon what you said in that talk. There's currently bugs in our "perfect images + captions" (#1699740: "Perfect images + captions") implementation on the Aloha Editor side, but they're working on fixing those. Once those are fixed, I'd love to sit down with you to make sure it matches your requirements. For the server-side implementation of that (i.e. a filter that transforms <img src="…" data-caption="This is the caption" /> into an image with a caption, I'm trying to reuse as much of http://drupal.org/project/caption_filter as possible.

Further, I want to stress that the reason that Spark settled on a different WYSIWYG is because we had a different end goal: we didn't want "just WYSIWYG on the back-end", we wanted "true WYSIWYG on the front-end" *and* "just WYSIWYG on the back-end". The former goal prevented us from using the more well-known Drupal WYSIWYG editors, such as CKEditor.
Also: I'm the only developer on Spark's Edit module and WYSIWYG editing, but we are collaborating with the Aloha Editor folks, which of course helps tremendously.

I'm very curious to hear and/or read more about why you wanted the WYSIWYG editor to integrate deeply into the filter system. Should I watch the DrupalCon London talk again, or where should I look? What do you then think about my proposed "classification of filters" approach, as outlined in #807996-15: [meta] Input filters and text formats? Does it make sense to you because the envisioned way of integrating a WYSIWYG is different; possibly because you wanted to remove the ability to switch to another WYSIWYG?

Very soon, it should all be usable to some degree, so then you'll be able to really play with it. I very much hope we'll get loads of feedback so that we can adjust our course if necessary.

Please also see the meta issue I created yesterday: #1706688: [meta] In-place editing, inline macros, editables, and Wysiwyg in core.

crimsondryad’s picture

Wow...there's a lot to read though on those links, you all have obviously been thinking about it a lot. Here's my nickel...if I'm hijacking, I'm sorry, this topic covers a lot of ground.

I actually like the idea of WYSIWYG and filters being deeply integrated just because it's a raging pain today to configure both the text format and the WYSIWYG profile consistently. It's just too easy to forget a setting and end up with things acting flaky.

However, I would *really* not prefer to have it so tightly integrated that we can't use something else. Mainly because we have a product we built using CKEditor that would be a lot of work to redo. We also had to hand-code enchant (php spellchecker api) support into CKEditor and we're not excited about doing it all over again. Unless you can convince the Aloha folks to toss that into their magic bag of tricks?

Another big pain point was that changing the profile for a content type would change everything...or not change everything. It wasn't really consistent and it confused the crap out of everyone ( at least here ). So I'm all for the ambition of really making text formats more usable.

One of my biggest concerns with taking a very ambitious approach is that there won't be nearly enough time to do it all ( 4 months til feature freeze ) and either D8 will get pushed out or the implementation will have some rather large holes ( specifically I'm reminded of the update manager with some things rushed in during late Dec and some stuff still kinda broken ). Because we're primarily using this in a corporate environment, I just really want it to work solidly, which is why I've been advocating for CKEditor...it's the devil I know.

On the inline editing piece, I assume folks can still go to the normal node edit screen if they need to, right? Because we actually use nodes as the backend to drive Flash and HTML5 game functionality and we wouldn't ever want to ( or be able to edit it) inline.

I am SUPER excited about Spark and all the changes to how content gets created though. The ideas are really neat. I've been talking to my entire team at work about them. Thank you both for putting all the time and effort into doing this.

effulgentsia’s picture

Also because it's being implemented as part of Spark (which means it'll have to run on Drupal 7), we can expect that the WYSIWYG integration will be more loosely coupled than had we taken my approach, which was to integrate deeply into the filter.module.

Following on #62, I'm not sure this has to be the case. I think some filter.module integrations, such as somehow connecting the wysiwyg toolbar configuration with the "allowed tags" setting of Filtered HTML to solve frustrations like "hey, I configured my Filtered HTML wysiwyg with an 'underline' toolbar button; why is it not working? oh, crap, I also need to add '<u>' to my filter settings" would be very welcome and are still very much on the table. I don't know how high a priority that is for the Spark team, but there's no reason for someone who cares about that to not work on it. Even if that's the kind of thing that can't be part of the D7 version of Spark, I think everyone working on Spark would love to see those kinds of improvements in D8. Perhaps the question is how to best work on those kinds of D8-only things: would that be facilitated by committing Aloha to D8 core sooner rather than later, or do we want to update http://drupal.org/sandbox/quicksketch/1088256, keep it synced with Spark wysiwyg work as best we can, but use it for D8-only filter.module/wysiwyg integration issues? I think @sun has some concerns about some kinds of filter.module integrations, which we may want to discuss and post a detailed analysis of somewhere.

On the inline editing piece, I assume folks can still go to the normal node edit screen if they need to, right?

Yes. This is necessary for creating a new node, for editing properties of a node that can't be inline edited (e.g., "promote to front page" and other things with no visual representation on the node display), and for people who don't install/enable the Edit module (which provides the inline editing features). #1510532: [META] Implement the new create content page design has had a lot of recent activity on making the non-inline node add/edit page better, and once we have Aloha in core, I think it would make sense to have core's Standard install profile configure it to be used for the node body field within that non-inline node form.

lightsurge’s picture

For anybody wanting to see Aloha jquery version who hasn't had the chance to install locally, the demos on the Aloha site have been upgraded to it. Also now includes the image plugin.


crimsondryad’s picture

I did actually play with the demo, though it's never quite as full featured as a live one because of XSS concerns.

mgifford’s picture

The demo is certainly better for accessibility. I wish that it was clear from the demo what version of the code was being used. The button highlights for the editor are still only visible on hover rather than focus. Not sure if I should be reporting that to the github issue queue or not considering I'm not sure what version to it is using.

Wim Leers’s picture

#67: it's "latest", but I also don't know what that means. I think it means "sort of the last commit", i.e. that it gets rebuilt every few hours or at least every day. But that's a guess.

Here you can test e.g. version 0.21.0 (the one-but-last stable release): http://aloha-editor.org/builds/stable/alohaeditor-0.21.0/aloha/demo/boil....

I've opened an issue to get you a proper answer, @mgifford: https://github.com/alohaeditor/Aloha-Editor/issues/663. Thanks a lot for your feedback!

droplet’s picture

Ckeditor is the way to go ? supporting html5 contentEditable now


Seb_CKSource’s picture

Ya, CKEditor 4 Beta has inline editing. More information can be found here. But more focus was given to optimize the code, not to make the editor look pretty.

Wim Leers’s picture

Seb_CKSource: thanks for chiming in! Could you explain:
- The core differences between Aloha Editor and CKEditor 4?
- Does CKEditor 4 have something like Aloha Blocks?
- Why we should choose CKEditor 4 over Aloha Editor?

FredCK’s picture

Wim, Seb asked me to reply here, so be ready to read on :)

We have never put around comparisons with other editor to promote ours (like others do). We always found it very unfair and we prefer to be focused on making a great editor. So we have little information about Aloha and no experience with their code.

What I can give you here are a few facts, which I hope will help on having a better understanding.

- With CKEditor 4 we're now offering a "hybrid" solution with inline and normal ("boxed") editing. We're not limited to one way or the other.

- We have *lots* of features, all of them available through a plugin system. All of them very stable. Together with the final release of CKEditor 4, we'll be launching services that will make customising CKEditor a breeze.

- We offer a powerful API. If any feature is missing or any customisation is needed, it's just a matter of developing them. If any small detail doesn't fit the Drupal needs, it can certainly be changed and amended.

- We work with straight contact with companies like IBM, Oracle and many others, which pushed us during the years to bring a high quality, extremely solid and reliable solution.

- For example, we worked directly with the IBM accessibility team to bring a wonderful usable accessibility experience. No other editor offer as much quality on this.

- We have have more than 1.2 million downloads yearly. While one could say "so what?", a better understanding of this number shows that CKEditor is trusted because of its stability, it has the features that most of the users want, it fits well on the huge different use case scenarios and it can be customised to fit all needs.

- We're a team working everyday for CKEditor, exclusively.

- We have a huge community, very active, providing us constant feedback.

- We have a ticket base with over 7100 tickets closed.

The last point is very important. With our experience we have understood that browsers are very buggy when it comes to text editing. This is worst with the old ones, of course, but it also includes the latest models.

No editor will be ever perfect. CKEditor has hundreds of hidden and less evident issues solved and I'm sure you'll hardly find the same on a new editor.

Of course, one could always point to specific issues, but those certainly can get fixed… and we're here for that.

- We're ready to support Drupal on this.

In fact, to conclude this message, one very important fact to be taken in consideration is that we've been active in the Drupal community for years, as the maintainers of the CKEditor module. And for years, we have showed our availability to collaborate to make CKEditor the perfect solution for Drupal. We always worked for the moment when Drupal would choose their core editor.

Now that moment came and, based on the things I've been seeing around, it looks like a final decision has been taken. Maybe (and I hope) I'm wrong and someone could confirm it.

In all cases, I want to renew our availability on cooperating. A core editor for Drupal is too important a feature to take risks and CKEditor is definitely the most complete and professional solution Drupal could ever have.

Please drop me a pm and I'll love to talk further about it.

quicksketch’s picture

Thanks FredCK for taking the time to drop in. We certainly appreciate your input and everything CKSource is doing.

We should have known that CKEditor (and probably other players) aren't standing still in light of the new HTML5-friendly web, and it's shame on us for not keeping tabs on development -- though looks like this was sort of an all-at-once surprise on Aug 22nd? In any case the information was probably there for us to get it if we would have asked.

You're right that essentially, "a decision has been made", but in light of this development it deserves re-evaluation.

From a technical perspective, one of the most compelling things in Aloha editor is their ability to have editable areas within other editable areas. We've used this ability to make minor elements editable within larger edit areas. However, with the addition (or planned addition) of using Create.js, I'm not sure we'll be using Aloha blocks quite so exclusively. @Wim Leers, any thoughts there?

Wim Leers’s picture

The potential use of Create.js does *not* prevent us from using Aloha Editor's Blocks functionality. As far as Create.js is concerned, it's just "apply editor X to field foo", with X being e.g. Aloha Editor.

The nice thing about Aloha Blocks is that you can develop pretty much any interactive behavior you may want, and make it available *directly* within the relevant elements inside the editable. You don't *have* to rely on AE's toolbar. #72 contains a lot of nice numbers, but e.g. not a direct answer to my Aloha Blocks question. It'd be nice to get a well-founded reply in that area.

I do also want to note that we've communicated very explicitly and publicly about our (Spark's) choice for Aloha Editor. We haven't reached out to CKEditor directly, but we've looked at roadmaps and bug trackers. I still can't find more information about CKEditor's "inline editing" functionality, now that I know that's the term I should be looking for.

klonos’s picture

We have never put around comparisons with other editor to promote ours (like others do). ...

Well, that doesn't help people decide if CKEditor fits their needs now, does it? It's not simply a matter of marketing and/or dissing other products - it greatly helps people see why they should pick a product (or not).

... We always found it very unfair and we prefer to be focused on making a great editor.

I have yet to cross a project that has set as their goal to build a really crappy one. They still provide a list of features compared to other editors and emphasize on what they do best/better and how.

FredCK’s picture

Sorry kronos, but still it would not be fair to have CKEditor putting comparisons all around. Of course those comparisons would be biased in our favour.

In fact, Aloha promotes "Faster" as one of the key things on their home page, pointing to a graph created with an old buggy version of CKEditor (with issues on loading in fact). Additionally, they compared their editor with very few features with a bloated full features version of CKEditor.

Then the "Save 25% of working time!" thing is really ridiculous. It is based on a precisely selected set of actions that benefits the results towards them. I'm sure every editor author could create a similar graph with different results on other tcs.

Now, do you still thing this is fair and that those are credible comparisons to be used to take your decisions? Sorry but I'm not with you on that.

The sad part is that in any case, most of the people out there see those things just like you described it. That's why I find it as a bad guys move to take attention.

In any case, this discussion is out of topic I believe. Only if you guys want to take in consideration the reputation of the projects.

FredCK’s picture

Thanks for the comments quicksketch and Wim.

As for having had these news earlier, you're right. We were here for you. We even tried to contact you guys to talk about all this earlier, but unfortunately our communications got cut once you have made a choice. In fact, we all know that there are very few real options in the market. Contacting us directly to exchange a few words wasn't supposed to be a big deal.

Anyway, we still have a chance to talk now. So let's take it positively and move on.

So, to start, a smile :)

FredCK’s picture

Wim, I've just checked the blocks feature you're talking about. There are several things I could say about it:

- No we don't have it right now.

- I think Aloha didn't have it as well, until you asked them directly to have it. You guys worked on straight contact with Aloha to have this feature developed. A prototype at least.

- It is not the first time we see someone taking a single unique feature as the key to justify a choice. You've just made that, by minimising the facts I've presented on #72, putting the block thing as the must have. // I'm not criticising, just making you notice it… not a big issue.

- I'm sure Aloha didn't spend months to have that feature developed (and you know it well). We can certainly develop something similar, or even better. In fact, every editor cold have it. It's just a matter of coding it. So I still don't see it as a key decision point over all the rest.

To conclude, I find this feature very interesting and I'm sure we would have interest on having it in CKEditor.

Btw, I didn't mention that, following the final release of CKEditor 4, we'll be happy to have our guys following you in straight contact to provide all you need to have the best editor for Drupal, ready in time.

FredCK’s picture

Let me open an additional point of discussion.

D7 has no editor in core. D8 aims to have and editor in core, but there is little time to make it.

Shouldn't you guys be focused on providing a stable set of basic editing features first of all? I know it is cool to have extra features all around, but this is just the beginning of having an editor in core. Aren't you jumping the first steps, trying to reach things that in any case you'll at some point have, when the time comes?

Anyway, I'm not saying that this or that can't be developed on time. Or that CKEditor is not able to have it. In fact, no matter what editor you choose, you'll always be able to have the features you want.

First steps first. KISS ;)

lightsurge’s picture

I'm also a bit confused... seems like the ckeditor folks were involved in this thread quite early http://drupal.org/node/1260052#comment-5923348 and the topic of inline-editing came even earlier... The new editor looks great and it might have really helped if there'd been some hint of what was to come ckeditor-wise.

Now that Spark is rolling with aloha, it would seem a shame to duplicate effort (and I got the feeling there's already been some wasted effort on quicksketch's part already) by incorporating a different editor in core, surely... unless it's feasible for Spark to roll-back?

webchick’s picture

Wim, quicsketch, and I had a discussion about this in #drupal-contribute today.

By way of background, the Spark team has made every attempt to be extremely transparent with the fact that we were tackling this issue, through blog posts, through videos, through outreach to key Drupal contributors, and through participation in these main community discussion threads. It therefore shouldn't come as a surprise to anyone actively involved in the Drupal community that this work has been going on now for months.

Back in May, a full analysis of all editors' issue trackers and code bases was performed by the Spark team and the larger Drupal community, including that of CKEditor. There was nothing we could find to indicate that HTML5 contenteditable support was under development, that it was a high priority for development, nor that it would have a beta release in time for our feature freeze. Nor did any Drupal community member/CKEditor team member outside of the Spark team raise this during the last 3 months. This all kinda seems like it was unveiled in "big bang" fashion last week.

And so, Aloha Editor was really the only option we could find that not only was written from the ground up to work with inline editing from the start, but also had 80%+ of the "plumbing" that we needed already for Drupal's crazy filter system, as well as a very active contributor base keenly interested in doing whatever it took to help Drupal work with it, including hosting a collaboration sprint in their offices in Vienna, showing up at DrupalCon to demo their stuff, and changing the freaking license of their project to GPLv2+ so we could use it. We've been absolutely thrilled with the collaboration with their team to date.

Therefore, from the Spark team's perspective, it doesn't make a lot of sense for us to deviate from the course of trying to express the full vision of what WYSIWYG in core could look like using Aloha Editor as the base. There is a metric ass-load of work to do, and we'll be extremely lucky to hit all of that by feature freeze date (Dec 1) as it is, even without throwing away all of our work to-date and starting afresh with something else. It would also, frankly, be pretty disrespectful to the Aloha Editor guys for all of the awesome stuff they've been helping us with for the past several months. So stopping everything to re-open the evaluation for WYSIWYG in core from scratch is definitely not something the Spark team is willing to take on; we're going to "stay the course" with Aloha, since it's the furthest along implementation-wise and has the best shot of making it by feature freeze.

Does that mean a firm "no" to CKEditor in Drupal core or integration with Spark's Edit module? Not at all! I think that anyone passionate about CKEditor (and you can see from these various discussions there are a lot of people who are) should definitely get involved in the over-arching plumbing issues that need to happen, regardless of what WYSIWYG editor is ultimately chosen. The work we have to do for Aloha anyway will likely pave the way for a CKEditor approach much more easily, since 99% of the problems are going to overlap, I would think. And we'd be happy to review patches for a CKEditor plugin for Edit module, as well as patches for any bugs that you hit on the way.

Just I would remind everyone to keep your eyes firmly on the goal—WYSIWYG editing in core, by December 1. That's what we need to hit. And from the Spark team's POV, sticking with Aloha has the best chance of it happening. But we certainly could use others in this battle as well, so please jump in and help!

RobW’s picture

In order to make any type of decision there needs to be a comparison chart, preferably provided by both CKEditor and Aloha. The Spark team is already pretty invested in Aloha, and have been for a while; CKEditor developers will need to prove that not only is CKEditor as good as Aloha for the key requirements of the Spark Initiative, but that it's superior to a degree that will justify switching at this point, losing the time and personal connections invested in Aloha (with no hard feelings of course).

I'd love to see a comparison that displays the strengths of both editors. I think first we need a consensus from the Spark team that switching is even a possibility.

Never mind, cross-posted with Webchick.

webchick’s picture

Well, I'd just like to point out though that just because the Spark team isn't planning to pursue CKEditor doesn't mean others in the community can't, or that such a comparison chart would not be extremely useful.

FredCK’s picture

webchick, thanks for the comments.

I think that, if you guys already had your option set, it was a mistake to call us on these recent talks. It just caused stress among the varios teams involved on this. So please let me add these last few words.

You talked about being disrespectful and the such. I agree. But consider that we've been serving the Drupal community for years, being the most used editor on the drupalsphere. We even left a dedicated developer during all this time to maintain the healthy, stable and high-quality integration that many of you guys use.

But that's part of the human nature... the other guy gets forgotten when you start a new love. :)

Anyway, for the little I've understood, there is already a kind of agreement that Spark will drive the wysiwyg on core thing into D8. I doubt a new group will start parallell work on a different solution to later have to run a battle to try to impose anything different.

In any case, I renew our availability to cooperate to have CKEditor and Drupal together. Don't be afraid to drop me a message now or in the future, if we can do anything to help you guys.

lightsurge’s picture

But that's part of the human nature... the other guy gets forgotten when you start a new love. :)

I think there's definitely still a lot of love for ckeditor.. don't think you should be too disheartened! In terms of Spark, I don't think this was speed-dating, the small ad wasn't very small, and was very descriptive, resulting in very few respondents of which Aloha was pretty much the only compatible choice, and it really seemed in that thread that we were scraping the barrel at times... so it seems they and the Spark team went on a date in lovely Vienna and things just went on from there ;-) I can't really argue with that, lots of people including me tried to find Spark a suitable date, and I think CKeditor 4 would have been put forward like a princess of editors had she been courting at the time, and if she didn't quite fit the bill, just as Aloha was a bit fat and came with a dubious pre-nuptial agreement, I imagine there would have been the same discussions with her parents to see if there was a willingness to sort that out.

If the Drupal/Aloha marriage makes its way into core, as I understand it the plan isn't to make it strictly monogamous, Aloha would just be the 'first', so it would seem a positive thing to focus, for example, on the mechanism behind how users switch editors? (see 8 in http://drupal.org/node/1706688 - something like wysiwyg module in core)

klonos’s picture

Yeah, when I was talking about comparison charts back in #75 I was thinking more like the way its done in wikipedia or here in d.o and elsewhere. So I was talking about wiki-style articles where things stated can be argued and proof required for whatever is written - I wasn't referring to ad-style, we-are-the-best kinda comparisons put out on each editor/product own website where everybody hides their flaws and augments their qualities.

I wasn't able to find a (d|r)ecent such chart out there. If it were such a place available with official input from each editor + links to resources that people could refer to as proof of what is stated, then I guess decisions made would be more well-informed and fair. Drupal would have then considered "dating" a few of these editors before making a decision for D8. It's not Drupal's fault if these editors didn't "put themselves out there" to be found. If you want to meet a person and eventually start a relationship it is not enough to put on your nice, brand new clothes and some fancy make-up/perfume - you also need to get out of your house :p

I realize that part of the reasons why only a few of these charts exist out there and why they get so outdated is the fact that it is really hard for a person or two to keep them up to date (btw I love it when such charts include a 'last update' column). So, this needs to be done by each editor developer separately in a commonly-agreed place (wikipedia seems to be such a place to me). So, I guess what I'm trying to say is that excuses can be easily found for both sides: one for not putting a comparison chart together and the other for picking seemingly "randomly".

crimsondryad’s picture

Part of the discussion on this was to try and keep the ability to replace the core editor with the editor of choice. This was important to my sites in particular because we had to write custom code for CKeditor ( which we are considering contributing ). So for at least that site we wouldn't be willing to switch from CKEditor easily.

So while I'm sure many folks will use what comes out of the box, that doesn't mean CKEditor is out of the game.

akmalfikri’s picture

+1 for CKEditor

quicksketch’s picture

Hi all, thanks for all the comments posted so far.

It hasn't been apparent from this conversation, but this initiative was largely superseded by the introduction of the Spark project (http://drupal.org/community-initiatives/drupal-core/spark). Considering most developers considered developing a less-ambitious WYSIWYG integration without inline editing to be wasted effort, all attempts at integrating other editors was largely abandoned.

During their analysis, all other editors were eliminated from competition because of a lack of inline editing ability. I'm not sure the comparison is posted publicly (it was on Google docs) so I can't link to it directly. A few months ago, the situation changed quite a bit when a mature project, CKEditor, announced inline editing (http://ckeditor.com/ckeditor-4-beta). However the level of investment in Aloha was already significant, and the situation remained largely unchanged.

Now when reviewing the initial Aloha patch for core (#1809702: WYSIWYG: Add Aloha Editor to core), it's become much more clear what Aloha's limitations are when used as a back-end editor. There are multiple issues with usability (disappearing/reappearing toolbar being the most prominent) and accessibility (contentEditable fields are not very tab-key friendly for changing focus). Now that CKEditor has inline abilities and it's no longer disqualified, using CKEditor even now it may prove to be a faster/better approach to integration due to the maturity of the editor. The Spark team is re-evaluating CKEditor in a head-to-head comparison between CKEditor and Aloha, and the results should be posted early next week.

In the mean time, I've re-bootstrapped this project to develop an adequate sandbox for comparison between Aloha and CKEditor. I've put up a demo site at http://quicksketch.org/wysiwyg that includes installations of CKEditor 4.x and Aloha (slightly modified from the http://drupal.org/project/aloha 8.x branch). For now I'm developing the CKEditor integration directly in the sandbox of this project. Anyone interested in reviewing the code please do. Anyone interested in comparing the usability of the editors that would also be appreciated.

Because my version of Aloha isn't feature complete, I recommend testing between these two sites for the current state of integrations:

CKEditor: http://quicksketch.org/wysiwyg/node/2 (login demo/demo)
Aloha: http://spark.webchick.net/8.x/node/2/edit (login sparkles/ sparkItUp)

The CKEditor integration isn't as mature as Aloha integration, since we just started, but as CKEditor demonstrates it's more mature as a project, it's a good start for basic comparison even with the lopsided levels of integration.

SeanBannister’s picture

@quicksketch great work, its really important that we give ckeditor a fair go as it already has so much momentum in the industry. Are there any other issues we should be following to keep an eye on progress and help out?

quicksketch’s picture

@SeanBannister Yes I'm glad you asked. The demo site mentions these issues (they reflect the patches applied to the sandbox) that could use immediate review:

#1833716: WYSIWYG: Introduce "Text editors" as part of filter format configuration (Needs opinions, usability and technical review)
#1834682: Consolidate filter options in the UI when configuring a format (Needs opinions and usability review)

These issues are needed to push the integration further:

#1667742: Add abstracted dialog to core (resolves accessibility bug) (Needs technical review)
#1779026: Convert Text Formats to Configuration System (Needs technical review)

Any bugs/features regarding the CKEditor implementation, please post them directly in this issue queue. Most of the Aloha integration is happening over in http://drupal.org/project/issues/aloha. If new features are added that we need to merge with over here, please open an issue here for the merge.

TinyMCE Dev’s picture

This whole evaluation of editors seems weird, but if you are still interested in evaluating TinyMCE we do have a version coming out soonish with inline editing as well as a new user interface and a lot of other changes. Let me know if you want to have a look at it quicksketch, we can set something up for a select group since its not publicly released just yet. I have added you on Skype quicksketch.

lightsurge’s picture

From my comment in http://drupal.org/node/1260052#comment-6743142 I had a look at how these two editors compared in terms of pasting from Word. I didn't use the examples in #89 because these both look to have been setup to strip pretty much everything, so it wouldn't be much of a comparison.

I used:

http://www.aloha-editor.org/demos/3col/ and

I used http://nicedit.com/demos.php as a control since I know it does no stripping, leaving in the weird classes, spans, styles, tags, measurements etc., just to check that Word wasn't giving me good markup in the first place ;-)

Both seemed to work pretty well, stripping out all the the worst. A few things I did notice:

  • CKeditor didn't strip out the 'align' attribute.
  • Ckeditor allowed various inline styles through, particularly prevalent being margin-left with pt measurements for Word indentations
  • Aloha allowed <b> but CKeditor converted to <strong> which seems better
  • Aloha performed slightly better at pasting lists from older documents, yet both regularly failed, pasting a disc character instead and filling the space between the disc and the text with nbsps, and CKeditor applying margin styles as well
  • CKeditor occasionally allowed DIVS to be pasted in, and them coming from Word they never made any sense
  • Aloha performed better with tables, with CKEditor applying a width to every single cell, and applying border, cell padding, cell spacing etc. to tables which didn't seem desirable in this context. Aloha basically took tables completely over with its plugin, removing/replacing all such stuff.

I get the feeling that many of the above observations with CKeditor may just be down to configuration? In any case, in my testing they both clean up the major cruft very well, but with Aloha performing slightly better at retaining formatting where it can, and cleaning up tables, which gives it a few extra points for me currently in terms of 'paste from word'.

Wim Leers’s picture

Aloha's allowing of <b> instead of converting those to <strong> are also a configuration thing. It's a known issue, and hasn't been a high enough priority to fix so far.

Thanks for the comparison! :)

lightsurge’s picture

Also <i> of course which should get converted to <em>, CKeditor does, Aloha doesn't... it's still valid markup of course but is semantically incorrect.

Wim Leers’s picture

#95: indeed.

quicksketch’s picture

Re #92:

This whole evaluation of editors seems weird, but if you are still interested in evaluating TinyMCE we do have a version coming out soonish with inline editing as well as a new user interface and a lot of other changes.

Yeah I couldn't agree more. So far it hasn't really been much of a "comparison" as a matter of elimination. I was looking through recent changes in tinyMCE and discovered that there's a lot of underpinnings for removing the iframe wrapper (checks to see if the editor is in wrapper or not), so it's not surprising to hear that inline editing is planned for tinyMCE too. Do you guys have any public tracking of this feature available? We're in the middle of trying to undo the miscommunication with the CKEditor team as it wasn't clear to us that they were working on inline functionality (or have any idea when it would be released) until they announced the 4.x version in August.

The Drupal timeframe is becoming shorter all the time. The technical "feature freeze" is Dec 1, but it's likely we'll see an extension for WYSIWYG functionality. @TinyMCE Dev I'd like to chat with you about where the development of tinyMCE is and where it's headed. I'll contact you via your drupal.org contact form, as I didn't see the Skype invite.

@lightsurge: Thanks for this comparison! I know CKEditor's paste from word is extensible in some ways, but I'll have to research the full flexibility of the system to know if the CKEditor limitations can be overcome.

webchick’s picture

Project: WYSIWYG in Core » Drupal core
Version: » 8.x-dev
Component: Miscellaneous » other
Category: task » feature
Priority: Normal » Critical

Greetings, folks!

Now that we're on the other side of http://buytaert.net/drupal-8-feature-freeze-extended and have a little bit of breathing room (but not much), I wanted to give an update on recent developments.

Just before BADCamp, Nate / quicksketch raised some concerns about how Aloha was progressing relative to feature freeze, particularly in terms of editing on the "back-end" node form. Since CKEditor is a more mature editor than Aloha, and since they recently added inline editing support (using contentEditable without an iFrame) to their just-released version 4, the question was raised about whether or not we ought to use CKEditor instead as the WYSIWYG editor for core.

We then embarked on the question to create a comparison document (yes, an actual comparison ;)) between the two editors, which you can find at https://docs.google.com/a/acquia.com/document/d/164Bm2KPAPelQj2fKauWlajD....

This was done by Wim from the Spark team with feedback from Théodore (Drupal core JS maintainer), Nate (WYSIWYG in core driver), sun and TwoD (WYSIWYG API module maintainers), FredCK (CKEditor project lead), and Tobias (Aloha Editor developer), so it should be pretty comprehensive/factual. And unfortunately, as I believe the document demonstrates, there's not one clear, obvious "winner" in this race. Both editors are strong on certain things and weak on others, and both will need work in order to integrate well with Drupal core (Aloha significantly more so, but it also holds a lot of promise).

The conclusion we (the Spark team) are drawing from that exercise, is to continue along the path of Aloha Editor as the WYSIWYG editor for Drupal 8. Because:

  • Aloha provides a comprehensive solution to editing nested pieces of content within the WYSIWYG through the concept of "Blocks".
  • Most browser-specific hacks live in a single “shim” that will allow the size of the library to decrease over time as browsers evolve (and Aloha Editor folks are helping to push forward these standards).
  • The pre-existing relationship with the Aloha Editor community, which has been both transparent and excellent to-date.
  • There's already pre-existing community buy-in on this solution that we don't need to try and build from scratch.

Dries supports this direction as well, however both he and us are obviously committed to doing what is right for Drupal. So we wanted to post this comparison for further community discussion/feedback, as well as to hopefully drum up some additional help, because there's still quite a lot of work to do and really only a couple of people doing it right now. :( I'm moving this to the Drupal core queue to get some more visibility on it.

In terms of next steps, we're going to discuss a bit with various people and try and put together a battleplan in terms of milestones and dates to hit to help move things forward. In the meantime, #1809702: WYSIWYG: Add Aloha Editor to core and #1833716: WYSIWYG: Introduce "Text editors" as part of filter format configuration could use your help/reviews.

quicksketch’s picture

The comparison mentioned in #98 covers a pretty wide scope of features and what we looked at directly between CKEditor and Aloha. Like Angie said, there's not a clear winner.

Given that either editor could work, which is "better" may be subjective based on what's important to "us" (being "Drupal"):

  • CKEditor is stable and is probably the best solution right now. They released the 4.0 stable version this week, which includes the "must have" feature of inline editing (at least for the Spark team). Using CKEditor we get all the benefits of a mature project and stable code base. CKEditor's release cycle is more inline with Drupal's cycles and would be guaranteed to have a steady stream of fixes and features based on its long history. CKEditor's code is clean and extensible, but may have a steeper learning curve for some coders because it does not depend on any external libraries with which they are familiar (e.g. jQuery).
  • Aloha has an API that is more inline with Drupal (being based on jQuery). The reviews of its code are generally more positive than analysis of CKEditor or tinyMCE. It provides a unique feature for managing chunks of non-editable (or partially editable) areas within the WYSIWYG called "blocks" which would be useful for contributed modules like Media, Inline, or WYSIWYG Fields. The concept of non-editable areas is not unique to Aloha, but the management of these areas is superior with better drag/drop and copy/paste support. However Aloha is not currently stable, and still has a long outlook on reaching a stable point (probably 6 months or more).

CKEditor is the better editor today. Aloha has potential to be the better editor months from now. So a lot of the decision here rests on how optimistic we are about the future of Aloha. Keep in mind that CKEditor isn't going to be standing still either, so during the next year we can expect both editors to improve further.

The most likely course for Drupal right now is probably a continuation of status quo: Aloha will continue to have the support of the Spark team (and Dries). That doesn't make it the de facto winner. I'm still a supporter of the "use what works" approach, which as I've demonstrated (http://quicksketch.org/wysiwyg), I think CKEditor fits with Drupal better. I'll continue to push CKEditor despite its lack of support because I maintain that it's an easier solution that meets all our requirements. In the event that Aloha doesn't stabilize or solve the "gates" for Drupal core (most specifically the Accessibility gate), then we'll have an alternative solution that meets our requirements waiting in the wings for Drupal 8.

Because of the feature freeze, we have additional time to deliberate which editor is most appropriate for core, though I doubt the situation is going to change much given Aloha's greater level of support amongst developers that are working on core.

henribergius’s picture

It should be noted that Create.js supports both editors via its "property editor" abstraction layer (CKEditor 4 was added in the Gent Core Sprint).

This means that theoretically Drupal could also support both and allow users to choose. Though obviously deeper editor integration like image and link browsers still has to be done on per-editor basis.

I've recently received reports that latest TinyMCE is also able to run in contentEditable mode, but haven't had time to look at that in detail yet. If this is true, then I'll add support for it also in Create pretty soon.

Of course, Create's editor abstraction is currently only used in the Edit module, and not on Drupal back-end, and so it might not be enough.

DamienMcKenna’s picture

FYI TinyMCE has had contentEditable support since v3.4.3, right now it's at v3.5.8.

eigentor’s picture

I got some other questions that may be helpful:

  • Is there a measurement of the size of CKeditors team compared to the one of Aloha?
  • Is there a way to measure the momentum behind it?
  • How good does the CKeditor team fare in terms of willingness to work with us and maybe accept upstream work from us, is there any experience in that regard?
  • Can one say that one of the two is more "modern" concerning the codebase?

The fact that Aloha builds on an external library I would count as a big plus as I believe that is modern :)

With choosing Jquery in the past Drupal has been very lucky (or just very capable of informed decisions :D )
to choose the competitor that is the king of the hill today. So wouldn't it be nice if we could hit that again.

mbrett5062’s picture

I guess I am missing something really important here, but I see people reading the comparison document and still coming down on the side of Aloha.

My review of the document clearly shows to me that as of today, CKEditor is the clear winner. Most features are green and where not they are equal.
The only real reason given for sticking with Aloha as our choice is the 'Blocks' feature in Aloha, which the document clearly states:

FredCK claims something like Aloha Blocks could easily be implemented

Perhaps someone could explain, is this the only reason, or am I missing something?

webchick’s picture

Well, but Fred also comments on that part of the doc and says, "Ops… before anyone else say that I said that that feature can be "easily implement", let me just say that I've never said that." :) The reasons for Aloha over CK are outlined in the four bullet points in #98, as well as some of the conclusions/comments in the doc there. I encourage you to read them thoroughly. We spent a LOT of time building that comparison, and reaching out to the right people.

This feedback has been passed along upstream to the CKEditor folks, who I believe are looking into Aloha's Blocks system now.

webchick’s picture

I don't have immediate answers for most of #102, other than both teams have expressed the desire to work with us, and Aloha's codebase is more modern because it's not a project nearly as old as Drupal. However, that's also a point that counts in CKEditor's favour, in terms of its overall maturity as a project.

Sylvain Lecoy’s picture

And why not providing a set of quality API-driven interfaces that an editor must implements to work with drupal ? A bit like plugins, and the way WYSIWYG module works ?

Core provides by default Aloha editor, but encapsulated in a way (through interfaces) that it can be replaced easily by another editor implementing the interface (such a class adapter). I think it would open possibilities for developers and makes everyone happy. I would be glad to help in the design of such interfaces also.

To resume:

  • We don't destroy months of works.
  • We open possibilities to swap for another editor.
  • We make the platform more flexible and not bound to an implementation.
  • We are not changing/adding features here: just making them more flexible.
eigentor’s picture

@webchick: yeah, I did not mean to get quick answers to #102 but I think those points might be good to find out and help the decision.

A bit of a problem I see is that the Spark team already settled on Aloha. It is sure hard for you guys to have to say "oh no, not discuss it all over again". But the Spark team is not the Drupal Core team.
I feel it is especially important to get onto the same page withy Sun and Quicksketch as they seem to feel it was not their choice. And Sun having spent quite some time in the ugly world of Wysiwyg is sure valuable to have on the team full-on :) How about giving this at least some days to be decided. It could be timeboxed, to make sure this gets no wild bikeshed.

The problem is there can not be a clear winner, but there can be a clear choice which tradeoffs are better for the project.

webchick’s picture

A bit of a problem I see is that the Spark team already settled on Aloha. It is sure hard for you guys to have to say "oh no, not discuss it all over again". But the Spark team is not the Drupal Core team.

Hm. I just want to point out that the Spark team are the ones who created this comparison document in the first place, and also the ones posting it for community review. We're doing this because we want to validate the research within it, and also ensure that we do what's right for Drupal. The Spark team is part of the Drupal Core team, it's not separate from it. So I don't feel this is a "problem" at all. :)

The real "problem" is we need to move if we want to get *any* WYSIWYG editor in core, and the longer we delay this decision, the more difficult it is for that to happen. And then we'd really be throwing away months of work. That absolutely can't happen. If we ship Drupal in 2013/2014 without this functionality, then seriously, we all better get new jobs. :P~

Part of the problem is that quicksketch and sun are not remotely aligned. Quicksketch feels strongly that we should go with what works, sun feels strongly that without an equivalent of the Aloha Blocks system, any WYSIWYG editor in core is a no-go. As he says in the document, that's the one feature that pushed him across the line from "absolutely not" to "ok" about this initiative. Additionally, Drupal's JavaScript maintainer (nod_) has come down on the side of Aloha, and Aloha's also what has the most work done on it so far. Bojhan says they're a wash when it comes to usability.

I don't want to play politics, I just want to write code.

The Spark team plans to work on #1824500: In-place editing for Fields for the next few days, aiming to get it to RTBC and off of our plates by Tuesday so we can then turn all guns on the WYSIWYG in core effort. We kick off our next sprint on Wednesday, December 5. If there's not significant turnaround in terms of community buy-in/technical arguments made by then, then we're going to stick with the conclusion outlined in #98.

eigentor’s picture

Timeboxing till Dec 5 sounds good.

FredCK’s picture

We're in fact doing some research around the blocks feature, which seems to overcome any other benefit we could drop into the box ;)

Our team will meet on Monday for a final brief on this, so we should be able to finalize our opinion on this feature by Wednesday. We'll be in touch.

webchick’s picture

Awesome, thank you Fred!

effulgentsia’s picture

I mostly agree with quicksketch's assessment in #99, except for this statement:

CKEditor is the better editor today.

I would personally rephrase that to CKEditor is the more accessible editor today. It is the more polished editor today. It is the one with a stable release today. Whether or not that makes it better, is a matter of how much you value those things relative to Aloha's strengths, such as the Aloha blocks system. If we were releasing Drupal 8 in a month or less, I don't think we'd be able to get either editor in, because I don't think Aloha will resolve all accessibility and stability issues by then, and I don't think we'd figure out a CKEditor alternative to Aloha blocks by then.

Which one we can get to the place we want quickly enough for D8 inclusion is a matter of debate, as exemplified by the differences between quicksketch's and sun's differing perspectives. I'm currently aligned with sun and the Spark team, because I'm more confident in Aloha's ability to solve the remaining accessibility hurdles and get a stable release out by Drupal 8 release, than I am in CKEditor's ability (or desire) to implement a blocks system similar to Aloha's. But I totally respect quicksketch's desire to do some risk mitigation, and his work in keeping the CKEditor option on the table.

effulgentsia’s picture

#112 was an x-post with #110. I'm glad to hear about #110. Could be exciting stuff.

quicksketch’s picture

@effulgentsia: Yeah I specifically said CKEditor is a better "editor" today, not the better "choice". It's stable and useable today, Aloha is not. But this is a choice for what we think is going to be better by D8 release.

The waving of "blocks" around as a killer feature that is a "must have" seems off base. CKEditor already supports moveable, configuration, resizable, read-only "blocks" through a similar plugin it has called "placeholders". It doesn't provide a drag and drop handle on them (which essentially is calling jQuery UI sortable on the parent wrapper). Core hasn't presented a situation where blocks are absolutely required. Blocks are used in the captioned image plugin for Aloha, but that approach can be (and is) implemented without use of either blocks or placeholders, as is demonstrated in Wordpress for TinyMCE and in my sandbox for CKEditor.

And why not providing a set of quality API-driven interfaces that an editor must implements to work with drupal ? A bit like plugins, and the way WYSIWYG module works?

@Sylvain Lecoy: While the basics of plugins are able to be abstracted, the APIs and UIs of different editors makes a complete abstraction layer difficult. WYSIWYGs are large projects, as large as Drupal itself (well maybe Drupal 6). You could compare providing an API around all of them is like trying to make an API that wraps around Drupal and Joomla. Editor libraries generally have similar concepts, so an abstraction layer is *possible*, but the end result is plugins that integrate in ways less complete than native plugins.

In any case, I do think that we should avoid re-implementation in any areas where Drupal integration is involved but interaction with the editor library is minimal, specifically around handling of image and link dialogs. Now that we have a reusable modal system in core, editing an image or creating a link should use a Drupal-based modal to do the manipulation (other systems such as Wordpress and Assembla also replace the native modals with their own). This would allow us to use familiar tools for image/link manipulation in the modal such as FormAPI, Views, the theme layer, etc. That's the long-term goal of the Editor module, which is attempting to be introduced in #1833716: WYSIWYG: Introduce "Text editors" as part of filter format configuration. We're also talking more about abstract plugin APIs over in that issue so it might be a better place to discuss that possibility.

lightsurge’s picture

This feels like the betamax/vhs or hd-dvd/blu-ray battle. You can bat it out as much as you like as to which is better, but when it's such a close race with just a few runners, I mean this is not 'just' but is just an editor, and as Henri said it's not beyond the realms of possibility to switch between... so perhaps people just have to agree to disagree?... because in the end one will be chosen not because it's better and somebody made the better argument but because the argument couldn't go on forever and ever and ever, and once one is inevitably chosen it's pointless reminiscing on what might have been, because quite easily something completely new'll be out in a few years.

What Spark has done has provided me with an Aloha module I could actually try out myself in 7.x, and an Edit module I could try out in 7.x for inline-editing, the whole point I thought was that catalyst and I could install it myself and see it working, that seems to speak more to me right now than a theoretical CKeditor4 8.x back-end wysiwyg module and a theoretical inline-editing module and theoretical CKeditor Blocks functionality. As far as Drupal goes CKEditor4 is all theory and no fact, in contrast to Spark and Aloha which sought to make it fact before proposing it for Drupal 8.x.

Sylvain Lecoy’s picture

In reply to #114 I think we should take the problem the other way around. There are plenty of editors with their own API and a different one between version, but at the end of the day, they all produces a sort of text flow which is usually HTML input. They also all requires parameters to know what is supported as tag thus its the class adapter job to instruct the editor how to configure itself. Starting with that in mind, the API design should fullfil the Drupal needing: what Drupal absolutely needs for an editor to integrate ?

quicksketch’s picture

As far as Drupal goes CKEditor4 is all theory and no fact

http://quicksketch.org/wysiwyg and http://drupal.org/sandbox/quicksketch/1088256. It's very real, I haven't been spending the last month imagining it. :P

The integration with Edit module is "theoretical" at this point, but considering it's integrated with Create.js already (on which Edit is built) then it should be trivial.

lightsurge’s picture

http://quicksketch.org/wysiwyg and http://drupal.org/sandbox/quicksketch/1088256. It's very real, I haven't been spending the last month imagining it. :P

I realise that and CKeditor4 in your sandbox looks great... it definitely made me want to try it out and see how it behaved in sites I'm currently working on, but as far as I'm aware there's no 7.x module that can yet utilise it. I'm not saying somehow that somebody should have made me that module, not at all, I'm still astonished and delighted everyday to find the hard work that people are sharing for free on drupal.org, but the Spark project's method of making this stuff available in 7.x as a catalyst for 8.x has definitely been a bonus in that respect, seeing how stuff works, doesn't, or breaks other stuff in the wild.

quicksketch’s picture

Yeah actually I've been so happy with CKEditor 4.x I'm going to work on backporting a significant part of it to D7. Though because the D8 version I've written is dependent upon editor.module (#1833716: WYSIWYG: Introduce "Text editors" as part of filter format configuration), and the current CKEditor project provides its own text format to binding system that I'd really prefer to avoid, since it conflicts with WYSIWYG module.

quicksketch’s picture

If you'd like to try out CKEditor today for Drupal 7 based on a backport of the work I've done for Drupal 8, you can now do so through http://drupal.org/project/wysiwyg_ckeditor. Because it doesn't have a mechanism for attaching to text formats, for the Drupal 7 version I've piggy-backed on top of WYSIWYG API. It's a little strange because WYSIWYG API doesn't have an official mechanism for providing a custom form for an editor's configuration (instead it recommends you simply form_alter() the default configuration form), but the approach seems to work at least as a demonstration of all the integration we've done so far to make CKEditor a Drupal-friendly editor.

FredCK’s picture

As promised (#110), here I am with details about the blocks feature in CKEditor. I hope it's good news!

Based on the feedback we had in this talk on on side discussions around the blocks feature, we started investigations to understand how hard it would be to have it in CKEditor. The preliminary tests demonstrated that this is feasible. So we decided to build a prototype that could more clearly show us all elements that compose this development, to help having a better understanding on requirements.

At the same time, it should serve as a tangible subject for discussion, so we all could go out of the theoretical talks.

To start off, we found a better name for it: Widgets :) That's all about widgets, in fact.

Then we coded the prototype, mainly focused on the basic selection and editing of widgets. We wanted to study the issues related to the fact that a widget must act as a single entity in the document. There are still several pending topics to be investigated and implemented. So, it is still very feature incomplete. If you really wanna break it, it'll break :)

In fact, you should try it with Chrome. Firefox may also work. We were not focused on x-browser compatibility in this prototype. First we want to have the design and processes well defined and have it working perfectly with Chrome.

Anyway, this is the result of two days of (hard) work. We have put a demo online:

We have implemented 3 different widgets, for needs that should touch most of Drupal users: Captioned Image, Video and Captioned Quote.

We opened a development ticket for this feature here:

It gives more details on the features status and current limitations.

The positive results we had with this prototype made us decide to definitely have the widget feature on CKEditor 4.1, our next major release.

While we're focused on bringing a generic feature to CKEditor, all this development started with the intent of satisfying the current Drupal requirements for an editor on core and the "must have" blocks (now widgets) feature. So we're firmly decided to sit here with you guys and shape the development in a way that it'll fit Drupal perfectly.

We have introduced several UI/UX aspects that need discussion, so we can understand the best way to go: widget selection markers, floating properties panel vs dialogs, insertion button in the toolbar, KISS vs full features, etc. But I think dedicated talks will be more appropriate.

To start, it would be nice to have a general feedback on the prototype.

tstoeckler’s picture

Using FF17 on Fedora17 this works beautifully. I cannot judge the implementation, but from the looks it seems exactly like what Spark has so far implemented with Aloha. This is in no way meant as a diss for anyone who has been working on the Aloha front so far, but I have to say that this being the result of only two days is extremely impressive!

eigentor’s picture

Hehe, now the race might be open again. Hope it won't cause too much friction for us... I guess FredCK has won more than a pawn on the chessboard..

mbrett5062’s picture

Works great in IE10, just need to click twice in the widget to bring up edit. Excellent work, a really cool feature, and so quick to implement to this level, astounding!!

effulgentsia’s picture

I'd love to get sun's assessment of the new CKEditor widgets prototype. The key feature of Aloha Blocks that impressed him a few months ago was related to how it could be used for his vision of a new and improved Inline module that could power Media and any other module that needs to insert entities, fields, or anything else into a text field. The key requirement here, for example, is that a caption, while potentially editable via the WYSIWYG editor, be saveable into a field attached to the file entity rather than as part of the parent text. I don't know enough at this time to assess whether the CKEditor widgets work enables that or not.

But I agree that it's cool stuff regardless, and sounds like even if more is needed, there's openness to doing it, so that's great. Thank you, FredCK!

klonos’s picture

Tested with latest FF20 nightly x64 and it works fine. Great job!

Sylvain Lecoy’s picture

The Inline module you linked made my day, thanks for that :D

I think this would be a killer feature, and even more if integrated with media.

webchick’s picture

Awesome! The plot thickens. ;)

We're going to continue working on Edit module and some other miscellanea for another couple of days to see how the evaluation of the new widgets system works out. Especially interested to hear from folks who maintain modules like Media, that want to add additional segmented metadata fields to the WYSIWYG editor, and whether or not this would work for you.

FredCK’s picture

The key requirement here, for example, is that a caption, while potentially editable via the WYSIWYG editor, be saveable into a field attached to the file entity rather than as part of the parent text. I don't know enough at this time to assess whether the CKEditor widgets work enables that or not.

Yes, definitely doable. Even in the prototype, widgets are standalone entities. The CKEditor API makes it possible to retrieve them and attach or read any kind of additional meta information available on it. For example, it would be possible to have fields in the properties panel that don't make any rendering change to the widget, but still live as part of it.

FredCK’s picture

Regarding the Widgets feature (#121), I've just opened a discussion about the "Properties Panel" we have proposed there:

It would be wonderful to have feedback on this as we'll get back to the prototype soon to bring it to its final shape (planned for CKEditor 4.1).

Wim Leers’s picture

I'd like to join the others before me in congratulating you on this proof of concept that you developed in such little time. Nicely done :)

That being said, here are the concerns we still see with it:

  • RE: the properties panel discussion (I joined that Google Group just now, but I don't have access yet, plus it'd be useful to gather feedback from more Drupal people, hence I'm posting it here): option 1 is a no-go, because it makes too many assumptions about the site's layout. Options 2 and 3 are feasible. But I'm not sure how you're going to make option 2 fully accessible, while I'm certain that you know how to make option 3 fully accessible, since it's just another dialog/modal like you have elsewhere in CKEditor. In the case of option 3, live changes seem like a less-than-great idea exactly because the user cannot *see* the changes, since the dialog sits on top of it? If you want live changes (which I think is something we could strive to do at a later point in time?), then I think option 2 is best.
    Bojhan, do you have more thoughts?
  • TRIVIAL: no events yet to know that the "CKEditor Widgets content" has changed; a specific event is not necessary, as long as the same "changed" event is triggered that gets triggered whenever you type something new in the "regular CKEditor" is also triggered when "CKEditor Widgets content" changes, then it's fine.
  • EASY: CKEditor Widgets' HTML/DOM representation does not yet get "cleaned up" when saving: we don't want a bunch of hardcoded HTML to show up — somebody in the 9764 ticket calls this "(de)serialization" which is another way of looking at it. We e.g. don't want an <iframe> with YouTube stuff to be saved; instead we want something like <youtube data-video-id="">; similarly we don't want <figure class="caption" about="something"><img src="" data-cke-saved-src="" /><figcaption>blah</figcaption</figure>, instead we want something like <img src="" data-caption="" data-align="" />. That means we have to implement both a server-side and a client-side "render" or "theme" function that maps from the canonical representation to whatever way a specific site wants it to look. This is also the way we made it work in Aloha.
    In short: Drupal themers need to be able to define what the HTML should look like. Existing, "minimal/core" HTML elements must be annotated with data- attributes, which also simplifies data migration: it needs to be possible to stop using a Drupal filter and have the image captions disappear, i.e. simply fall back to regular images (<img />). Analogously, it needs to be possible for us to import data from legacy systems where there are just images (<img />) and have CKEditor annotate them with data- attributes to add captions to them.
    If we wouldn't have this ability, then we'd be saving a lot of crufty/very unstructured data into text/markup stored in Drupal, and that's something that is considered to be utterly bad and evil in the Drupal world.
    Let me know if this is not yet sufficiently clear.
  • HARD: ability to convert an image (<img />) to a captioned image (<img data-caption="" />). But as said above, it must still be possible to render it (which in Drupal would happen through Drupal's theme layer) to something else than that entirely.
Wim Leers’s picture

I cross-posted bullet #131.1 to https://groups.google.com/d/msg/ckeditor-dev/uHHicc9J11A/EJ_uw15cLT4J and #131.2–4 to http://dev.ckeditor.com/ticket/9764#comment:12. Those seem to be the "correct" locations to discuss that within the CKEditor ecosystem.

Wim Leers’s picture

We've been looking more into CKEditor to try and identify gaps. Here's what we came up with, but we really encourage people who know CKEditor more to chime in too. We're doing this because Fred was eager to know what he and his team could do to make CKEditor more palatable to Drupal.


  1. Normal bug: Render bugs (horizontal gray lines) when scrolling → WTF? (In Chrome 23 and earlier AFAIK, not in Firefox/Safari/Opera!).
  2. Major feature: Ability to configure CKEditor’s pasting to match the currently active text format; specifically to strip tags and/or attributes that are not allowed in the active text format. In the demo at http://quicksketch.org/wysiwyg/node/9/edit, if I copy/paste the rendered version of
    This is <u>underlined</u> text!
    This is <em>emphasized</em> text!
    This is <strong>strong</strong> text!
    This is <i>italics</i> text!
    This is <b>bold</b> text!
    This is <strike>strike</strike> text!

    Then all formatting is stripped away!
    (Note that the Drupal text format only allows the <em> and <strong</em> tags. That means the others should be stripped, but those two should be retained. CKEditor is configured to only have the buttons for <code><strong>, <em></strong> and <code><strike>, note that the latter is not allowed by the Drupal text format.)
    If I use the "paste from Word" button, then paste in the pop-up that I get, then press "ok" and finally get to see the result, then only the strong and bold formatting is retained (both are mapped to <strong>, which is fine), but all other formatting is stripped away. I'm not sure what's wrong here, but no matter if you look at the Drupal text format settings or the CKEditor UI settings, in neither case this extremely simple pasting example at least seems very much broken. If I'm doing something wrong, I'd love to hear it.

  3. Normal feature: A “content changed” event like http://alfonsoml.blogspot.be/2011/03/onchange-event-for-ckeditor.html, but built in to CKEditor itself, including support for *all* editing, including source mode, any formatting, etc. (needed in in-place editing to know when we should mark Save button as active).
  4. Major feature: (might already be supported) CKEditor + Edit: make in-place editing of rich text through Edit with CKEditor work well; this includes making the UI work well; which likely involves some sort of embedding of CKEditor’s UI into the DOM structure that Edit provides; this may have a11y implications. If CKEditor already supports something like this, let us know how so we can work on that.
    If the above doesn't make sense to you yet, please see this screencast around the 10 second mark: https://vimeo.com/54104526. There you can see how we embedded Aloha Editor's UI into the DOM structure that Edit provides.
  5. Major feature: (might already be supported) A way to unify CKEditor’s JS loading with Drupal’s JS loading: don’t create “custom builds of CKEditor that contain all plug-ins that you’ll ever use”; instead ensure that Drupal contrib modules can add new CKEditor plug-ins through hook_library_info() (i.e. through separate CSS/JS files, instead of having to include them with the build of CKEditor that ships with Drupal core).
    AFAICT CKEDITOR.plugins.addExternal() handles this?
  6. Normal bug: CKEditor 4 does not load when the Google Chrome dev tools are open! Very weird indeed!
  7. Major task: Improve “paste from Word" — based on the feedback at #1260052-93: Candidate WYSIWYG editors.
  8. Normal feature: (might already be supported) Ability to configure CKEditor to never set inline style attributes such as style="list-style-type:lower-alpha;".
  9. Major feature: CKEditor widgets improvements/missing features, as outlined in #1260052-131: Candidate WYSIWYG editors.
  10. Major feature: Contextually disable/enable relevant buttons. E.g. if the cursor is on an image, disable the strong/em/… buttons. For a concrete step-through of where CKEditor fails at this: 1) Go to http://ckeditor.com/demo, 2) click on the Saturn V rocket image (this selects that image), 3) click on the bold, italics and strikethrough buttons, 4) view source, 5) you'll see the image tag is wrapped in <strong><em><strike> tags… This source of "nonsensical" behavior should be prevented by CKEditor.

Note that if we were to use CKEditor in Drupal core, then at least the first five gaps would need to be fixed before it could be committed, from my POV.


Besides the above, these are the things where the integration needs to be built or improved:

  1. CKEditor + Edit. This is blocked on Gap 4.
  2. Integrate with Drupal 8’s Dialog (e.g. for selecting an image; to present a “native Drupal image gallery” through Views).
  3. Further (quicksketch's, not CKSource's) CKEditor module configuration pages (http://quicksketch.org/wysiwyg/admin/config/content/formats/ckeditor in quicksketch's demo site). Though an excellent proof of concept, their UX and a11y need to be improved significantly.
FredCK’s picture

Thanks for the review Wim. This certainly helps us understanding your priorities, so we can act accordingly.

1. Damn browser bugs! :) Known issue: http://dev.ckeditor.com/ticket/9764 … we have a workaround coming.

2. The demo is using "force paste as plain text", to avoid any issue with pasting. See "CKEditor 4.1" bellow.

3. Ok, doable in fact.

4. I may be confused on this. Are you talking about calling `var editor = CKEDITOR.inline( element )` on "Edit" and `editor.destroy()` after save? We may bring a sample page, if necessary. Just let me know.

5. Yes, supported. Core may have a minimum editor setup, which will be then enlarged by dynamic loading of plugin files. On "source version", CKEDITOR.plugins.addExternal() can be used for that or Drupal can make them loaded automatically. In production, all plugin files can be minified and merged. The only important thing, in both situations, is having the plugin files been loaded after the CKEditor core file.

6. Very weird… we use the dev tools all the time and it wfm. Can you open a ticket at our dev site? We'll try to reproduce it.

7. See "CKEditor 4.1" bellow.

8. Right now, this depends on the plugins you have enabled and some configurations. In any case, see "CKEditor 4.1" bellow.

9. Yes, definitely. Most of the features will be there with CKEditor 4.1. Right now, we'll be focused on providing the definitive integration API… the things that touch Drupal coding. Other CKEditor side only thing will be handled right after it.

10. Fixable, for sure… but based on our experience, you can call it minor feature really.

# CKEditor 4.1

There are two major features planned for CKEditor 4.1: "Widgets" and "Data and Features Activation based on configurations". The first one is already clear.

"Data and Features Activation" is something that, because of Drupal", we have already discussed in our team talks and targeted to the 4.1, but we still didn't put it on paper. We're suppose to start designing it soon, but considering this talk, I've just summarized it in a ticket:

We're very excited about this new feature. We would love to have opinions here as well.

Wim Leers’s picture


1. Yes, stupid browsers! :) That link is the one for CKEditor Widgets, I think you meant http://dev.ckeditor.com/ticket/9746.
2. Okay. Clearly I was doing something wrong!
4. No, that's not what I mean. What I mean is that we need to put the CKEditor UI not in whatever location the UI puts itself by default; we need to be able to put it in a location that the Edit module provides (i.e. inside Edit's own per-field toolbar).
5. Great! Glad that I found the answer myself already. (In quicksketch's code.)
6. Created a ticket: http://dev.ckeditor.com/ticket/9830.
9. Sounds sensible.
10. Okay, great. I figured this might require some UI architecture changes, but it sounds like you're confident your current architecture already enables this.

RE: CKEditor 4.1's "Data and Features Activation based on configurations": I agree that it's the answer to gaps 2, 7 and 8. It's a very important feature indeed!
Thanks for opening that ticket (you may want to link to it from the 4.1 milestone too). I tried to give feedback on it over at https://dev.ckeditor.com/ticket/9829#comment:2, but I currently lack enough knowledge about CKEditor's internals to give proper feedback. It'd be great if you could point me to the right places in the docs.

FredCK’s picture

4. Ok, now it is clear. We've been having this kind of requests since the release of the 4.0. It's already targeted for CKEditor 4.1: http://dev.ckeditor.com/ticket/9387

falcon03’s picture

@FredCK, I would like to ask you some questions about CkEditor accessibility:

  1. As I've always said, the rich text area is very accessible; so, just to have an understanding of how CkEditor works, can you describe for us how you made it so much accessible? Did you use any ARIA role to get this result?
  2. From what I've read, using Windows I can access an help page pressing "Alt + 0"; how can I access the same page (with a shortcut) with Mac OS X?
  3. Using Voiceover I cannot access the options in CkEditor listboxes in the toolbar; did you know this (critical for Drupal) bug? If you did, do you have any planned fix for it?
  4. Is there any plan to make Widgets/Inline Editing accessible?

BTW, I've added some tags, delete them if you think I've done a mistake! :D

falcon03’s picture

Sorry, due to a strange behavior of the screen reader I added the wrong tag for the usability team!

falcon03’s picture

Issue tags: +JavaScript

ok, let's see if it goes well this time...

nod_’s picture

fix tags :)

(edit) crosspost

FredCK’s picture

R: #137

1. Yes, we use WAI-ARIA extensively for all parts of the editor UI. If you analyse the editor DOM structure, you'll find several "role" attributes all around.

2. You should use the "Option" key, which serves as "Alt" on Windows.

3. We have accessibility very optimized for JAWS. Sometimes we need to do some tricks to make things work there, which may impact on the performance of other ATs. We'll be working on accessibility this week, so we'll take this chance to check the status of things with VoiceOver.

4. Yes, definitely. In fact, our efforts on accessibility for this week are dedicated to inline editing. Our goal is having the best accessibility as possible on inline on CKEditor 4.0.1. But it is still to check if it'll be as good as the framed editor. I'm predicting some browsers and JAWs limitations, which will be reported to Freedom Scientific at that point.

FredCK’s picture

R: #135

4. No, that's not what I mean. What I mean is that we need to put the CKEditor UI not in whatever location the UI puts itself by default; we need to be able to put it in a location that the Edit module provides (i.e. inside Edit's own per-field toolbar).

Just a doubt about the "per-field toolbar" behavior... will it be always visible, in a similar way we do it now with the CKEditor toolbar (see demo)? I mean, what happens if you have a long article and you scroll-down the whole page when you're working on the bottom part of the text? Will the toolbar site there far at the top of the text or it'll stick at the top of the viewport?

This is an important usability issue.

Wim Leers’s picture

#142: Heh, that's indeed a usability issue that has been raised. Nevertheless, that's something you don't need to worry about; most likely we'll have to implement something similar to CKEditor's "inline" mode's floating behavior. Does this mean that your answer in #136 (i.e. http://dev.ckeditor.com/ticket/9387) is actually not really the solution?

FredCK’s picture

#143: Sorry for the confusion. I was just worried about that. It has nothing to do with CKEditor in fact. It's all about Drupal. http://dev.ckeditor.com/ticket/9387 will bring the solution for the toolbar location, as you expect.

Btw, feel free to be "inspired" by the CKEditor code for the floating toolbar solution. Just check the floatingspace plugin code ;)

Wim Leers’s picture

#144: will ticket 9387 also allow us to force the UI to remain visible even if the cursor is not currently inside the editable area? In the case of the Edit module, we want to control when the UI is visible.
(I should have made this more clear — sorry for not explicitly stating this in #133 already.)

FredCK’s picture

#145: Yes... btw, I've just pushed this feature at #9387. It does more than what you expect, because I've ported a CKEditor 3 feature... but it does exactly what you want.

quicksketch’s picture

A couple more feedback items from comment #133:

Item #2 (pasting text): Yes the demo is pasting everything as plain text. The paste functionality is quite a bit more flexible but does not truly filter out all non-allowed tags on pasting (yet). We have the ability to add this easily enough I believe.

Item #5 (adding plugins): The CKEditor module I've posted to http://drupal.org/project/wysiwyg_ckeditor includes this functionality already, though improving it to use libraries sounds like potentially a good idea. Right now each plugin just gets a single JS and CSS file (since that maps to CKEditor's capabilities). We could preload the CSS/JS files at page load time, but I think it makes sense to have CKEditor load these files separately upon editor initialization. This cuts down on globally added CSS/JS unless the editor is actually initialized on the page (for example if CKEditor was not enabled on the default text format).

Wim Leers’s picture


Item #2: Indeed, CKEditor plans that for the 4.1 release, see #134.

Item #5: Ahhh! I was working with http://drupal.org/sandbox/quicksketch/1088256, but http://drupal.org/project/wysiwyg_ckeditor is much handier!
And yes, I had noticed addExternal() in your code, that's why I suspected in #133 already that it would be a non-issue, I just wanted confirmation :)

Do you have more gaps to share? Below is the current status for each of the gaps outlined, for clarity for you, I and everyone else.

  1. 4.0.1, BEING FIXED — Render bugs in Chrome: http://dev.ckeditor.com/ticket/9746
  2. 4.1 — Pasting text should match the current text format: https://dev.ckeditor.com/ticket/9829
  3. 4.1 — “content changed” event: http://dev.ckeditor.com/ticket/9794
  4. 4.0.1, INITIAL PATCH READY FOR REVIEW — Ability to put the UI where we want and control when it appears (for use in in-place editing): http://dev.ckeditor.com/ticket/9387
  5. ALREADY SUPPORTED — CKE plugins shouldn’t be included in the CKE build.
  7. 4.1 — Improved pasting from Word: will also be addressed in https://dev.ckeditor.com/ticket/9829
  8. 4.1 — More control over attributes that CKE sets: will also be addressed in https://dev.ckeditor.com/ticket/9829
  9. 4.1 — CKEditor Widgets improvements/missing features: http://dev.ckeditor.com/ticket/9764
  10. 4.1 (if time permits, this is the lowest priority) — contextual enabling/disabling of buttons: they consider this a “minor feature”: https://dev.ckeditor.com/ticket/9855

UPDATE: link for the last gap, was originally posted on Dec 19.

FredCK’s picture

Update on accessibility... it looks like we'll have great support for it on inline editing with CKEditor 4.0.1:

falcon03’s picture

@FredCK#149: great work! I am looking forward to test! :D

Is there an updated demo to test these accessibility improvements? Or can you give me detailed instructions to set up the updated CkEditor?

FredCK’s picture

#150: You can try it at our nightly build: http://nightly.ckeditor.com/standard/samples/inlineall.html


Wim Leers’s picture

@falcon03: Any chance you've already tested it but forgot to report back? :)

falcon03’s picture

@Wim Leers#152: I've tested it using Mac OS X and VoiceOver, but not using Windows and any available screen reader.

My initial impression is that inline editing with CkEditor can be used with Voiceover, but it is not as usable as framed editing. At this point, however, I think that these issues are caused by poor screen reader' support for contenteditable.

I'll test it using Windows as soon as possible but I think that FredCK should have already tested it using windows and Jaws.

I have only a question: when using inline editing, is CkEditor' toolbar shown or not?

Wim Leers’s picture

@falcon03: Yes, CKEditor's toolbar is also shown when using inline editing.

falcon03’s picture

@Wim Leers#154: So we have an accessibility issue. Using Voiceover I can neither see the toolbar at all nor I can use the available shortcuts.
I have this issue only with inline editing.

@FredCK, what can you tell us about this bug? Was it already known? Is there any planned solution?

FredCK’s picture

#155: It works for me with Chrome and VoiceOver on Mountain Lion. I have all editors announced on TAB focusing, their toolbars visible and reachable with ALT+F10.

Do you have more information about your environment as well as how you're testing it?

webchick’s picture

Status: Active » Fixed
Issue tags: -JavaScript, -Usability

Ok, looks like this is settled: http://buytaert.net/from-aloha-to-ckeditor

Please file any follow-up issues in either http://drupal.org/project/wysiwyg_ckeditor or http://dev.ckeditor.com, as appropriate.

Next steps in #1833716: WYSIWYG: Introduce "Text editors" as part of filter format configuration.

Thanks everyone for your contributions to this discussion. Let's get 'er done. :)

webchick’s picture

Issue tags: +JavaScript, +Usability

Didn't mean to do that...

droplet’s picture



Thanks for all great work :)

FredCK’s picture

#157 : That's great news for CKEditor! Thanks again for the Drupal community by supporting us on this. We gonna keep working hard here to make the magic come true ;)

falcon03’s picture

@FredCK#156: ok, the problem was that I didn't expect that pressing option + F10 would bring me to CkEditor Toolbar.

I am testing it using Mountain Lion and Safari, all up to date to the latest.

Anyway I noticed two strange things:

  1. The toolbar buttons were translated into Italian :-);
  2. When I pressed Option + F10, Voiceover automatically interacted with the first item of the toolbar. Is this a desired behavior?

But this issue is marked as fixed (as it should be), so maybe we need a better place to discuss these aspects:
;). @experienced core developers, correct me if I am wrong with creating the new issue.

FredCK’s picture

@falcon03, still I don't see the issues you have listed in the new ticket you have created (1879430), so I'll just leave short comments here.

1. The toolbar buttons were translated into Italian :-);

Yes, that's a feature. The point is that our nightly build contains language files for all languages we support, which includes Italian. The editor then has a feature that automatically detects the user language and shows the editor UI in that language, if possible. This should not be an issue in production environments instead, where the number of available languages is usually reduced and the system explicitly specified the language to be used by the editor.

2. When I pressed Option + F10, Voiceover automatically interacted with the first item of the toolbar. Is this a desired behavior?

Yes, that's the right way for it. With JAWS at least, it is made clear to the user that a toolbar has been reached. All this is regulated by WAI-ARIA roles.

soulfroys’s picture

7.72 KB

About the "feature/issue" (CKEditor VS Drupal language VS browser language, etc.), I'm not sure if it is related, but there is already a small patch (D6) that deals with it very well, bringing flexibility in the choice of language as shown in the image below. It's definitely a feature that should be considered.
Ckeditor auto-detect language

Wim Leers’s picture

#163: Oh, great, that's very good to know :) Thanks!

Wim Leers’s picture

Issue tags: +Spark, +CKEditor in core

Retroactively tagging; this helps the CKEditor folks track the "CKEditor in core" status on the Drupal side. On the CKEditor side, see http://dev.ckeditor.com/query?keywords=~Drupal.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

laogui’s picture

Why don't try the redactor?

klonos’s picture

Because it's not open-sourced for one. If you're looking for other reasons, then please take the time to read this issue from the start ;)

francis55’s picture

Just a few words about what other people are doing...

The best on-line software I have used for image editing is Confluence by the Australian company Atlassian.
Not only do you directly drag-and-drop images into the editor, but clicking on the image (in the editor) displays a little menu with a selection of 3 images sizes, border, link and properties. Once the page is saved, if the image is a thumbnail the end-user can click on it to get the full-size image as a pop-up. The html generated uses <img data-image-src="" src="">; probably a lot of jQuery going on behind the scenes.

On Wordpress you click on an Add media button, which opens an interface where you can upload your image, after which you have a collection of images to insert (based on tinyMCE I hear, but some of it may be custom). Quite basic, but well presented and agreeable to use.

Personally I'm using Drupal 6 and image editing is appallingly badly integrated. The best I could find other than uploading via ftp was a drag-and-drop module that only works in Firefox and integrates the complete url in the src attribute of the img tag. Drupal 7 is probably better but it's so hard to switch versions in Drupal...

Nailing the editor issue would be a major step in getting more people to love Drupal.

PS: just clicked on the image icon in this comment editor, it offers image url: http://drupal.org/files/ with no browse button. Looks like we're still a long way from home...

effulgentsia’s picture

@francis55: thanks for your feedback. This issue was for deciding which editor to add to Drupal 8 core, and that decision was made (CKEditor), so this issue is now closed. I think you'll find the UI for adding and working with images in Drupal 8's CKEditor to be much better than in Drupal 6, but since Drupal 8 isn't out yet, we're not done yet. For example, #2039163: Update CKEditor library to 4.4 and #2061377: Allow image style to be selected in Text Editor's image dialog (necessary for structured content) are just two issues related to image sizing UI.

On Wordpress you click on an Add media button, which opens an interface where you can upload your image, after which you have a collection of images to insert

If you like that approach, then once you get onto Drupal 7 or 8, check out Media.

effulgentsia’s picture

Oh, and for Drupal 6, check out http://mustardseedmedia.com/podcast/episode29, which I think explains the best setup you can get in D6-land.

francis55’s picture

@effulgentsia: thanks for the link, I'll try it out. The filefield thing looks cool.
I have been using CKeditor + Wysiwyg + IMCE in Drupal 6, which does allow you to upload an image, but requires a lot of clicks and relies on rather 20th-century looking interfaces. I think providing a good user experience is not just about choosing the right editor, but making it mesh in seamlessly with all the other functions such as image upload.

giorgio79’s picture

Issue summary: View changes

Just found out after testing extensively that CKEditor is incompatible with Android browsers. Massive ouch. HEre is some more info https://dev.ckeditor.com/ticket/10380
Quoting from that ticket:
"As explained on our compatibility page, Android support is, sadly, not available yet. It's not that we do not want to provide it, the problem is with Google not implementing some vital features of contenteditable support :( Since this is the case, we had to blacklist Android in our env.js file. However, if you want to try it out, you can uncomment the blacklisting code and see for yourself if the level of support that Android browser provides is OK for you, because some features work quite all right already.

You can see the list of open Android bugs by using the ​Android keyword."

Stagger Lee’s picture

Have some feature request.

Can you please, please make Drupal specific skin for Ckeditor ? As it is now nowhere near it fits all themes. Looks like it fell from sky in Drupal.
Take lessons how Wordpress did it with Tinymce editor and WP skin for editor. It fits and looks professional on all themes.

First look at Ckeditor and its skin, and first association is "it doesnt belong here", "it looks different then rest of website".

For now i use this custom skin:

(despite not colorized, exactly as in Wordpress)

Or make it easy for us to easy change skins.