RFC: More stable editing by using CKEditor

Hey everybody,

down below is an RFC which originated at Neos Code Sprint in Nürnberg, after discussions with @aertmann, @christianm, @christopher and Frederico Krabben from CKEditor.

Background / Current State

Currently, we’re using Aloha 1 as editor, which is heavily customized to fit into the Neos UI.
However, Aloha 1 is not well-maintained anymore, as the Aloha team has shifted most of their
attention to work on Aloha 2, which is a very exciting editor concept working without contentEditable,
thus aiming to provide editing without cross-browser inconsistencies.

However, Aloha 2 is still pre-beta quality (as it is a lot of work to create such an editor from scratch); and
quite a lot of features are missing (e.g. Tables, inline images). Thus, switching now to Aloha 2 would degrade
our editing experience; and it is very hard to tell when Aloha 2 will be ready for us to use.

On the one side, we’re seeing feature requests like “wanting to be able to add CSS classes or other markers
to content”, on the other hand we hear problems with the editing stability; especially when e.g. pasting
from Word.

Goal: More Stable and Powerful Editing

On the Neos Code Sprint in Nürnberg, Frederico Krabben (head of CKEditor), visited us for a day and we
had a very open talk and discussion about its features, the development mindset, our current problems
and how they might be solved. See Christopher’s questions and my answers for a rough idea what
areas we checked specifically.

Proposal: ckEditor

After the meeting, I (and the others in the meeting) are convinced that CKeditor would be a really good fit,
for the following reasons:

  • Well-maintained and stable; not just for “classical RTE” but also for the inline-editing-use-case (about the latter,
    I was not sure of this before the meeting)
  • We can easily run our own UI on top of CKEditor (see this example) which Fred has created for us; and
    we can customize it the way we want it to. I think the API is quite fine to work with already.
  • The created HTML is very clean and we can restrict exactly what is allowed inside there. This should e.g.
    fix copy/pasting from Word or other websites
  • the editing experience is very fast and has lots of “small usability features”, e.g. there is a marker which
    allows you to add text in front of a bullet list if the editable directly starts with the bullet list. Generally it
    feels very mature and you just see that it has been “proven by real world”.
  • It has a concept called “widgets” which is essentially the equivalent of Aloha Blocks; allowing for non-
    editable areas inside editables (and can contain other editables again); which would be great for inline
    images, if we want to do that at some point.
  • It has lots of documentation; see http://docs.ckeditor.com
  • It is developed very actively and very fast; and the CKEditor team seems to be really responsive. In fact,
    Frederick and their lead developer joined us over in our slack in #project-ckeditor; so we have a direct
    connection to them in case of questions.
  • Furthermore, they’re a pleasure to work with and are very nice people :slight_smile:
  • They’re currently planning Version 5 of CKEditor; and if we see problems with the API or so, we can
    actively influence the future direction.

Areas of work

Of course there are also some areas which need some work/collaboration, but I think they are very few:

  • Placeholders are not supported as of now, so we need to see how to solve this.
  • We do not know yet how single-line texts can be realized; i.e. where <br> and <p> are disallowed

How to progress

I’d suggest to prioritize this topic for Neos 2.1; I have personally already added a prototype to
my personal GitHub Fork where I’ll continue experimenting and playing around with it.

But first off, I’d of course like your comments & feedback :smiley:

All the best,


Thanks for the write up. Full steam ahead from my side :smile:

How is the mobile / tablet experience with CKeditor ? Currently Aloha just don’t work for mobile, so the next solution should be rock solid in this area from my POV

