RFC: More stable editing by using CKEditor

[sebastian (Sebastian Kurfuerst)]

answering to Wilhelm’s post from the React Thread

@wbehncke

The one I can not easily agree with is CK. I absolutely respect the level of sophistication behind this software, and certainly think that it is superior to aloha, but I do have great doubts if it is the right solution for Neos. It is just huge! Why should Neos integrate a Rich text editor, that looks like it aims to be a CMS itself? In my daily experience working with Neos, I always try to restrict the feature-set of Aloha (Which I can’t even do to the degree I would like to). With CK, I would have to reduce the feature set of a battleship down to that of a canoe - for me there would literally never be a scenario in which I could use a full blown CK in a project.

I once thought the same; but then Frederico Krabben (CTO of CKSource) joined us at the Developer Days in Nürnberg last year, and we had a very open conversation about this. You can read up on this in CKEditor questions for Neos and RFC: More stable editing by using CKEditor.

For Neos, I think there are two possible directions which might be required/wished by users.

• Either a very stripped down RTE, creating many structural node types (I know @dimaip does this, @wbehncke and @bwaidelich to name a few).
• or a more full-blown editing experience where you’d f.e. want tables, bullet lists, different header stylings.

I see use cases for both and I’d like Neos as a tool to cater for both use cases, as I simply don’t know which of both cases will be the one accepted by the market in the longer term. (Might also be dependent on different market segments).

I feel that CKEditor, while “historically” being on the “full-blown-side”, is a great fit for the “stipped-down-RTE” as well, because in a nutshell:

• you can excellently control which markup is allowed in the RTE
• we can run the RTE completely headless, with our own UI powering it; as it has a good API. Frederico demoed this to us.
• Still, if we need advanced features like tables, … it will “just work” without breaking in subtle ways.
• They know how to deal with all the various browser quirks.

Additionally, CKeditor 5 will be a great step into a direction which will work extremely well for us. I expect that we’ll basically just use the CKEditor Core library, and integrate it with our custom UI.

Furthermore, there are some “soft facts”, mainly that they’ll support us directly, their core devs even hang out in #project-ckeditor in our slack

Still, I think it totally makes sense to make the editor pluggable; but to me the default choice of CKEditor is quite important because of the reasons explained in this thread.

tl;dr: Use CKeditor as default editor implementation shipped with Neos, but make it switchable.

All the best,
Sebastian