Add optional support for CKEditor 5 in D9 so we can remove CKE 4 from Drupal 10

Looks the best way is create 8.x branch in contrib module to provide drop in replacement for core module to adopt migration.
Later consider to include to core as extra module a-la ckeditor5

Other way is build own implementation on top of https://ckeditor.com/ckeditor-5-framework/

In Drupal 8.x, the best we could do is make this an opt-in feature — we can't make it the new default without breaking lots of sites and contrib modules. Of course the CKEditor toolbar configuration UI would need to be rewritten (because CKEditor works completely differently now). And most likely, the PHP infrastructure to allow Drupal modules to add CKEditor plugins (and make them configurable etc) would likely need to change.

If anybody is willing to take this on, I'd be happy to help you :) But the majority of my time is going to the API-First Initiative right now, and that will not change any time soon.

Well, considerations and possible long chaining issues with other modules to worry about etc. is one thing, the other thing is: how long will CK4 be updated and secured? On the long run, the CK5 adoption is nothing to consider no more, it is possibly a must. Or a possible reason to drop it again. Security first.

@Wim: How can we make it an opt-in feature? CK5 works completely different than CK4 (so far the user reports). If that's the case, the underlying Drupal adaption code to use CK5 will have a massive rewrite, isn't it?

the underlying Drupal adaption code to use CK5 will have a massive rewrite, isn't it?

Correct.

Regarding CKEditor 4 support, via the CKEditor Help Center:

We are determined to continue the CKEditor 4 development and maintenance for some good time still.

The CKEditor 4 roadmap looks as follow:

- Bug fixes and browser support - provided until January 2020.
- Security bug fixes and an extended SLA support - provided until January 2023.

@jrbeeman Thanks, that's a very important addition to this issue :)

@jrbeeman: Good news! Thanks

CKEditor 4 also relies on inline JS in HTML attributes for the interface buttons, which requires using a more permissive Content Security Policy with script-src 'unsafe-inline'

#2789139: [upstream] CSP requires 'unsafe-inline' because of CKEditor 4

The question of Drupal 9 EOL came up if Drupal 9 keeps relying on CKEditor 4 and CKEditor 4 goes unsupported in January 2023, that means that Drupal 10 needs to be released earlier to give people time to update. Our immediate release window before would be December 2022 but then people would not have time to update contribs, etc. So Drupal 10 would need to come in around December 2021 let's say, if we want to give a year for people to update contribs. That is only a year and a half after Drupal 9 is planned to be released. If Drupal users don't need a year because we cannot deprecate so much in Drupal 9 in this timeframe anyway and CKEditor 5 support does not affect that many modules, it could be 2022 June, still "only" 2 years after Drupal 9.

Would be nice to know the feasibility of optionally supporting CKEditor 5 in Drupal 8 so we can bring that into Drupal 9.

Could we create ckeditor5.module for CKEditor 5, leaving ckeditor.module to handle CKEditor 4?

There are definitely some interesting changes when looking at CKEditor 5 and I think this migration will need a lot of effort and work.

When compared to its predecessor, CKEditor 5 should be considered a totally new editor. Every single aspect of it was redesigned — from installation, to integration, to features, to its data model, and finally to its API. Therefore, moving applications using a previous CKEditor version to version 5 cannot be simply called an “upgrade”. It is something bigger, so the “migration” term fits better.

So, the biggest challenge I think is that CKEditor needs to be built from source, or that you customise an existing build. This means that you need `node` and `npm` and then you rebuild a bundle. You cannot add a plugin on a existing build. See https://github.com/ckeditor/ckeditor5/issues/1047
This is not entirely true though, you can add simple features, however, I'm not sure yet how limiting they are. (But it seems that's not the way to approach this)
Either case, this makes it a lot more problematic for contrib. adding new features/plugins than how it was in CKEditor 4. But also, it makes the UI much harder, because you're only allowed to remove existing plugins (without rebuilding).

Edit: It is being discussed here https://github.com/ckeditor/ckeditor5/issues/667 to be able to support adding plugins to an existing build. Looking at it at a glance, it seems to be a lot of work to be done there as well :)

Since CKEditor 5 no longer uses iframes, styling has become easier out of the box. It uses CSS variables, which means as long as the custom styles are imported after the theme you're good to go (or after the rendered CKEditor instance in the DOM) If you need to change theme completely, you'll have to rebuild from source.

I'm interested to know if there are any ideas on how we can support contrib. adding new features to Drupals build, and how more non-technical users should be able to use them without needing npm+node.

The second issue is obviously the migration from CKEditor 4 to CKEditor 5, the data model has changed, sites may use different plugins of CKEditor 4 that may not exist in CKEditor 5 etc. More on that later.

I'm eager to hear more about #16, both about the build architecture and about migration.

In the meantime, I'm optimistically retitling and tagging, based on #12, and if we decide on a different approach, then we can retitle accordingly.

I'm also recategorizing to a major task, since it's doing the work we need to do to keep Drupal secure.

