Problem/Motivation

Since ckeditor5 was released (or even announced), we have struggled to reconcile its release cycle with Drupal core. The most recent example is #3527914: Use UMD installation method for CKEditor5, however there have been bc issues with many previous updates which in many cases have resulted in breaking contrib ckeditor plugins or other instability.

I think the biggest problem is not really inherent to core and ckeditor5's release cycles, but specifically because ckeditor is in core, so that sites have to update ckeditor when they update core, and core can only support one version of ckeditor at a time (multiplied by the number of supported branches with different ckeditor5 versions).

Also, ckeditor used to have three maintainers in core, and is now down to one, this means that ckeditor5 updates have increasingly been handled by release managers as a last resort.

For sites, when they need to update to a new minor version of core, they also have to update ckeditor, which due to lack of semver can mean that contrib modules break. Similarly, there is no way for Drupal 11 sites to run ckeditor 48 because of the switch to the umd installation method, so they will be unable to adopt new ckeditor features or bugfixes without updating to Drupal 12 - months or years after its release.

Steps to reproduce

Proposed resolution

Move ckeditor5 and all core plugins to a contributed project.

The contrib project would be able to do the following, that is impossible to do in core:

For each ckeditor major branch, the contrib project could start a new branch e.g. for ckeditor 47 and 48.

Both the 47 and 48 branches could support multiple Drupal branches, so e.g. all of 10.6, 11.3, 11.4 and 12.0

For sites, when a new core minor branch is released, they would be able to update to that minor version without updating the ckeditor module.

Conversely, when a new ckeditor version is released, sites would be able to update to it as soon as it's available in the contrib module, instead of waiting for a minor or major release of core.

For contrib ckeditor plugins, they'd be able to specify compatibility with a specific range of contrib versions, which will incorporate both Drupal and ckeditor compatibility.

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

Comments

catch created an issue. See original summary.

catch’s picture

catch
he/him
Primary language English
commented
Issue tags: +Needs subsystem maintainer review, +Needs product manager review, +Needs release manager review
markconroy’s picture

markconroy commented

@catch, just for clarity:

  • Is this issue only for removing ckeditor from core?
  • Are you proposing to add a different WYSIWYG instead?
  • If not, does that mean we will be shipping Drupal core with no WYSIWYG?
catch’s picture

catch
he/him
Primary language English
commented

@markconroy this proposal is only about moving the module to contrib. This would mean it wouldn't be included with core, but we have other issues open to slim down the standard profile such as removing the content types, so an installation of core will end up more of a blank slate than it currently is with standard (but less than with minimal which for me looks broken due to the lack of admin theme).

It would still be included with Drupal CMS, which is the default experience for new users and people who want to start sites with defaults in place.

I've personally done zero research on alternative WYSIWYG editors and have no plans to do so.

godotislate’s picture

godotislate
he/him
commented

This is +1 from me, but with two concerns:

  • If there is only one ckeditor maintainer in core, will there be requisite maintainers active enough to maintain multiple branches and keep up the release pace with CKEditor?
  • What is the LOE of decoupling core tests from CKEditor?
longwave’s picture

longwave
he/him
Primary language English
Location UK
commented

I also have a concern that we then have editor.module in core to support WYSIWYG editors, but no concrete implementation provided with core, so what happens to tests and maintenance of that module?

catch’s picture

catch
he/him
Primary language English
commented

If there is only one ckeditor maintainer in core, will there be requisite maintainers active enough to maintain multiple branches and keep up the release pace with CKEditor?

That's a good question, but if it's a problem then the impact would be on the contrib module vs. the entirety of core. Between ckeditor4-5 for 9.x-10.x and the dll deprecation for 11.x-12.x we've already had two major core release cycles impacted by ckeditor changes. We got lucky with the dll deprecation in the end due to @longwave's efforts but also it was stalled for years prior to that. I would hope that in contrib CKSource might get involved a bit more directly too.

What is the LOE of decoupling core tests from CKEditor?

Three editor tests depend on it, which is also related to @longwave's point about coverage. We might need to both copy those over to ckeditor5 and also try to replace the coverage as best we can in core.

We'd also need to move the media ckeditor5 widget and its test coverage. Apart from that not all that much though afaik.

quietone’s picture

quietone commented
Issue summary: View changes
Status: Active » Postponed

We've been discussion all the extension removals at one time. I have setup an issue for that and this is postponed on the core team completing their review, which is not yet scheduled.

mlncn’s picture

mlncn commented
Status: Postponed » Active

Respectfully moving back to active as, not seeing the issue to discuss all extension removals all together, i am not sure the value of it in a special case like CKEditor5, where removing it is definitely not about reducing Drupal's commitment to integration with CKEditor but about making it more flexible (will we finally have an officially blessed Golden Contrib with this? ;-)

