Maybe this issue (https://jira.neos.io/browse/NEOS-1465) is another reason to say good bye to aloha. 
Hey Wiktor,
thanks for your response 
In fact, it is pretty damn cool that you as the CTO of CKSource help linger around in our forum 
Thanks a lot, and I am really looking forward to continue the CKEditor road!
Sebastian
@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 
Hey everybody,
I originally started playing around with it in the following fork:
https://github.com/skurfuerst/TYPO3.Neos_OLD_TO_MIGRATE
- this would need to be migrated to the new shared repository structure (Dev Collection), and then we could continue working on this
I am currently lacking some time; so if anybody else would like to migrate, feel free to do this
All the best,
Sebastian
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.
3 Likes
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…
2 Likes
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
Hey Dmitri,
@dimaip I’d REALLY like to use CKEditor, as we did lots of discussions with the CKEditor guys and I am sure they are handling lots of edge cases… And we have “premium support” by them.
I don’t care if the editor is on NPM or not, we should not limit ourselves by “whether it uses the hip package management” or not
We could make the editor implementation pluggable; BUT I’m 100% for making CKEditor the default, which is shipped with Neos. In my opinion, nothing has changed since we last evaluated the editors; so this decision is still valid…
All the best,
Sebastian
2 Likes
answering to Wilhelm’s post from the React Thread
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
3 Likes
Hey Sebastian!
Just a small comment: what use case will the market accept depends a lot on which use case we push with Neos as the recommended use case. Aiming for COP and structured editing, we should try to show users the benefits of keeping structured data, and not just a big blob of HTML. Things like the default editor config will contribute to it.
For example I was really mad at first, that Aloha didn’t support assigning custom classes, but in the end it pushed me to better solution with which I’m still happy: use nodetypes for custom block level elements.
But in the long run, yes, I agree with decision: support both use case, support switchable RTEs, BUT make the default configuration align with the Neos vision and educate users to appreciate COP more.
Full ack concerning the default config! It’s just that I think that when we bet on some user behavior assumptions, it limits the risk if we take into account that we might be wrong in certain areas or use-cases 
All the best,
Sebastian
2 Likes
I think that many users of Neos don’t think like we programmers do and just want an editing experience like they have with their default text editor (most common: Microsoft Word).
So having the ability to make that possible would surely help Neos to spread further!
3 Likes
Hey guys.
Fully agree with Sebastian here and Dmitri regarding providing stripped down defaults. Same discussion over again.
However supporting switchable RTEs requires way more work than implementing one RTE supporting different use cases, which is exactly what CKEditor does. In terms of consistent custom UI, custom plugins (linking etc.). This is the reason I keep advising against it, we tried it already (Create.js) and it never happened due to lack of interest. Although if there’s anyone willing to put in that extra effort of supporting multiple RTEs, I wouldn’t block it. But I don’t see much benefit of it so wouldn’t make it a responsibility of the core team.
Also other structured editing tools like Contentful and GatherContent provide full RTEs for their BLOB content, which proves that there’s certainly a need for that even in structured content scenarios.
3 Likes
I’d advise against switchable RTEs if it requires much more effort.
For the time being, an editor supporting most of the features one would like to have would suffice. Having an extendable editor (like CKEditor is) would be even greater!
I’ve been there with Frederico at the Code Sprint and his demo was pretty convincing. However I’m not deeply enough into that topic (and other alternatives) to judge, so just one comment regarding:
I might state the obvious, but IMO the fully fledged RTE is just the compromise for a lack of usable alternatives.
If we could get to an editing experience of a regular word processor combined with the power of proper semantics – man that would be a USP.
Concretely it should be possible to make it really easy for the editor to actually let the system know what he’s writing about. E.g. a list of employee names could be a bullet list within a RTE blob - or it’s a collection of employee nodes. But the editor won’t (always) go the extra way to go through the “new node” wizard… So there should be an easier way for those “nested structures”.
4 Likes
Any news on this topic? We really could use some missing features in a project of ours.
Eventually there will be a contribution (
) to the development ;).
The CKeditor is already integrated into the new React-based UI.
I’m not sure if it would be integrated by anyone into current Ember UI.
2 Likes