For what it's worth, I really miss being able to use any editor I wanted with Drupal 7. It's a bit more cumbersome to do that now with D8, to say the least (as in, it's well beyond my expertise). Was it maybe a mistake to tie core to a specific editor version? I'm wondering what the longer term plan is. Do we just try to follow Ckeditor as we grow?

I, for one, wish it was easier to use an alternative like Froala or something newer. I like how much easier ckeditor was to use initially since it came with core and was so well integrated. But I'm dying to give my editors something modern like ckeditor 5 or froala and it seems like that may be way down the road.

I'm not trying to be a troll or anything here. Just trying to be a part of the conversation, and understand what the plan is/was. What happens when we put a ton of work in ckeditor 5 and then ckeditor 6 comes out? I just can't tell if committing so much to ckeditor for D8 was a step forward or a step back.

#17: I don't see how we can realistically remove CKEditor 4 in Drupal 9.0.0 considering https://dri.es/making-drupal-upgrades-easy-forever.

#18:

I really miss being able to use any editor I wanted with Drupal 7.

This is not correct. See #1833716: WYSIWYG: Introduce "Text editors" as part of filter format configuration, which introduced the Text Editor (editor) module in Drupal core. Specifically because we wanted to avoid coupling Drupal to one particular rich text editor. I think it just hasn't happened since the community has aligned on CKEditor.

@wimleers re not removing CKEditor 4 as per https://support.ckeditor.com/hc/en-us/articles/115005281629-How-long-wil... it is supported "until 2023", which depending on which month of 2023 it is, may mean a Drupal 9 lifetime as short as 2.5 years until CKEditor 4 goes unsupported, and may be a major dependency bounding the possible lifetime of Drupal 9. Whether 2.5y is too short or not is a question, just looking at boundaries now.

Also that Drupal 9 lifetime of 2.5 years really means 2y or 1.5y then since we need to give people time to adopt the new Drupal version so they can get off of an unsupported editor in time before security problems may arise. That would mean moving on to Drupal 10 alongside Drupal 9.3 or 9.4 latest.

I don't see how we can realistically remove CKEditor 4 in Drupal 9.0.0 considering https://dri.es/making-drupal-upgrades-easy-forever.

I don't see how that blog post contradicts what I wrote in #17. Trying to retitle for greater clarity. Also changing from "5.0" to "5", because AFAICT https://ckeditor.com never refers to it as 5.0. In fact, the latest version on https://ckeditor5.github.io/ appears to be 12.0.0.

Whether or not it's feasible to add CKE 5 and deprecate CKE 4 in Drupal 8 is an open question. I hope it is, but if it's not, we'll need to figure out a plan B.

I, for one, wish it was easier to use an alternative like Froala or something newer.

I did a Google search for "drupal froala" and all I could find is https://www.drupal.org/sandbox/in0ni/2573787. So even in Drupal 7, you'd need to be comfortable with using a sandbox project whose first words on the project page are "This module will no longer be developed". If someone is interested in picking up that project again, I don't think a Drupal 8 port would be any more complex than the Drupal 7 code is. If you try to do it and run into questions or problems, please file a support issue to the editor.module component. We probably need some better docs, but https://www.drupal.org/docs/8/core/modules/editor/overview is a start.

What happens when we put a ton of work in ckeditor 5 and then ckeditor 6 comes out?

CKE 5 will be supported until 2026. Any library that we rely on comes with the risk of cumbersome upgrades once or twice every decade or so. It's also possible that CKE 6 won't be as radical of a re-architecture as CKE 5 was, so the upgrade to it will be easier, but we have no way of knowing that yet (and no way of knowing that any other editor won't get radically re-architected some time in the next 7 years).

I did a Google search for "drupal froala" and all I could find is https://www.drupal.org/sandbox/in0ni/2573787. So even in Drupal 7, you'd need to be comfortable with using a sandbox project whose first words on the project page are "This module will no longer be developed".

Yes, I have seen that sandbox module. I was using the WYSYWG module on D7. I meant to imply, I liked that we had a list of editors to choose from and we could more or less drop in the code we wanted (provided it was supported).

https://www.drupal.org/docs/7/modules/wysiwyg/supported-editors-matrix

Just clarifying that point. It was nice to have (somewhat) pre-built options.

CKE 5 will be supported until 2026. Any library that we rely on comes with the risk of cumbersome upgrades once or twice every decade or so. It's also possible that CKE 6 won't be as radical of a re-architecture as CKE 5 was, so the upgrade to it will be easier

I agree with this. I wasn't so much talking about the actual upgrade there but more about the lag between releases. To me, the bigger issue overall is how far we are behind. I get that there's a risk of cumbersome upgrades once or twice a decade, but the true tragedy is the moment we're in right now where Ckeditor 5 has such exciting features (from a wysiwyg standpoint) while we're still using Ckeditor 4 for the foreseeable future. And it will be tough some day when Ckeditor 6 comes out and we are missing out on those features too.

I'm not sure what the answer is. I'm just speaking from a developer's perspective that has to use Ckeditor 4 when I use Drupal, but I can use any editor when creating a stand alone symfony site.

I was using the WYSYWG module on D7. I meant to imply, I liked that we had a list of editors to choose from and we could more or less drop in the code we wanted (provided it was supported).

Good point. I just now commented in #2619106-5: Drupal 8/9/10 version? about that.

the true tragedy is the moment we're in right now where Ckeditor 5 has such exciting features (from a wysiwyg standpoint) while we're still using Ckeditor 4 for the foreseeable future

I share your enthusiasm for wanting to use CKE 5. However, I don't see Drupal 8's decision to add CKE 4 (back when it was the latest version) to core as an impediment to that. Even for Drupal 7, do either https://www.drupal.org/project/wysiwyg or https://www.drupal.org/project/ckeditor currently support CKE 5? Potentially, we'll get it into Drupal 8 core before either of those projects gets it into them. Or maybe one of them will happen first, and then we can apply the knowledge gained there into getting us that much closer to getting it into Drupal 8 core. I'd love to see it in Drupal 8.8, which will be released on December 4, 2019, but that can only happen if there's people available to work on it over the next few months. DrupalCon Seattle is next week, so maybe a good opportunity to start organizing an initial team of interested people?

The BOF session "Drupal 9 office hours: the dependencies", Wednesday 16:00 to 16:30, is a relevant time to discuss this issue at Drupalcon Seattle.

Hi! CKEditor 5 project lead here.

First of all, great research, @johndevman :) I'm always impressed when people can find all this information scattered around GH and other sites :D

A couple of comments from me:

So, the biggest challenge I think is that CKEditor needs to be built from source, or that you customise an existing build. This means that you need `node` and `npm` and then you rebuild a bundle. You cannot add a plugin on a existing build.

That's true, but we've been thinking about Drupal's case early in the design process and made research how we could allow extending builds. The idea, which worked back then, but would need to be reviewed today, was to use webpack DLLs to build the core and allow loading plugins by a simple JS concatenation. Webpack DLLs allow creating a global registry of modules so plugins could also import them, even if build separately.

I didn't follow what's happening with the DLLs feature since then and webpack changed quite a lot during that time, but I'm quite sure it must be still possible today in one way or another.

However, frankly speaking, avoiding using node/npm today will be harder and harder for you. IDK if there are any plans to e.g. rewrite Drupal's admin panel to React or any other framework, but extensibility of that might also suffer if it will have to work without standard JS tooling.

PS. One more thing that came to my mind was a service like the current CKEditor 4's online builder (https://ckeditor.com/cke4/addons/plugins/all) but which would allow e.g. Drupal's admin panel to download a ready-to-use customized build of CKEditor 5 based on a provided configuration. However, someone would need to sponsor this service and it'd be much heavier than what we're currently hosting for CKEditor 4.

This is not entirely true though, you can add simple features, however, I'm not sure yet how limiting they are. (But it seems that's not the way to approach this)

Correct. It will always be limited to plugins which use relatively standard APIs. Any dependencies still need to be installed and loaded somehow.

Since CKEditor 5 no longer uses iframes, styling has become easier out of the box. It uses CSS variables, which means as long as the custom styles are imported after the theme you're good to go (or after the rendered CKEditor instance in the DOM) If you need to change theme completely, you'll have to rebuild from source.

Not sure if relevant, but you can have CSS included in the JS file (the default setup) or CSS extracted to a separate file (easy). The latter makes it easy to order stylesheets in the right way.

The second issue is obviously the migration from CKEditor 4 to CKEditor 5, the data model has changed, sites may use different plugins of CKEditor 4 that may not exist in CKEditor 5 etc. More on that later.

In the case of migrating the content, there are 3 issues here:

1. Missing support for certain features, in general.
2. Existing features being proposed differently. E.g. CKEditor 5 favors semantical content and the UI follows that meaning that the output may be different and some features are missing (table styling, image styling, etc.).
3. Lack of "free HTML editing" (https://github.com/ckeditor/ckeditor5/issues/592) .
4. Some core options such as "don't autoparagraph" or "enter mode div/br" were dropped and some can't be implemented without major work (which is often a reason why they were dropped).

We're working on reducing the impact of 1-3., but CKEditor 5 will never become a drop-in replacement for any random CKEditor 4 setup. However, based on feedback from the community and our customers, around the end of this year, we should have 1-3. at a level where 90%+ of them should be able to migrate to CKEditor 5 without bigger effort and content loss. The only limitation for them will be that some HTML features, while they will be preserved by the editor, will not be editable in the editor through the UI (e.g. div inline styles will not be editable via the UI). This is due to the fact that retaining HTML markup/attrs is easier than building UI for all those attrs and elements.

Also changing from "5.0" to "5", because AFAICT https://ckeditor.com never refers to it as 5.0. In fact, the latest version on https://ckeditor5.github.io/ appears to be 12.0.0.

Thank you and sorry for the confusion 😞. "CKEditor 5" is the project name. v12.0.0 is its current version.

CKE 5 will be supported until 2026.

The website says "at least until 2026" :). Of course, we can't guarantee anything today, but let me explain where this date comes from and what's likely to happen.

CKEditor 3 was released in 2009. CKEditor 4, while it brought some breaking changes, had the same architecture and most plugins were portable or required just minor code changes. CKEditor 4 will be supported until 2023. This is 14 years.