Asking, selfishly for me, if it has been gamed out exactly how to do different versions— what the naming convention would be for the branches? Would it be better to have separate modules ckeditor5_47 and ckeditor5_48? Then we could get started right away, and it would be more straightforward to composer require the one you want. Not sure if that complicates moving it out of core. But for sure some sites that move to Drupal 12 will want to stay with CKEditor5 v47 for a bit (the automatic "table" class for tables moves from <table> to a surrounding <figure> in v48, just to warn everybody), while other sites want to move to CKEditor5 v48 right now without having to wait for Drupal 12's release in December.

catch’s picture

catch
he/him
Primary language English
commented

I was thinking there could be minor branches like 1.47.0 and 1.48.0 to match the ckeditor versions. Would then allow for patch releases where necessary. If the module itself needs to make a breaking change it leaves the major version open.

quietone’s picture

quietone commented
Parent issue: » #3588899: [policy, no patch] Move ckeditor to contrib
grimreaper’s picture

grimreaper
Primary language French
Location France 🇫🇷
commented

Hi,

In comment 11, this issue is referencing itself as parent issue, is it normal? Or am I misreading?

quietone’s picture

quietone commented
Parent issue: #3588899: [policy, no patch] Move ckeditor to contrib » #3609464: [policy, no patch] Extensions to possibly deprecate in Drupal 12 or Drupal 13

Thanks. Fixed that.

quietone’s picture

quietone commented
Issue tags: +Needs framework manager review
larowlan’s picture

larowlan
Location 🇦🇺🏝.au GMT+10
commented

I also have a concern that we then have editor.module in core to support WYSIWYG editors, but no concrete implementation provided with core, so what happens to tests and maintenance of that module?

I think we should consider removing editor module at the same time.

If we can get a team of maintainers for contrib, then +1 from my point of view as a framework maintainer. Leaving tag to give other FMs the change to respond too

wim leers’s picture

wim leers
Location Ghent 🇧🇪🇪🇺
commented
Related issues: +#1890502: WYSIWYG: Add CKEditor module to core, +#2099741: Protect WYSIWYG Editors from XSS Without Destroying User Data, +#3231354: [PP-2] [META] Discuss: merge the Editor config entity into the FilterFormat config entity

(Thanks @bnjmnm for pointing me here. I'm one of the former maintainers of the CKEditor 5 module.)

Overall

The contrib project would be able to do the following, that is impossible to do in core:

  • For each ckeditor major branch, the contrib project could start a new branch e.g. for ckeditor 47 and 48.
  • Both the 47 and 48 branches could support multiple Drupal branches, so e.g. all of 10.6, 11.3, 11.4 and 12.0

Makes sense!

My concern is: won't this bring back the very problem that #1890502: WYSIWYG: Add CKEditor module to core aimed to resolve? @catch already answered that in #4:

an installation of core will end up more of a blank slate than it currently is with standard

IOW: the answer is https://www.drupal.org/project/drupal_cms, which would then be shipping with the contrib CKEditor 5 module.

Who maintains the CKEditor 5 contrib module

If there is only one ckeditor maintainer in core, will there be requisite maintainers active enough to maintain multiple branches and keep up the release pace with CKEditor?

Again answered by @catch, in #7, and I agree with his position that it'd make sense for CKSource to step up to do more maintenance work — they know exactly what's coming, so they're best positioned. Plus, they would then more directly own the Drupal subset of their ecosystem, and the impact on that ecosystem from upstream decisions.

Impact on core's editor that provides the low-level integration infra

@longwave in #6:

I also have a concern that we then have editor.module in core to support WYSIWYG editors, but no concrete implementation provided with core, so what happens to tests and maintenance of that module?

I vote we merge it into the filter module. IOW: do #3231354: [PP-2] [META] Discuss: merge the Editor config entity into the FilterFormat config entity.

I'd be fine with dropping subsets of that module though: the dialog infra seems less relevant today,

Why?

  1. We don't want competing contrib modules to reinvent security-critical infrastructure like \Drupal\editor\EditorXssFilter\Standard — that was very difficult to find the right balance on, and has been protecting switches between CKEditor and every other assistive/rich text editor ever since then. IIRC that was one of the most frequent security problems pre-Drupal 8 (some text editor executing some malicious HTML blob in its preview). It took expertise of the Drupal security team and WYSIWYG/filter system expertise from @eaton back in #2099741: Protect WYSIWYG Editors from XSS Without Destroying User Data to arrive at this solution, and it has effectively not needed to change in 8.5 years. Let's keep at least this part.
  2. The editor_file_reference filter is what records file usage, and what rewrites URLs of embedded images, videos, documents … We don't want to break this.

I think both of those are fundamental for any rich text editor, and folding the editor module into filter would achieve that quite easily.