Before the end of August I will organize a short hangout with Adrian the men behind FrontKit (https://beta.frontkit.io/), less mature solution, but mobile friendly, with some nice feature. @sebastian maybe you can participate to this hangout ?

Sorry for last friday, unable to participate the the ckeditor hangout.

Hey Dominique,

CKEditor supports mobile versions
of Safari (default browser on iPhone and iPad) and Chrome (available
for Android and preinstalled on many Android devices) with minor issues
related to platform limitations.

CKEditor is currently disabled on other browsers available for
Android devices due to irreparable compatibility issues. You can change
CKEditor settings to accept any environment, including mobile ones (at
your own risk), by manually setting the CKEDITOR.env.isCompatible to true, as described in the “Enabling CKEditor in Unsupported Environments” guide, but this is an experimental solution and you will not have the same experience as on desktop environments.

Full mobile support will be introduced in CKEditor 5.
We aim to have perfect CKEditor support for most popular mobile
platforms, so if you encountered an issue on not yet supported
environment please report it on our development site.

Another argument for CKEditor is the accessibility support (have not tested it in detail, but seems really thought through):

Actually CKEditor is the editor I used in most frontend editing stuff over the last months. The only other editor I stuck to was quilljs.com which has a nice templating possibility which Frederico just nailed in his custom style example. Besides that I like it doesn’t introduce it’s own require like aloha (which added a bit of extra complexity), no jquery ui and a more acceptable downloadsize.

Sounds like a good idea to switch :wink:

Hello Sebastian
For 7 years, and I use CKEditor and CKFinder for images and is really perfect.
I realized a CMS for creating web pages for smartphones accessible with a qrcode…

In a current project we used ckeditor for a complex multi-language multi-tab form with up to 25 instances of ckeditor.
There was no time nor money for an asynchronous solution, but at least we can say that the amount of “fired-up” instances did not cause any trouble.

The UX for editors seems to be pretty great, since 150 researchers who updated their profiles during relaunch, gave us no complaint or question about the editor at all!
We assume a lot of MS-Word copy and pasting is going on and it looks like ckeditor is taking care of that pretty well too.

We tested inline editing just for fun during development and we quite liked it, but it didn’t fit the clients requirements.


Pretty cool, thanks for the insight :slight_smile:

The FAQ was a bit outdated. Starting from CKEditor 4.5, the editor is now enabled in all environments:

Prior to version 4.5 CKEditor was disabled in all environments which were not recognized as compatible. Since CKEditor 4.5 the whitelist was changed to a blacklist, so currently CKEditor is only disabled in environments which it is known to be incompatible with (for example Internet Explorer 7 and below and Firefox 3.6 and below)

So in short if anyone had troubles with running CKEditor 4.4 and below on mobile browsers and had to tweak CKEDITOR.env.isCompatible, he no longer has to do it. The most complete explanation of browser compatibility is explained in the Browser Compatibility Documentation


Maybe this issue (https://jira.neos.io/browse/NEOS-1465) is another reason to say good bye to aloha. :wink:

Hey Wiktor,

thanks for your response :smiley: In fact, it is pretty damn cool that you as the CTO of CKSource help linger around in our forum :smile:

Thanks a lot, and I am really looking forward to continue the CKEditor road!

@sebastian, thats a cool project and nice that you got the ball rolling! Has some thing evolved from that yet? What would be the estimated time to implement that into Neos for real?

Another topic which is probably solved with this would be:


Nothing moving currently AFAIK, but I am also strongly interested to see this getting on :slight_smile:

FYI: https://medium.com/content-uneditable/ckeditor-5-the-future-of-rich-text-editing-2b9300f9df2c

Hey everybody,

I originally started playing around with it in the following fork:


  • this would need to be migrated to the new shared repository structure (Dev Collection), and then we could continue working on this :smile:

I am currently lacking some time; so if anybody else would like to migrate, feel free to do this :smile:

All the best,

FYI: There is an Ember-Cli-Addon for CKEditor https://github.com/ebryn/ember-ckeditor written by the Ember-Core member Erik Bryn.

1 Like

Any progress on this?
Aloha currently is a single weakest spot in the Neos usability at the moment.


I guess the state of that fork is still unchanged? This would be something for the time after 2.1, so basically a week to go before someone could dive into this…


Now if we’re doing the React rewrite, we should reconsider the RTE part too.
I think on most projects an RTE would only provide inline stuff like bold, italic and links, while for headings, blockquotes and other fancy parts invite users to use nodetypes.

So here are my requirements for an RTE:

  • Rock-solid editing
  • Plain-text fields, possibly without line breaks
  • Do inline stuff like links and B, I.
  • Strip unsupported block-level tags and attributes VERY well. No more of those tips like copy/paste text to notepad editor to remove formatting…
  • Must be very fast and responsive with hundreds of instances on the page.
  • Ship as an npm module and have lean codebase

Current React prototype uses medium-editor and I really like what I see so far.

In any case we should consider if we want to provide switchable editors, or integrate only one solution.

1 Like