Why is CKEditor 5 so "breaking"? Because CKEditor 3-4 had no internal data model (or rather – used DOM as such). It was impossible to iteratively move from that point to CKEditor 5's editing engine with its custom data model, virtual DOM implementation, etc. CKEditor 3-4 had a very thin abstraction over the DOM which the plugins used. CKEditor 5 implements a rich framework API which is strongly decoupled from the underlying DOM.

This means that with CKEditor 5 we're able to iteratively improve the implementation and bring new features, without introducing huge breaking changes. This, in turn, means that 2026 isn't something I'd worry about. We had to state give some date, something so we went safe with it. But I'd say there will be no next completely breaking version of CKEditor for a very long time. We both – won't need to rewrite everything cause we'll be able to move iteratively now, and we saw already how much money it cost to rewrite such a project so no business will accept that :D

----------

Hope that helps.

Feel free to ask me anything :)

Excellent discussion here! :)

Is there somebody among the 48 followers of this issue who is interested in leading this effort? I will certainly be available to assist, provide context about past architectural decisions, and so on. It'd be fantastic to have somebody else take this on, to grow the pool of people in MAINTAINERS.txt :) Anyone? 😀

@Reinmar Thanks for the compliment and your valuable insights!

I'm on holiday, so I will just adress the build comments for now!

That's true, but we've been thinking about Drupal's case early in the design process and made research how we could allow extending builds.

🙏

The idea, which worked back then, but would need to be reviewed today, was to use webpack DLLs to build the core and allow loading plugins by a simple JS concatenation. Webpack DLLs allow creating a global registry of modules so plugins could also import them, even if build separately.

Interesting, I've never encountered or used Webpack DLLs before. But I decided to try it out quickly and after a couple of hours I ended up with something that allowed me to extend the build by doing something like:

import BoldPlugin from '@ckeditor/ckeditor5-basic-styles/src/bold';

const ClassicEditor = require('./vendor').default

ClassicEditor.builtinPlugins.push(BoldPlugin)

ClassicEditor.defaultConfig.toolbar.items.push('bold')

export default ClassicEditor

And that file was 8 kb, and the vendor (A slightly modified CKEditor classic build) was 536 kb.

However, frankly speaking, avoiding using node/npm today will be harder and harder for you. IDK if there are any plans to e.g. rewrite Drupal's admin panel to React or any other framework, but extensibility of that might also suffer if it will have to work without standard JS tooling.

This is a great point. It would definitely be valuable to hear from the JavaScript initiative on their ideas and thoughts on extensibility.

PS. One more thing that came to my mind was a service like the current CKEditor 4's online builder (https://ckeditor.com/cke4/addons/plugins/all) but which would allow e.g. Drupal's admin panel to download a ready-to-use customized build of CKEditor 5 based on a provided configuration. However, someone would need to sponsor this service and it'd be much heavier than what we're currently hosting for CKEditor 4.

Yes, I thought about this as well, I personally think that won't be the way to approach it, but it's definitely an approach that exists.

Again, thanks!

Here's a start to triage missing features in CKEditor 5.

To be continued.

Two days ago, we had a big meeting with Drupal CKEditor integration maintainers, Drupal core committers and CKEditor maintainers. I've kept detailed notes of the meeting for all to see :)

Special thanks to Piotrek, Marek, Krzysztof and Wiktor from the CKEditor team!

Conclusion:

• 🥳 D9 can ship with CKE5!
• ⚠️ This is a non-trivial migration!
• 🥺 Not all CKE4 features will be available in CKE5, at least not from the start.
• 👍 We can start working a high-level implementation plan, but certain parts will have to be figured out a later time; blocked on upstream work.
• More nuance in the summary of the meeting notes below and in the full meeting notes :)

Drupal 9 + CKE4 security support

The CKEditor team guarantees security fixes for CKEditor 4 until early 2024. This allows us to ship CKEditor 4 with Drupal 9 without the need to shorten Drupal 9's release cycle 🥳 (if CKEditor 4 security support would end in early 2023 like we first thought might be the case, Drupal 9's life would be shorter than 3 years).

CKE5 versioning & BC guarantees

CKEditor 5 is just a product name. It uses semantic versioning. CKEditor 5 has already seen releases 10.0.0 and 12.1.0 for example, and as you would expect from a project following semver, there indeed are BC breaks. However, they distinguish between two APIs:

1. Integration API — this is the API used by e.g. Drupal to instantiate a CKEditor instance.
2. Plugin API — this is the API used by CKEditor plugins to add functionality to a CKEditor instance.

Since the original release of CKEditor 5, they estimate that they've finalized 75% of the Integration API surface. They think they'll need another year to reach 100%. They can commit to backwards compatibility guarantees for the Integration API in time before Drupal 9 is released. 👍

But the Plugin API still is evolving pretty rapidly. Part of it could be treated the same as the Integration API, with stronger BC guarantees. But part of it they can't/don't want to: they're in a similar situation as Drupal 8 (see https://www.drupal.org/core/d8-bc-policy), with nothing private, and so even though technically pretty much everything is an API, much of it is so low-level that it doesn't make sense to provide BC.

Most CKEditor plugins (both those on ckeditor.com and those custom-written for Drupal projects) should usually be unaffected. We're not going to be the only CKEditor-depending project that will have to deal with this; we'll need to figure out as we go along how we deal with this.

From any HTML a browser can render in CKE4 to only HTML knows how to interpret in CKE5

CKEditor 4 added Advanced Content Filter (ACF) at Drupal's request. Because by default, CKEditor 4 allows any HTML. Drupal wants to be able to guarantee clean mark-up and hence wants to ensure CKEditor doesn't allow entering markup that the @Filter=filter_htmlplugin 's "allowed tags" setting would strip away.

CKEditor 5 has a completely different approach. Put simply, it has to be taught how to handle/interpret/render every HTML tag and attribute. This means it turns things around: by default, much HTML won't work in CKEditor 5 at all today (e.g. the <hr> tag that is overused by some 😅, or data-align). But not only does it not get shown, it'd be lost: in today's CKEditor 5 any HTML that that does not have a CKE5 converter will result in data loss.

The CKEditor team is working on issues related to this, but it's probably safe to assume that CKEditor 5 would not be turned on by default for the Full HTML text format, since that specifically allows arbitrary HTML.

D8's custom drupalimage + drupallink plugins plus associated generic dialogs

This can be implemented in a similar way in CKE5, probably easier.

D8's drag-and-drop configuration UI allowing the end user to assemble a toolbar

Still possible, but the Drupal @CKEditorPlugin plugin type will probably need to gain a CKEditorPluginInterface::getHtmlRequirements() method where it'll need to be hardcoded for each CKEditor plugin that's made available for through the drag-and-drop configuration UI which HTML tags/attributes need to be allowed for that CKEditor plugin to be able to function correctly.

Since CKE5 offers many more possible UIs rather than a single one, it will possibly require Drupal owning a particular UI with choices that make sense for Drupal. See https://ckeditor.com/ckeditor-5/demo/#classic vs https://ckeditor.com/ckeditor-5/demo/#balloon-block for example.

Selective enabling of features can still be achieved without a JS build process since CKEditor plugins can be part of a build without being initialized.

D8's drag-and-drop configuration UI allowing site owners to add more plugins without a JS build process

The CKEditor team needs to first figure out webpack DDLs, as mentioned by @Reinmar in #28, to allow for contrib modules to add additional CKEditor plugins.

… or is it okay to require a JS build process?

CKE4 was iframe-based, CKE5 is not; how can we make it visually match the front end theme?

Impossible until Shadow DOM. The CSS prefixing strategy used by Settings Tray is the only available alternative today (see #2826722: Add a 'fence' around settings tray with aggressive CSS reset.).

"View source" functionality

Not yet supported. Related to From any HTML a browser can render in CKE4 to only HTML knows how to interpret in CKE5. Should be less necessary now. Note that viewing source is easy to support, but editing source is what most people use it for and that's challenging.

Copy/paste functionality

Paste-from-Word/Google Docs is supported, but not as complete as for CKE4 yet.

Can D9 offer CKE5's collaboration features out of the box?

No, they all require a commercial license.

for that CKEditor plugin to be able to function correctly.
Since CKE5 offers many more possible UIs rather than a single one, it will possibly require Drupal owning a particular UI with choices that make sense for Drupal. See https://ckeditor.com/ckeditor-5/demo/#classic vs https://ckeditor.com/ckeditor-5/demo/#balloon-block for example.

It would be pretty super cool to keep the doors open for allowing contrib to provide their own builds. Drupal would probably need to maintain its own official build as mentioned though :)

I think if:

… or is it okay to require a JS build process?

is okay, there could be some interesting doors opening here :)

@johndevman Can you explain which interesting doors you see opening? :)

#34
That was mainly for the build idea.

Conceptually I think we should try abstract the build process in a way, that would allow contributed builds (UIs) and plugins work together. With DLL(s) that would be hard.

Not saying we must or should do that, but I think it's a fair idea, given CKEditor 5 is more of a framework rather than an single kind of editor.

But if we feel strongly about not introducing these dependencies to Drupal end-user I'm hoping Webpack DLLs will work as intended!

The CKEditor team needs to first figure out webpack DDLs

Is there some way we can follow that progress? It's interesting! :)

Finally;

Impossible until Shadow DOM. The CSS prefixing strategy used by Settings Tray is the only available alternative today

Aren't there polyfills available?
https://github.com/webcomponents/webcomponentsjs

Adding issue credit for contributors whose d.o usernames I know who participated in this very important discussion. :)

(Well, also me.)

Summarizing the plan as a release manager (above about D9 shipping CKEditor 5 support could be misread) 🙂:

1. Drupal 8 will retain full support for CKEditor 4 until its end-of-life in November 2021.
2. Drupal 9.0.0 will maintain a dependency on CKEditor 4, so there is no need to EOL Drupal 9 before December 2023. That said:
3. We will provide optional CKEditor 5 support in some D9 minor release, likely starting out as an experimental module. (We'd consider even shipping this module in 9.0.0 if it's ready by then, because it's not so much a feature per se as a dependency compatibility.)
4. We'll use the D9 cycle to perfect our CKEditor support, and deprecate CKEditor 4 support once CKEditor 5 is fully supported.
5. D10 will require CKEditor 5.

Thanks everyone!

(Edited to clarify D8 support and mention when CKEditor 5 will be deprecated in D9. Also edited for silly typo; thanks @frob.)

@xjm I think you mean D8 will retain full CKEditor 4 support till EOL 2021

Updating the issue title for what I think #42 is indicating.

#32 Great work!

Here is some comments:

in today's CKEditor 5 any HTML that that does not have a CKE5 converter will result in data loss.

I don't think that is acceptable - especially as HTML is the markup language standard. So any custom HTML should be supported. I think that's the #1 reason CK 5 adoption feels difficult.

Fortunately there is a pretty simple solution:

- When importing unknown elements, just create a 'component' for them during loading on the fly. That should be doable with some DOM document parsing.

I have not reviewed the API for registering components in detail, yet - but it feels doable. In the worst case a markup component that is encapsulated would be used.

The same is true for view-source and editing source. The main problem with that is to e.g. continue supporting the collaborative editing or track changes features.

As those are key properties of the "Letters" offering, I can understand that there is hesitation to re-introduce the wild west by allowing HTML editing.

On the other hand this is just a model transformation problem and how changes in one model (HTML) affect another model (CK's Virtual Dom).

I think the 90% case for not allowing wild-west and having a "Full HTML" model that does not allow collab editing / track changes / etc. is the way to go.

But as soon as CKE 4 is gone, CKE 5 will need to have an answer for that particular use case. Especially as plugins, etc. should not need to be written twice for every version.

Supporting the full set of HTML is crucial for some use cases, it's possible that some trade offs need to be made then however.

CKE4 was iframe-based, CKE5 is not; how can we make it visually match the front end theme?
Impossible until Shadow DOM. The CSS prefixing strategy used by Settings Tray is the only available alternative today (see #2826722: Add a 'fence' around settings tray with aggressive CSS reset.).

There is another way that we should explore - unless themes in 2024 are purely web-component based and fully encapsulated (which would be better of course):

- Load CK5 in an iframe like before and load our frontend-theme CSS styles file like usual

As we can run the whole of Drupal within an iframe in theory (given proper X-Frame headers), it's also possible to load CK5 into an iframe - even if it was designed otherwise

Usually however the CSS for e.g. font-style is pretty small and encapsulated in one styles.css file, so just copying those rules and prefix them with e.g. .cke5 is not that much work -- even if it's not automatic.

So I am not sure that is that big of a problem.

Can D9 offer CKE5's collaboration features out of the box?
No, they all require a commercial license.

That is correct, however there are almost-OSS alternatives that should be easy to integrate with CK5 (which Drupal could ship with).

One such integration is https://firepad.io/. Unfortunately it currently needs a FireBase database as backend, so is just "OpenCore" not OSS, but it should be possible to write a small NodeJS application storing to RethinkDB that replaces the FireBase adapter.

So if someone really wants that for Drupal + CK5, it is possible with some (but not too extensive) effort.

Some more comments after reading the tutorial how to write a placeholder plugin. (https://ckeditor.com/docs/ckeditor5/latest/framework/guides/tutorials/im...)

CKEditor 5's model idea in theory is great and it mirrors web-components in many cases.

In fact it is probably a great way to configure web components.

What I dislike most about the model (and I am writing this here as that directly impacts the Drupal integration) and what is also the reason for no-longer-support-HTML is that they have choses to upcast and downcast things.

e.g.

the model:

<span class="placeholder">{name}</span>

with the implementation of e.g.

<span class="placeholder">{time}</span>

is represented internally as:

<placeholder name="time"></placeholder>

or shorter could be even:

<placeholder name="time" />

Looks familiar? Yeah - it is. That's a standard web component.

But instead of outputting markup like:

<placeholder name="time">
<span class="placeholder">{time}</span>
</placeholder>

for saving into the database or just:

<placeholder name="time" />

they output:

<span class="placeholder">{time}</span>

That's nice and convenient for Drupal as we can output that directly and it's still totally bad (architecturally), because now you need to write a converter to convert the HTML code back into the model.

What I think would work much better is to just output both:

[$html, $output]

$html is for display purposes, $output is for re-loading the CKEditor.

Boom! You never leave the model space for output and can still display the final result.

And you save writing 100s of converters and every web-component / Vue component / React component can automatically be used as a display model. Just need to write the UI and define the schema.

And HTML is just what it always was, HTML - because you don't need to parse HTML to get back your model VirtualDOM Ouput, HTML is just HTMLElements that are in between the other models, basically a <raw></raw> component.

View / Edit as HTML would still not exist as of now, but the editors frankly don't care if there is a <span> or a <placeholder> tag they are editing.

Maybe a <raw> or <html> element could be implemented by Drupal to remove the problem with non-standard HTML. The idea would be to convert data _once_ then keep the raw or html element to avoid having to re-parse.

So far my thoughts on that issue and how it could be circumvented, no idea if it's possible to run CK5 without the upcast converters though, but it would make things so much simpler and remove a lot of the complexity ...

I would love to see Drupal 9 go full web component with all this. Turn the traditional "body" field into a list of entity references to simple entities that are rendered via web components mixed with simple non-reference based web components.

in today's CKEditor 5 any HTML that that does not have a CKE5 converter will result in data loss.

Immediately thought of the footnotes module that allows <fn></fn> tags. Preserving stuff like this in the case where there's no CKE5 converter (even if it's not editable until one is added) does seem like a requirement yeah.

I don't think that is acceptable - especially as HTML is the markup language standard. So any custom HTML should be supported.

You're right that HTML is the standard, but not every HTML is a proper rich-text.

I hope it's not a too far-fetched analogy, but here it goes... JSON could be considered a proper format for storing data (and many apps use it), but there's a reason why Drupal doesn't use it and instead uses a proper DB with a proper schema. It's also why you don't allow the users accessing the DB and changing records there by hand.

Allowing people to insert any HTML into the editor and expecting that it'll work out of the box would be like expecting that behind a CMS you have an unstructured database and that users can change it by hand and that the CMS will somehow handle that when rendering its frontend or backend sites.

However, just like in a proper CMS, in CKEditor 5 there are means to extend the schema and write code which handles changing the model (converters, commands) and which displays those changes back to the user (converters). You can register whatever elements/attributes you need and input/output any HTML. But you need to code these little features, that's why it does not work out of the box for any HTML input. Also, at this stage (when extending the schema and writing converters) you're telling the editor about the semantics of those HTML features, and that's why it cannot be done automatically for any imagined feature.

That said, we agree that wider HTML support is important for easier adoption of CKEditor 5 and we plan to work on it this year. In other words, we'll work on reducing the cost of "teaching" the editor how to handle certain HTML elements/attributes to the real minimum. The most likely solution will be a declarative format in which you will be able to list HTML tags and attributes that the editor should accept, but you'll also need to specify some really basic semantics of these features (e.g. that a <video> is an "object" while <div> is a "block").

On the other hand this is just a model transformation problem and how changes in one model (HTML) affect another model (CK's Virtual Dom).

It's not only about that. If the only role of the editor would be to display its data, then more or less yes (although, not really). However, the user is also interacting with this data. The editor features such as typing, backspace, enter key need to know how they should modify that particular model structure. The editor must know where the selection can be placed and where not. The bold feature needs to know where it can be applied. The text alignment feature needs to know to which model elements it's applicable. The image feature needs to define what happens when you click on it in the editor and how selection navigation around it should behave. It needs to tell the editor that an image can only be deleted together with its caption. And that the caption cannot be split by pressing the enter key or totally deleted alone.

CKEditor 4 and the "classical editors" try to hardcode all those things for as many HTML features they can. That's why it seems that you can load "any" HTML into such an editor and it just works. But, first of all, it's never "any" and it comes at a huge cost for editor and plugin developers because trying to predict how any HTML should behave greatly increases the complexity of the whole solution and ties all the things together, meaning that, in the end, it's harder to maintain and far less flexible.

CKEditor 5 and (I think) all the modern editors went in a different direction. In CKEditor 5 everything is a plugin (even support for typing and paragraphs). You can re-compose and extend it in incomparably more ways than any of the classical editors.

Yes, that comes at a cost. Yes, the cost can be significant now (you need to learn a bit about CKEditor 5 itself). However, we're at the beginning of the CKEditor 5's life and we started designing and implementing it from the low-level building blocks. The higher-level APIs (like the above mentioned declarative way to define which HTML features the editor should understand) will come later.

BTW, if you need a really quick intro to CKEditor 5's architecture, you can check my talk on this year's Neos Con: https://youtu.be/HtZcqtTFXRg?t=2869 (first Sebastian introduces what kind of feature we would like to build) and then I take over and introduce CKEditor 5.

There's also the second part of this talk, where I show a PoC of how structured content could be made editable in CKEditor 5. Besides the whole concept, the interesting thing can be how easy the rendering can be made (spoiler: with a single render() function). This part starts here: https://youtu.be/HtZcqtTFXRg?t=3678.

Finally, if you'd like to understand a bit more about the complexity behind building a WYSIWYG editor, there's my other talk about that precisely :D https://youtu.be/0XBB3seernY?t=16842

CKEditor 5's model idea in theory is great and it mirrors web-components in many cases.

Not really :) Webcomponents are the way to introduce new elements. The editor model, while being a tree structure, differs from the DOM in more ways than just that. More in: https://youtu.be/HtZcqtTFXRg?t=2869

But, on the other subject – there's a great fit between webcomponents and CKEditor 5. The main goal of custom elements (which are the base for webcomponents) is to create an interface for the underlying "thing". That's also what we do in CKEditor 5 with the model, even though we render normal HTML. E.g. the model's representation of an image looks like this:

<image src="..." style="aside">
    <caption>The caption...</caption>
</image>

The DOM will however look more like:

<figure class="image" class="image-aside">
    <img src="...">
    <figcaption>The caption...</figcaption>
</figure>

Now, you don't have to store this <figure> in your database. You can certainly output the <image> meaning the model<->view conversion here will be 1:1.

You also don't have to render that <figure> to the user. You can render a custom element called <x-image>(unfortunately, custom elements must be prefixed) and handle rendering of it in your webcomponent's definition. This means conversion here will be again 1:0.99.

The remaining part is telling the editor that this should behave like a non-editable object (schema definition). And that the content of the <caption> element needs to be editable. If you saw https://youtu.be/0XBB3seernY?t=16842 you perhaps have an idea now how simple it could be made to define such features in the editor.

But there's one downside... if you want the user to be able to copy those webcomponents from your editor and paste it to some other website, you need the actual, real DOM structure. Otherwise, if we'd place the <image> in the clipboard and you'd paste that on another website (email editor?) you wouldn't see anything. The image would not work. That's why we need at least one real-HTML representation of the content.

Now, the render() function I proposed in https://youtu.be/HtZcqtTFXRg?t=3678 solves that automatically (as long as you don't use custom elements). If you want to use custom elements, then there's a question whether the editor will be able to stringify them (get the underlying innerHTML of them).

One last thing, regarding the placeholder feature's output – it completely up to you how you want to store it in your database. You can write a converter which returns a <placeholder> element when you get data out of the editor. At the same time, you can still display a normal <span class=placeholder> in the editor which will work out of the box (no need to implement you custom element, no problems with the clipboard). CKEditor 5 implements two separate pipelines – one for getting/inputting the data and second for the editing in the editor. They are independent and their only touching point is the model.

The official editor features output more or less the same structure to both pipelines – that's because we want to make using the saved HTML easier for integrators. If we'd output custom elements, they'd need to write converters on their backend. Kinda like they need to do now if they want to support any HTML in the editor ;).

PS. Sorry for posting 3 comments but I wanted to lessen the risk that I'll never post anything :D

That PoC about structured content inside CKEditor is crazy insane. I've never thought that this is possible. Real eye-opener. Seems like the future of content editing. Thank you Piotr.

#45:

- Load CK5 in an iframe like before and load our frontend-theme CSS styles file like usual

➕

#48: thanks for the <fn> example: that's a very clear one. Your point is not that CKEditor 5 must render it, your point is that CKEditor 5 cannot cause this custom HTML to be lost, because that would amount to data loss.

#49: Great to see you here, @Reinmar, thanks so much for participating in this discussion! 🙏

you're telling the editor about the semantics of those HTML features, and that's why it cannot be done automatically for any imagined feature.

This is the crucial bit here: the semantics are essential for CKEditor 5 to offer integration with its entire feature set. But hopefully it'll be possible to gracefully degrade and hence not omit/delete/lose custom HTML whose semantics are not defined, but just make it invisible and non-interactive (read-only). I think we should just wait and see where https://github.com/ckeditor/ckeditor5/issues/592 leads us though :)

#51:

Now, you don't have to store this <figure> in your database. You can certainly output the <image> meaning the model<->view conversion here will be 1:1.

To prevent readers of this from concluding Drupal has been storing template markup in its structured content, I need to chime in on this, even though I know that you know Drupal doesn't do this.

Drupal never stored <figure>. Drupal stored <img data-caption="The caption" src="…">. This is why Drupal insisted on having the CKEditor Widget system that you built. We're also using this in #2994696: Render embedded media items in CKEditor, where <drupal-media …> represents an embedded video, image, document, [whatever] from Drupal's media library, yet the HTML the end user sees is something else entirely.

#52: We've actually been doing that in Drupal 8 already, thanks to CKEditor Widgets. Also see https://wimleers.com/article/drupal-8-structured-content-authoring-exper... — in the comments on that issue we discussed exactly this five and a half years ago :)
That being said, what @Reinmar demonstrated there is of course going much further and is very cool. Nonetheless, it's the same principle.

Quoting #32:

• 👍 We can start working a high-level implementation plan, but certain parts will have to be figured out a later time; blocked on upstream work.

I've updated the issue summary with such a plan. I am the lead maintainer of the CKEditor 4 integration. I don't want this to be blocked on me, nor do I necessarily want to be the person do bring CKEditor 5 integration to Drupal. That's why I wrote this in #29:

Is there somebody among the 48 followers of this issue who is interested in leading this effort? I will certainly be available to assist, provide context about past architectural decisions, and so on. It'd be fantastic to have somebody else take this on, to grow the pool of people in MAINTAINERS.txt :) Anyone? 😀

That's why the plan that I added to the issue summary is written in such a way that it should not need me at all. I recommend whomever starts working on this to first watch @Reinmar's talk at https://youtu.be/HtZcqtTFXRg?t=2869, that gives you a good sense of the high-level CKE5 architecture.

And here's a PoC to get us started. CKEditor 5 loads, but that's about it. It's littered with @todos, and most things you'd expect from a rich text editor don't work right now.

(To be clear: that's not CKEditor 5's fault — that's why this is a PoC! Thanks to this PoC I discovered the incompatibility between CKE4 and CKE5! 🙏)

I wrote the plan by inspecting core/modules/ckeditor and the docs on d.o. This incorporates relevant bits from https://docs.google.com/document/d/1CmchTY_W9TafhEf7wREDGMllR4jaFyg5VsNf... (see #32).

Are there any work being done on this integration? CKeditor 5 feature's, like collaborative writing and comments, are so awesome for editors that I'm sure we could get organizations to sponsor the development to speed things up.

RE #32

CKEditor 5 is just a product name. It uses semantic versioning. CKEditor 5 has already seen releases 10.0.0 and 12.1.0 for example, and as you would expect from a project following semver, there indeed are BC breaks.

Should we switch to referring to CKEditor more by the actual version and not the marketing release?

Should we switch to referring to CKEditor more by the actual version and not the marketing release?

I think for purposes of this issue, it's useful to refer to it as CKEditor 5 (the product name). It is precisely the fact that CKE 5 is an entirely different product from CKE 4 that makes this a large issue and requires us to have both in Drupal 9.

Once we have CKE 5 in Drupal 9.x core, then I think we can start referring to it by its version. I.e., we might have issues at that time along the lines of "Upgrade to CKE 13", which will hopefully be much more straightforward upgrades that don't require us to have two different major versions in the same Drupal core release.

Other than these issues though, where else do you suggest that we evaluate how we refer to the CKE version? One place I can think of is in documentation / handbook pages, but that's probably moot until after we've committed CKE 5 (whether that's v12 or later) to core.

I think it makes sense to refer to it however the CKEditor team refers to it.

From #32 @Wim Leers wrote about two parts. But it sounds like there are at least three.

1. Integration API — this is the API used by e.g. Drupal to instantiate a CKEditor instance.
2. Plugin API — this is the API used by CKEditor plugins to add functionality to a CKEditor instance.
3. UI — This is the Front-end that seems to change the most between the marketing releases.

We should find out if the there is a version number associated with each of those APIs and use those as that seems to be the integration points.

As far as a D9 feature set goes; Drupal 9 includes CKEditor 5! Sounds good but it gets confusing when trying to jump in and lend a hand. It is also confusing when attempting to reconcile documentation between CKE and Drupal. But this should all probably go into the issues in which the work is being done on the integration.

See also ckeditor5_sections for contrib which uses (parts of?) ckeditor5.

I spoke with Wim and Gabor at DrupalCon and while I really appreciate the enthusiasm and the working code (fantastic work), this issue does not mean that Drupal 9 will ship with CKEditor 5, but rather that we need a replacement for CKEditor 4.

I think we should - as a community - select the best editor solution. Therefore I created:

#3091226: [META] Select the best modern editor for Drupal 9

Gabor suggested to postpone this issue on that one, however I am not sure.

Maybe it might be better to make it a child issue of the new plan issue? Or maybe it might be better to have separate modules in contrib where we try things out and report back the findings on the main meta issue?

New features can be introduced in >= 9.1.0

Excited that we are periodically evaluating our dependencies to see if they best match our needs. Agree that we need a set of requirements and process to determine if CKEditor 5 or another editor best fits that. We should continue to consider our ability to work within the Editor's project as a key consideration. We need to ensure we can get what we need out of the editor.

We've been able to work well with CKEditor's codebase and that dev community has been good work with. So we've already got those boxes checked there.

Shouldn't we have a few test implementations for the editor module to ensure a switch like this isn't a huge deal? How are we currently testing our theming and database systems to ensure they work with multiple systems.

Another consideration is quickedit. What is going to happen there when all this is decided.

Absolutely, but I think that's the focus on the #3091226: [META] Select the best modern editor for Drupal 9 issue. At this point it looks like there's been a little exploratory demo making. But there should be more. And with the efforts we'll find more and more about the details that help make the final decision.

For a look at the demos the Tag Consulting team put together, check the link to tag1's article in the issue description of #3091226: [META] Select the best modern editor for Drupal 9

I hate to be the one raising this...
but

Long story short – CKEditor 5 doesn't work on IE11.

https://github.com/ckeditor/ckeditor5/issues/330#issuecomment-547436626

See #3080068: [policy, no patch] Define usage heuristics for browser support for determining the criteria to drop IE11 or not.

An extremely important aspect to be remembered is that — because of the difference in features — the data produced with CKEditor 4 may not be compatible with CKEditor 5 (which may lead to data loss).

Extensive analysis, data verification and tests should be performed on existing data. If necessary, you will need to develop conversion procedures to avoid data loss. A relatively simple yet efficient strategy of adopting CKEditor 5 into existing systems might be using CKEditor 5 for creating new content and the old editor for editing legacy content.

https://ckeditor.com/docs/ckeditor5/latest/builds/guides/migrate.html

Using ckeditor 4 to edit content is a non-starter if it's unsupported.

Data verification on all Drupal sites is also a non-starter - although we could verify the markup created by all of the available buttons that core provides.

although we could verify the markup created by all of the available buttons that core provides.

This too is impossible — not all markup created in D8's CKEditor 4 is necessarily created using CKEditor buttons.

Quoting the issue summary:

Related: ensure that arbitrary HTML is not lost — see https://github.com/ckeditor/ckeditor5/issues/592 and comments #49–#51.

So see #49, #50 and #51. I don't know if that is still accurate. About 15 months have passed since then!

Hmm 15 months have passed since those comments, but no updates since then either, so seems unlikely much has changed.

This too is impossible — not all markup created in D8's CKEditor 4 is necessarily created using CKEditor buttons.

Good point, so we are quite stuck then without help from ckeditor here.

> Good point, so we are quite stuck then without help from ckeditor here.

All the more reason to not bake in an editor and focus on extensibility.

Not trying to stir up a not-built-here mentality. After using gutenberg in production, I would prefer to have something almost exactly like that. Core needs a html block level editor. ckeditor 4 should just be deprecated/moved into contrib. Hard cut or we will be stuck here beyond Drupal 10.

There are many Drupal sites using the paragraph module to build up pages and other content.
A Gutenberg editor that is replacing ck editor would be a huge overkill for those scenarios.

There already is a Gutenberg contrib module that you can use. I think If CK editor is replaced. it should be a light weight editor that can be used in many scenario's But this discussion is off topic here, and the discussion is already in an other ticket. #3091226: [META] Select the best modern editor for Drupal 9

100% agree to Martijn. IMHO paragraph is superior to Gutenberg because it still creates programatically distinguishable Drupal entities and not one huge content blob. If we'd want that we could just as well use Wordpress ;-)

So, I think using paragraphs is also more the "Drupal way" of solving things because one of the aspects of Drupal is obviously that you don't just store arbitrary data, but you can get it out in a structured way which allows a multitude of things like content reuse, exporting data, swappable widgets etc. that would not be possible as easy otherwise.

It's important that the move to CKEditor 5 doesn't break accessibility. There are a reasonable number of open accessibility issues but not sure how comprehensive the testing of this has been.

I updated @wimleers PoC from #56 so this module can install on D9, and made a few small changes to fix the javascript errors and let the editor detach correctly.

Updated the global variable name, and used the latest version of CKEditor5 (23.0.0).

I removed the InlineEditor for now, just to focus on the ClassicEditor.
Using the cdn url caused a problem where the ClassicEditor global wasn't set before the Drupal behaviors script ran, so I added the js directly as a core library. I believe this is the same problem as #1988968: Drupal.ajax does not guarantee that "add new JS file to page" commands have finished before calling said JS

In editor.js the onChange gets registered immediately after the attach- before the create promise finishes- so there is no editor instance to set an event on. I'm not sure how to fix that without making changes to editor.js.

It was very cool to make commits on a branch on an issue fork, it's my first time working this way!

Why are we moving forward with CK5 when #3091226: [META] Select the best modern editor for Drupal 9 isn't resolved and when it doesn't provide any solution to backwards compatibility? As far as I have read in these comments there is still no solution to the data loss problem.

Would it be better to include a different lagacy style editor to take over for CK4? What options are out there. TinyMCE is the only one that comes to mind but I don't know if the license is compatible.

@frob: Please see https://www.drupal.org/project/drupal/issues/3091226#comment-13823027 for an answer for the direction forwards.

Posted some more updates to the prototype, there is now a fix for the problem I had regarding attach/detach, and registering the onChange event.
Ran into a problem with a textarea marked required, such as a comment body. HTML5 validation prevents an ajax submit from even happening so it was impossible to click the submit button.

This seems to be related to a very old issue that Wim and nod posted on in https://dev.ckeditor.com/ticket/8031
There was a patch in Drupal #1954968: Required CKEditor fields always fail HTML5 validation that was later removed in #2571755: Required text field with a Text Editor + AJAX form rebuild = unsubmittable form after the CK team added that feature into CKE4: https://github.com/ckeditor/ckeditor4/commit/385a822

As far as I can tell this does not exist in CKE5, so for now I added a variation of this code into the behavior.

I added the InlineEditor in as well, which in CKE5 terms is the DecoupledEditor since it can be easily attached to the quickedit toolbar. To have both Classic and Decoupled requires a custom build, I put the src files I used into the ckeditor5 module folder so that they can be altered, and moved the library back into the module folder instead of core.libraries.yml.

To build the minified file, from the ckeditor5/js/src folder run npm install and npm run build. I used very minimal config and plugins for this prototype.
To add more plugins, npm install --save $plugin_name, then import it in the custom.js file.

I'm going to look more into how filter_html works with CKE5, and how plugins can be added, selected and overridden.

I have been digging a little deeper into how to integrate CKEditor5 with Drupal,
using the plan in the IS as a guide.

There are several items which fall under the same problems related to arbitrary html and the way CKE5 plugins work (requiring a build step).
Specifically Critical technical aspects: 1, 2 and Critical integration aspects: 1, 2.

I understand that how to handle arbitrary html is a high priority for the CK team so it may not be something we should stay blocked on in Drupal.

Evaluate all of Drupal core's CKE4 plugins: DrupalLink, DrupalImage and DrupalImageCaption. For all of these, we should ask ourselves whether we truly need Drupal to maintain custom integration code for them.

It does seem as though most of these core modules are not necessary for CKE5, the markup output by CKE5 does not require the same overrides.
In the case of DrupalImage, the extra data attributes can be preserved with a custom CKE5 plugin, and CKE5 has improved markup and UI for image captions.

Evaluate all Drupal's choice to not use CKE4's dialogs but our own server-side rendered ones to allow Drupal modules to hook_form_alter(). (This is true for the plugins mentioned in the previous bullet.) Perhaps in Drupal 9 we can choose to not offer Drupal-PHP-alterable forms and require developers to customize their CKE5 build?

A big part of the CKE4 DrupalImage plugin and the editor module relates to the image upload form, CKE4 is overridden to open a Drupal dialog.

Should we try to copy that with CKE5?
It has an upload plugin which can do a direct POST.
Maybe we would be better off removing this reliance on the ajax system (and dialog)?

An aside to this question is whether we should be using an inline image upload at all, now that Media is in core.
See the discussion in:
#3073901: Determine an upgrade path from CKEditor image button to media library

An aside to this question is whether we should be using an inline image upload at all, now that Media is in core.

I think we should, at least until #3073901: Determine an upgrade path from CKEditor image button to media library is resolved.

A big part of the CKE4 DrupalImage plugin and the editor module relates to the image upload form, CKE4 is overridden to open a Drupal dialog.

Should we try to copy that with CKE5?
...
Maybe we would be better off removing this reliance on the ajax system (and dialog)?

I'm intrigued by the idea of using CKEditor dialogs for simplicity. However, I'm not sure how we expect those dialogs to behave: should they be considered as part of the CKEditor experience or should they be considered as part of the Drupal experience? If we expect them to be part of the Drupal experience, it might still be worthwhile using Drupal Dialog. Having two different dialog solutions mean that people working with dialogs might have to override or style them separately.

should they be considered as part of the CKEditor experience or should they be considered as part of the Drupal experience?

In CKEditor5 they have gone away from using dialogs, in favor of more of an inline editing bubble. The workflow is slightly different as well, for inline images for example in CKEditor4 the Drupal dialog is responsible for uploading the image, setting attributes like alt, then sending them back to the editor. In CKEditor5, it could handle the file browsing, enable drag-and-drop for a file upload, show a progress meter- and then POST just the file contents to Drupal. The alt text or other properties can be configured by their UI,

Having two different dialog solutions mean that people working with dialogs might have to override or style them separately.

It also means synching configuration- CKEditor5 would need to be modified with a plugin to allow arbitrary new attributes for example. If a user altered the upload dialog to add a new text field, it wouldn't automatically "work" with CK5. It might be simpler to just write a new CK5 plugin to change which attributes it accepts and add the UI directly using their conventions.

I added 2 more commits to the issue fork to get the basics of an image upload working.
These latest changes are to give an idea of how CKEditor5 could work (for image uploading) without using a Drupal dialog.
The imageToolbar lets you click an image to edit its alt text inline, and I used the SimpleUploadAdapter plugin to POST a file directly to Drupal controller.

The controller borrows heavily from Drupal\file\Plugin\rest\resource\FileUploadResource and the similar code in Drupal\jsonapi\Controller\TemporaryJsonapiFileFieldUploader but would need some more work with validation and getting configuration from a settings form. It currently does not add the correct file attributes, like data-entity-uuid.

If this seems like a good direction it could be possibly be another implementation of the service in #2940383: [META] Unify file upload logic of REST and JSON:API.

Discussed with @yoroy and he said that he feels that we should move forward with the CKEditor 5 UI pattern on image and link UIs. He said that it seems better for UX because it provides more direct manipulation compared to dialogs.

I think this is a nice opportunity to evolve towards a smoother editor ux! I assume it involves work to actually hook into these, but it seems a good idea to do so.

@zrpnr walked me through his current PoC, thinking, concerns, direction last night! 🙏I'll try to keep a closer eye on this.

@zrpnr, @lauriii and @yoroy: I agree with this direction away from using Drupal-generated-dialogs, because the authoring UX is much better. However, it does not come without a cost:

• alt attribute is not required — so potentially less accessible markup will be generated. This can be mitigated, but it'll also make the UX less smooth.
• https://www.drupal.org/project/editor_advanced_link & https://www.drupal.org/project/editor_advanced_image become impossible. That being said, alterability was not the only motivation for using Drupal-defined form/dialogs. The other motivation was to avoid the need for competing text editors to reimplement all this integration. But now that Drupal 8 has been out for >5 years, it's clear that the entire Drupal ecosystem has settled on CKEditor 4. Almost no @Editor plugins were developed besides core's \Drupal\ckeditor\Plugin\Editor\CKEditor. AFAICT most alternative implementations are for things like Markdown, for example https://www.drupal.org/project/simplemde.

I think those downsides do not outweigh the benefits.

An aside to this question is whether we should be using an inline image upload at all, now that Media is in core.

I think we should, at least until #3073901: Determine an upgrade path from CKEditor image button to media library is resolved.

An interesting intermediate could be to make inline image uploads generate a Media entity under the hood, and generate markup like

<img src="cat.jpg" data-entity-type="media" data-entity-uuid="1004afac-1c4a-4a79-b9f9-015b4892b722" alt="Magnificent cat!">

instead of

<img src="cat.jpg" data-entity-type="file" data-entity-uuid="3be19b6a-54da-4378-b93e-94bbfedc6443" alt="Magnificent cat!">

and update \Drupal\editor\Plugin\Filter\EditorFileReference to also support Media entities instead of only File entities.

That would ease the transition to Media Library in the future 🤓

I gave a brief demo of the prototype at a Drupalcon Europe BoF, and have made some updates to the issue fork since then.
Recently I've been trying to connect the editor settings to how CKEditor5 is configured.

The Drupal plugins for Image and Media Library both use editor settings to provide config and add libraries.
On the CKEditor5 side, the media plugin is part of the js build, while the Drupal Image plugin js is added separately.
I wasn't sure which approach was better so I left both examples here for discussion.
There's also some ongoing work by the CK team to make plugins more easily loaded dynamically: https://github.com/ckeditor/ckeditor5/issues/8395
I haven't experimented with this branch yet.

Whether we have the source for these plugins or even the CKEditor5 "build" itself in Drupal core is also something to decide.
There is active discussion about js libraries in core, see:
#3185289: Use package.json and rollup to manage third party JS libraries
#3178115: [policy, no patch] Maintenance of JS in core
#3176918: [policy, no patch] Publishing / Maintaining JS libraries produced by Drupal that do not have a dependency on Drupal

The allowed html filter needs to be connected somehow to CKEditor5, since the elements and attributes the editor supports shouldn't be in conflict with Drupal.
The approach I took here was to add a validation function to the settings form, similar to what the media module does to check for <drupal-media>.
All the elements provided in a CK plugin could be declared somewhere in php, such as the Drupal plugin annotation.
The validation checks that only the list of supported elements and attributes can be added.
I'm not sure this is the best way to handle it, but it seems like there shouldn't be 2 places for configuration to live.
Maybe instead it would be better to have the field pre-populated and disabled, instead of letting a user make a choice that's not allowed?

If another input format becomes standard, we could make sure the CKEditor5 build is configured to have all those elements.
see: #3097468: Deprecate the "Full HTML" text format in Standard and Umami in favor of a "content editor HTML" for content editor roles

Image upload
Images now have the data-align filter working, and it corresponds to CKEditor5 UI.

alt attribute is not required

Maybe this could be helped with form validation, scanning the text about to be saved?

https://www.drupal.org/project/editor_advanced_link & https://www.drupal.org/project/editor_advanced_image become impossible.

This is true, however there are lots of other possibilities for plugin development and extension within CKEditor5, just using javascript :)
I think like the allowed html, the config and features should come from CKEditor5 as much as possible.

An interesting intermediate could be to make inline image uploads generate a Media entity under the hood

At first I thought it might be best to leave off the image upload entirely, but the CKEditor5 UI and upload (including multiple file upload) would be a shame not to include.
This is a really creative solution, to preserve the image upload in the editor but avoid the pre-media file storage.

Media Library
The media library browser can be opened from the CKEditor5 UI, and it can insert a placeholder into the editor.
In CKEditor4 there's an ajax request to get the rendered Media entity, something similar should be possible here with either the Media Embed feature of CKEditor5 or by using a "container" RawElement.
There isn't any integration with the media embed filter yet. I wasn't sure if I should use that filter as a way to toggle off the js plugin entirely, or just use it to validate whether Drupal should render the tag.

I'd appreciate some thoughts and feedback on these questions and more, and I also would like advice on how best to continue this work.
This is the first issue where I've worked on an issue fork, and it has been much nicer DX than posting enormous patches but it also feels less visible and open to collaboration.

Gábor created a #ckeditor5 channel in Drupal slack, where we are just starting to plan for regular meetings.
Please join and share your expertise!

In CKEditor4 there's an ajax request to get the rendered Media entity, something similar should be possible here with either the Media Embed feature of CKEditor5 or by using a "container" RawElement.

@Reinmar posted some info about the RawElement in the #ckeditor5 Drupal slack channel, https://drupal.slack.com/archives/C01GWN3QYJD/p1609750533031000

That helped a lot, and I pushed up a change yesterday that displays the rendered media element from Drupal in the editor instead of the simple div placeholder I had previously.

https://git.drupalcode.org/issue/drupal-2966864/-/commit/d7c78f7131abd4f...

Updated IS to reflect that work has moved to the CKEditor 5 contrib module.

(adding a tag to help triage on my end)

Updated IS to remove roadmap, pointing instead to #3201824: Roadmap to core

A core issue to add CKEditor 5 to Drupal core is in progress at #3231364: Add CKEditor 5 module to Drupal core! :)

ckeditor5 was committed to core yesterday, is there anything else necessary for this or can it be closed too?

This is a children of #3118154: [meta] Deprecate dependencies, libraries, modules, and themes that will be removed from Drupal 10 core by 9.4.0-beta1, I think if this is closed, it needs to be replaced with an issue to make the CK5 module stable, since to my understanding that would be required to deprecate the existing CK module and thus complete the addition of CK5 for the purpose of replacing CK4. (Also other issues may be needed to do said deprecation, eg. to use CK5 for new sites in 9.4).

#3238333: Roadmap to CKEditor 5 stable in Drupal 9

Let's mark this duplicate of #3238333: Roadmap to CKEditor 5 stable in Drupal 9.