Add CKEditor 5 module to Drupal core

This represents months and months of work by many wonderful people in https://www.drupal.org/project/ckeditor5! 😊😊

It also is in no small part thanks to the wonderful people at https://ckeditor.com/ — without whom this would not be possible. Special thanks to @Reinmar for always making time for us!

(FYI: the generating of this patch is automated — see #3227826: Preparation for moving CKEditor 5 to core.)

Clearly it'd have been wiser to first open a test-only issue to first get the patch green. But we've been developing with Drupal core's core/scripts/dev/commit-code-check.sh running for us (patched, of course, since it only works for Drupal core). That made us think it'd work on the first try. Clearly not 🙈😅

This fixes the cspell violations, and a bunch of other test failures that we found by temporarily disabling the core commit checks. We still expect this to fail, because this introduces one big change: instead of keeping the CKEditor 5 build in core/modules/ckeditor5/js/…, we move it to core/assets/vendor/… — which exempts it from many checks. Let's see if I got that right 🤞 (That also explains the huge interdiff.)

Built using #3227826-24: Preparation for moving CKEditor 5 to core, using CKEditor 5 module commit 8a8c4580417427d7644f66e218a0e7cc677f4cdd. (The patch in #2 was using commit f4906174b1d0fdd394a1648b35179c19019834a4.)

Two *.es6.js complaints remained. Fixed.

Built using #3227826-26: Preparation for moving CKEditor 5 to core, still using commit 8a8c4580417427d7644f66e218a0e7cc677f4cdd .

Indeed, not yet happy. Because I confused eslint compliance with ES6ification compliance.

Built using #3227826-28: Preparation for moving CKEditor 5 to core, still using commit 8a8c4580417427d7644f66e218a0e7cc677f4cdd .

This should fix most failures!

Built using #3227826-36: Preparation for moving CKEditor 5 to core, using commit 545040f7d1fe9eff138e2daa2dc1f5edb2aa8cab. Upstream commit history since the previous build:

* 545040f7d1fe9eff138e2daa2dc1f5edb2aa8cab Issue #3231550 by Wim Leers: Follow-up for #3205654: make hook_help() comply with the format expected by Drupal core
* ca63aa841f0714ba5fad2c2de7e24863ff3a9618 Issue #3231402 by Wim Leers: Work around ConfigImportAllTest somehow calling config schema alter hooks before config schema is imported
* 14c4ca67e32221278eb6ebc46d209b6739acf2cc Issue #3231427 by lauriii, johnwebdev: Changing basic HTML format to CKEditor 5 results in CKEditorError: plugincollection-plugin-not-found {"plugin":null} on fresh install

→ adding credit for @johnwebdev :)

This should fix the remaining failures.

Built using #3227826-39: Preparation for moving CKEditor 5 to core (thanks @lauriii!), using commit 411c7358a3404d11ff1e2f0c1a638f43b37f072a. Upstream commit history since the previous build:

* 411c7358a3404d11ff1e2f0c1a638f43b37f072a Issue #3231718 by Wim Leers: Make ckeditor5_dev_hook_help() comply with the format expected by Drupal core

The 2.32 MB patch size might scare people away. ~75% of that is for the core/assets and core/yarn.lock changes. I think moving that part into a separate issue may be helpful — but I'll first await some initial reviews before doing that :)

#30: Thanks! :)

#31: On it.

#29: release manager @xjm indicated that it'd be better to hold off on that for now because it otherwise may need to be removed if the CKEditor 5 module is still alpha-level stability at the time when 9.3.0-rc1 gets tagged. So, holding off on creating that separate issue.

We will instead from now post multiple patches: ckeditor5-CID.patch (includes everything) ckeditor5_assets_only-CID-do-not-commit.patch (assets only) and ckeditor5_module_only-CID-do-not-commit.patch.

#34: Wow, thanks for creating that! Added comment with relevant information from the CKEditor 5 team from the meeting earlier today: #3232052-2: Drupal 10 & CKEditor 5 readiness.

#31: See #34 and the above update for it, plus #3232190: CKEditor 5 readiness for LinkIt. In short: they're aware of this need, but so far they've managed to not have to support it. There are significant implications for focus state/accessibility, real-time collaboration conflict handling, et cetera. @lauriii and I discussed various potential approach with @Reinmar. He'll provide us with an update in ~2 weeks (September 23, 2021).
TL;DR: we're blocked on news from upstream to really make progress on this front. They understand how important this is to Drupal, and are prioritizing getting these aspects unblocked.

Related: we opened #3231341: Deprecate EditorLinkDialog, EditorImageDialog and EditorMediaDialog in Drupal 10.1 for removal in Drupal 11 a while ago for this.

#37: the CKEditor-specific toolbar you mentioned: I think you installed the CKEditor 5 developer tools 🤓

#37–#40: Fixed in #3232409: Media Embed button is broken. (I agree with the aside in #40 ;))

#41–#43: @lauriii reproduced this and confirmed this is an upstream CKEditor 5 bug, for which he filed an issue too: https://github.com/ckeditor/ckeditor5/issues/10539 👍 The CKEditor 5 team is really grateful for our bug reports 😊

#44 + #45 + #47: Fixed in #3236648: The "Limit allowed HTML tags and correct faulty HTML" option under "Enabled filters" was never checked still shows the filter settings for it.

#46: to add to what @lauriii already wrote in #48: we can absolutely change this in the future. But there already are some huge hurdles that we have to overcome here. 😅 Innovating on Drupal's JS package handling isn't one that we should put in the critical path. 🙏

Built using #3227826-42: Preparation for moving CKEditor 5 to core using commit 686cce684c3edc7874db11ece8149a8bcf702b3a. Upstream commit history since the previous build:

* 686cce684c3edc7874db11ece8149a8bcf702b3a Issue #3236648 by Wim Leers, yash.rode, Luke.Leber: The "Limit allowed HTML tags and correct faulty HTML" option under "Enabled filters" was never checked still shows the filter settings for it
* def76f5ad12fcab6ac1acf63cd0848fba3c0cd34 Issue #3227875 by yash.rode, lauriii, Wim Leers: update mapping of CKEditor 4 to 5 toolbar items to support ckeditor5-remove-format
* 54a659b752892f2358dbb6c3c246698e34787120 Issue #3227890 by yash.rode, Wim Leers, lauriii: Add ckeditor5-special-characters to allow inserting special characters for users that do not know the native picker
* 9709e8c213e2f2908b48b257f440d8d0fa1cb03b Issue #3232409 by yash.rode, Wim Leers, webchick: Media Embed button is broken
* 670d8bb7032be81eb32bdf35affb7be217df8daa Issue #3227875 by yash.rode, Wim Leers, lauriii: Add ckeditor5-remove-format to allow removing formatting from pasted content

New since last time: #3227890: Add ckeditor5-special-characters to allow inserting special characters for users that do not know the native picker + #3227875: Add ckeditor5-remove-format to allow removing formatting from pasted content. These bring us closer to complete feature parity. Only a few issues remain. Which reminds me: we have not yet moved the roadmap issue into Drupal core. Did that just now: #3238333: Roadmap to CKEditor 5 stable in Drupal 9.

The biggest concern I have is how robust the upgrade path will be on real sites - but again a core experimental module is the way to flush out problems there.

💯

This is why I focused my time on that very question since I started working on this in earnest ~3 months ago! 😊

It's why we use config validation constraints to help guarantee correct configuration, and why we have the concept of "smart default settings" (see \Drupal\ckeditor5\SmartDefaultSettings).

It's why we (in particular @bnjmnm!) spent a lot of time on making the UX of using the UI to switch from CKEditor 4 to CKEditor 5 over at /admin/config/content/formats/manage/* solid and informative, so that people testing it now (before the upgrade to Drupal 10) are informed in detail of the what and why. We can choose how (or even if) to expose those messages to the end user when it happens automatically when upgrading from 9 to 10.

It's why we have \Drupal\Tests\ckeditor5\Kernel\SmartDefaultSettingsTest in particular: it provides 6 different testing scenarios (3 that cover Drupal 8's default text formats without changes: basic_html + restricted_html + full_html, plus two with high-impact changes to basic_html and finally one that tests a text format that uses only filter_html with its default settings). If I were you, I'd focus my attention (or at least start with) scrutinizing that test. If you have a suspicion that edge cases X or Y are not handled, it's going to be trivial for us to expand test coverage there.

For upgrade path robustness, what remains to be done there is:

1. #3226335: Follow-up for #3216015: allow contrib & custom Drupal modules providing CKEditor 4 plugins to specify their CKEditor 5 equivalents + settings to be migrated, because currently only core's CKEditor 4 buttons + settings can be migrated (see \Drupal\ckeditor5\SmartDefaultSettings::mapCKEditor4ToolbarButtonToCKEditor5ToolbarItem() + \Drupal\ckeditor5\SmartDefaultSettings::createSettingsFromCKEditor4()). We of course want contrib modules (which provide additional CKEditor 4 plugins, buttons and settings) to be able to specify an upgrade path as well.
2. #3226694: Follow-up for #3216015: refactor SmartDefaultSettings to return messages rather than sending them

@catch: Clearly #50 is from the release manager POV, what would you write from the framework manager POV? 🤓

what happens when a site tries to update, but a plugin it uses hasn't implemented an upgrade path?

Any buttons for which no upgrade path is defined will be dropped.

Any plugin settings for which no upgrade path is defined will be dropped.

Most importantly: 100% of the stored HTML will still be editable after the migration, thanks to the Source Editing plugin getting enabled when needed.

What happens if the plugin later adds an upgrade path and you enable it, will the old markup get upgraded on the fly, or is it stuck in edit source?

Not sure I follow. So I'll just explain the different aspects:

1. At absolutely no time ever do we need to "upgrade the old markup". We do not change the markup, ever. The old markup remains the same before and after the CKEditor 5 plugin gets used. It's just edited through a nicer UX instead of by manually editing the source.
2. If the plugin adds an upgrade path later, meaning after you've already upgraded to CKEditor 5, we will not re-run the upgrade path — the user might've already customized it since then.
3. The user can manually add this plugin/toolbar item though, when it becomes available.
   
   

   In fact, when it becomes available, they'll be notified explicitly: they'll get the SourceEditingRedundantTagsConstraint::$availablePluginsMessage validation error which says: The following tag(s) are already supported by available plugins and should not be added to the Source Editing "Manually editable HTML tags" field. Instead, enable the following plugins to support these tags: %overlapping_tags..

   If they then actually add this newly available toolbar item, they'll get the SourceEditingRedundantTagsConstraint::$enabledPluginsMessage validation error which says: The following tag(s) are already supported by enabled plugins and should not be added to the Source Editing "Manually editable HTML tags" field: %overlapping_tags..

   (Both scenarios have test coverage in ValidatorsTest — see the INVALID Source Editable tag already provided by plugin and another available in a not enabled plugin test case.)

Let's apply this to a concrete example: imagine there's a marquee button to add <marquee> markup in Drupal 9, and you've got filter_html configured to only allow <p> <br> <strong> <marquee>. No upgrade path is defined for it at the time the site upgrades from Drupal 9 to 10. This means that a Editor config entity with these settings will be generated during the upgrade:

      'settings' => [
        'toolbar' => [
          'items' => [
            'bold',
            'sourceEditing',
          ],
        ],
        'plugins' => [
          'ckeditor5_sourceEditing' => [
            'allowed_tags' => [
              '<marquee>',
            ],
          ],
        ],
      ],

(<p> <br> are supported by CKEditor 5 core — you cannot disable them. <strong> is supported by bold. <marquee> is supported by nothing, which is why we're explicitly adding it to the list of Manually editable tags that the sourceEditing plugin allows you to configure. If you put all of that together, you can see that CKEditor 5 can generate and edit exactly the set of HTML tags that the text format's HTML restrictions allow 👍)

Then, once a marquee button becomes available that supports that tag, you'd first get that first message when interacting with your text format/editor in the UI. To fix it, you'd add the marquee button:

      'settings' => [
        'toolbar' => [
          'items' => [
            'bold',
            'sourceEditing',
            'marquee',
          ],
        ],
        'plugins' => [
          'ckeditor5_sourceEditing' => [
            'allowed_tags' => [
              '<marquee>',
            ],
          ],
        ],
      ],

(This is the state immediately after dragging that toolbar item into the "active toolbar" in the UI.) You still won't be able to save it though. You'll get that second message now! You'll have to manually remove that tag, which means you're now in this state:

      'settings' => [
        'toolbar' => [
          'items' => [
            'bold',
            'sourceEditing',
            'marquee',
          ],
        ],
        'plugins' => [
          'ckeditor5_sourceEditing' => [
            'allowed_tags' => [],
          ],
        ],
      ],

Now you will be able to save the text editor. You can choose to remove the sourceEditing button, or you can keep it to edit your other markup — there are just no additional allowed tags specified.

In other words: the module does nudge you towards doing the right thing: it nudges you towards using plugins instead of Manually editable HTML tags — because the user experience is way worse there.

@lauriii and I met with @Reinmar from the CKEditor 5 team yesterday. Meeting notes available.

Outcomes:

1. editor_advanced_link and linkit portability were our top concerns. The challenge here is that we'd love for those two modules to not need a clunky Drupal form/dialog anymore. It's clunky (form-based UI instead of the elegant and less in-your-face balloon UI of CKE5 and slow (requires a round trip to the server). But … that's the ideal. If need be, there's no reason we can't fall back to that for those scenarios.

   So here are the next steps:

   1. @laurii will pair with CKE5's Oleq early next week to investigate how to override the link actions view: autocomplete (for LinkIt)+ button to trigger dialog (for Editor Advanced Link). If that fails:
   2. Allow Drupal modules to signal they want to use EditorLinkDialog instead of CKE5’s link.
   3. Drupal to override the CKE5 Link plugin to not trigger the CKE5-native balloon link UI and instead trigger Drupal’s EditorLinkDialog when that signal is present. Pointers:
      https://github.com/ckeditor/ckeditor5/blob/ab03609f2c599ed4aa9ee758d1e14...
      + https://github.com/ckeditor/ckeditor5/blob/ab03609f2c599ed4aa9ee758d1e14...
   4. IN THE FUTURE use a better CKE5-integrated UX, potentially using new APIs in CKE5. (It's very complicated to make their existing, super compact linking UI extensible while retaining good accessibility and usability, not to mention API supportability.)

   (BTW, I provided a patch for what is implementable today: #3232052-5: Drupal 10 & CKEditor 5 readiness. But the above is necessary to port 100% of their functionality.)

2. Work has begun on <ol start> support! 🥳
3. The CKE5 port of the CKE4 StylesCombo plugin will start after this! 🥳
4. They're prioritizing the major bugs we found: https://github.com/ckeditor/ckeditor5/issues/10505 + https://github.com/ckeditor/ckeditor5/issues/10539.

Aaand … everything I wrote in #51 wrt upgrade path has been completed in https://www.drupal.org/project/ckeditor5! :)

Built using #3227826-44: Preparation for moving CKEditor 5 to core using commit bf5df30c36153131e56b2ca11c1148007645aa92 against 9da1866da41f0bfcdb90e1f8901ce8919549f189 in 9.3.x. Upstream commit history since the previous build:

* bf5df30c36153131e56b2ca11c1148007645aa92 Issue #3228920 by yash.rode, Wim Leers: Improve internal consistency: consistent variable names and return type syntax
* a645cc086e0c3dd95ab670ef78418ab19fda5527 Issue #3226335 by Wim Leers, lauriii: Follow-up for #3216015: allow contrib & custom Drupal modules providing CKEditor 4 plugins to specify their CKEditor 5 equivalents + settings to be migrated
* 40dd5a9f57c59292a672cb856983c229058a1bda Issue #3231327 by Wim Leers, lauriii: Plugin definition DX: validate ckeditor5.drupal.elements items
* 68f2d9ebb126899f84f6011d92d024055e38d938 Issue #3226694 by Wim Leers, bnjmnm: Follow-up for #3216015: refactor SmartDefaultSettings to return messages rather than sending them
* 58bc66be9ec24462f4bc1c7d27026e2ac5f5846a Issue #3229433 by bnjmnm, Wim Leers, lauriii, nod_, tim.plunkett: Post-devue js directory refactoring
* c8bcd03b1c0b21d1ed8d6ebd53caeb99fa95d24e Issue #3231325 by Wim Leers, lauriii, yash.rode: Use pre-existing filter format config from YAML instead of duplicating it in PHP
* 459961596f38b49c9ed314c56a1709d6291e56f7 Issue #3239376 by Wim Leers: [unbreak tests] SA-CORE-2021-009 broke tests
* f91e0e68264b80948ca48645cb62e53a4d906154 Issue #3227871 by yash.rode, Wim Leers: Add ckeditor5-paste-from-office to allow pasting from Microsoft Office & Google Docs
* c66c65ceea0d9b37ef7d69a6893951f5a15cbdaf Issue #3201186 by Wim Leers: Create ckeditor5.api.php (the core equivalent of README.md) + CKEditor5PluginDefinition::toArray()

New and notable since last time: upgrade path (as mentioned before), #3227871: Add ckeditor5-paste-from-office to allow pasting from Microsoft Office & Google Docs (again closer to complete feature parity!), ckeditor5.api.php, improved DX.

It's been very quiet here. But we've not been idle.

We've been pushing forward the CKEditor 5 module itself, fixing more edge cases, adding more tests, and so on. Mid next-week, there will be a new CKEditor 5 release. Once that's out, we'll be able to address a few things we've been unable to address.

But at least equally crucially, we've been pushing forward the two most popular CKEditor 4-integrating contrib modules: https://www.drupal.org/project/linkit and https://www.drupal.org/project/editor_advanced_link.

Editor Advanced Link

We've been working with the CKEditor 5 team to figure out a way to bring the Editor Advanced Link experience to CKEditor 5 without having to sacrifice the superior CKEditor 5 linking experience (which does not rely on a Drupal-rendered dialog, which is very prone to network latency).

@lauriii collaborated with https://github.com/oleq to get that to work:

And then I worked on the automatic upgrade path, which was just completed:

Linkit

This is using https://www.drupal.org/project/a11y_autocomplete (which will soon replace jQuery UI Autocomplete in Drupal core — see #3076171: Provide a new library to replace jQuery UI autocomplete). That's right; we're reusing Drupal JS components in our CKEditor 5 integration, and it required zero hacks. 🤩 However, the Linkit module's use of jQuery UI autocomplete was actually pretty advanced … so advanced that it was doing things https://www.drupal.org/project/a11y_autocomplete could not yet do. That's why @lauriii, @bnjmnm and @nod_ have been collaborating for the past few weeks on this, and it's actually been a great way to validate the work in a11y_autocomplete: this is a prominent, high-profile use case, and they've been expanding API support in several ways to enable the LinkIt use case!

In particular, Linkit needs grouping and richer results, which you can see in this screenshot from its project page:

Cheer them on in #3245114: Allow grouping search results, #3243749: normalizeSuggestionItems() handles additional properties inconsistently and other issues in that project. This is an unexpectedly nice coincidence where we're validating one thing by working on another! 🥳

Since #60, we now also have a fully operational linkit module with CKEditor 5: both UX and upgrade path. See #3232190-12: CKEditor 5 readiness and later. It looks like this:

Built using #3227826-50: Preparation for moving CKEditor 5 to core using commit 8031f5b7198cfc6b7ca30b4451934b48bb890e32 against 9da1866da41f0bfcdb90e1f8901ce8919549f189 in 9.3.x. Upstream commit history since the previous build:

* 8031f5b7198cfc6b7ca30b4451934b48bb890e32 Issue #3206522 by Wim Leers, yash.rode, effulgentsia: Add FunctionalJavascript test coverage for media library
* 2073a9468d7220f5d2d0b7b4368cc3fcdb9f43c9 Issue #3245942 by lauriii, Wim Leers: Update CKEditor 5 to 31.0.0
* a0a865ebfa813350231bc7898b432794c174bfd7 Issue #3228505 by Wim Leers, lauriii: Plugin definition DX: automatically check for plugin definitions whether their ::getDefaultSettings() matches the config schema
* bc5ca00c8b5698fae2ac81bb417224b81e6e39b2 Issue #3245320 by Wim Leers, lauriii: Automatic upgrade path always disables image uploads — in the UI
* bcbe107fbd8e8c45f1eb24dc846f8d885095bcf7 Issue #3231362 by Wim Leers, lauriii: Refactor ImageUpload's ::validateImageUploadSettings() into the proper validate and submit methods
* ade0c4dff5c5f60c18aad51da3b32818e4514006 Issue #3231289 by Wim Leers, lauriii: Follow-up for #3230447: since optimizing admin UI, messages can accumulate
* 21a2680ce4a7ae5593f9e68c99e9b8a950770adc Issue #3245723 by Wim Leers, lauriii: Follow-up for #3201637: omitting PrimitiveTypeConstraint violations for filter settings is implemented too broadly
* 2443628abebf3e671afca90890f07f9d5a1d46bc Issue #3245807 by Wim Leers, lauriii: DX: allow contrib modules to subclass \Drupal\Tests\ckeditor5\Kernel\ValidatorsTest
* 231adf93d22dfc82b196990498b2b24943056f5f Issue #3245735 by Wim Leers, lauriii: Follow-up for #3222852: validation errors are not associated with the correct form element
* 25c1719eb147fff4fbd3eb78285ec7f6d46ef8d3 Issue #3245772 by Wim Leers: Update CKEditor5AllowedTagsTest following the commit of #2763075 into Drupal 9.3
* 4b9b4955674cda948d4a43c96eacec629dcf5a5c Issue #3245390 by Wim Leers, effulgentsia: CKEditor5::validatePair() and CKEditor5PluginManager::getPluginConfiguration() throw inconsistent exception types
* cacfb842bad00cf688c92e160233e27945f39aa1 Issue #3245387 by Wim Leers, effulgentsia: CKEditor5 has an empty settingsForm() method that neither inherits from nor is called by anything
* c4e005cea07ac3998f343f872f26261b27544be8 Issue #3245079 by Wim Leers, lauriii: Automatic upgrade path always enables all <h*> tags when only >=1 was enabled before
* 5c4433a14fd3b003cbf5e2fb726145f96fb192ec Issue #3244911 by Wim Leers, lauriii: Automatic upgrade path failing when CKEditor 4 has the StylesCombo plugin configured
* 835b8fba6451ebfea9ef429e421967483718911f Issue #3231327 by Wim Leers, lauriii: Plugin definition DX: validate ckeditor5.drupal.elements items
* c4dd59351cc9b5d4b94452b5f3f25d6334540aff Issue #3243850 by Wim Leers, effulgentsia: hook_ckeditor5_plugin_info_alter()'s example sets ['drupal']['config'], but that's not one of the documented definition properties

New and notable since last time: hardened upgrade path (and also now proven further thanks to working upgrade paths for linkit and editor_advanced_link), functional JS test coverage for media/media library (#3206522: Add FunctionalJavascript test coverage for media library), improved DX, and we're on CKEditor 5 https://github.com/ckeditor/ckeditor5/releases/tag/v31.0.0 now 😊

Thanks, @effulgentsia for filing a whole bunch of issues in https://www.drupal.org/project/ckeditor5, we've addressed some but not yet all.

#3226052: Update to cspell 5 was committed while I was creating #67 🥸

Built using #3227826-51: Preparation for moving CKEditor 5 to core using commit 8031f5b7198cfc6b7ca30b4451934b48bb890e32 against 3eba4b3c583e94b3e2306ca0c141251e0939d7b1 in 9.3.x. No upstream commits.

#68 applied cleanly, but failed on cspell (not surprising since it just was changed), but also on a bunch of phpcs violations, which is surprising, because https://www.drupal.org/project/ckeditor5 is explicitly using core's commit-code-check.sh 🤔Also, #2909370: Fix 'Drupal.Commenting.VariableComment.IncorrectVarType' coding standard just landed, which causes new phpcs violations.

I cannot reproduce those failures: #3233107-3: [ignore, testing issue] Fake bug report 😬 So instead I worked on a PoC fix, tested it in a helper issue, and am now confident it will be green here too.

Built using #3227826-51: Preparation for moving CKEditor 5 to core using commit a587204ef3678612991237bf5a5dc8b5e6cf7a6c against 3eba4b3c583e94b3e2306ca0c141251e0939d7b1 in 9.3.x. Upstream commit history since the previous build:

* a587204ef3678612991237bf5a5dc8b5e6cf7a6c Issue #3246448 by Wim Leers: Fix cspell & phpcs failures caused by both becoming more strict

Highlights since #69:

• #3247246: Attribute value encoding not compatible with Xss::filter() introduce a new JS dev dependency: jsdom. We'll need to do a library evaluation for that. That issue was a blocker to a long-known data loss issue: #3222808: Follow-up for #3201646: markup in image captions is lost.
• We finished #3206522: Add FunctionalJavascript test coverage for media library in #67, but that uncovered a few data loss critical bugs… 😱 we've been working hard to fix those: #3246168: Images are not linkable through UI; already linked images are unlinked (data loss!) is fixed, #3246169: Embedded media are not linkable through UI; already linked embedded media are unlinked (data loss!) is still in progress. That also uncovered an upstream bug: #3247634: [upstream] [drupalImage] Unlinking linked inline images while GHS is enabled: wrapping <a> is impossible to remove.
• #3244855: Regression in Drupal 9.3.x due to jQuery.once deprecation landed in core recently, and revealed a subtle bug in CKEditor 5 👍
• Meanwhile, @effulgentsia has opened about a dozen issues in the past few weeks with his findings as a backend framework manager, we've been working to address those as well.
• In meeting with the CKEditor 5 team yesterday, we learned that we could simplify our build process, and so @lauriii did just that in record time: #3247711: Simplify and accelerate builds: update our use of the CKEditor 5 DLL manifest. This explains the significant changes in core/package.json — all for the better! 😊
• In that same meeting, we also learned that they're actively working on <ol start> support, are discussing the CKE5 successor to CKE4's StylesCombo, and are looking into providing official CKE 4 → 5 plugin mapping recommendation docs (essential for getting Drupal contrib modules ported) 👍
• The #3229174: Making changes directly in the source view drops the made changes on save data loss critical that @webchick re-discovered in #64 was in fact fixed upstream, but obscured by an extremely tricky bug on the Drupal side!

I believe the following issues should still block commit, and 2/3 are very close; all should land early next week:

1. #3246524: Make more (all?) classes @internal
2. #3246169: Embedded media are not linkable through UI; already linked embedded media are unlinked (data loss!)
3. #3246280: Defense in depth: add anti-CSRF token to this module's routes

Built using #3227826-58: Preparation for moving CKEditor 5 to core using commit 07dbfdc24c0cf332c40a7d379d5d7f816324e723 against 707121c9cc46266be7d922b5ff096f07cb9461ee in 9.3.x. Upstream commit history since the previous build:

* 07dbfdc24c0cf332c40a7d379d5d7f816324e723 Issue #3222808 by lauriii, Wim Leers, longwave, effulgentsia, Reinmar: Follow-up for #3201646: markup in image captions is lost
* 78888b4b378b914e7906c263e551cd2c40ef924d Issue #3229174 by lauriii, Wim Leers, rkoller, tim.plunkett, webchick: Making changes directly in the source view drops the made changes on save
* 53a6bbe4dbf66a793bb00258bb836944ae81757f Issue #3247246 by lauriii, Wim Leers: Attribute value encoding not compatible with Xss::filter()
* 55cb04ce3119c1ac7abdb4e307ad75794c97f8cb Issue #3246168 by Wim Leers, bnjmnm, yash.rode, lauriii: Images are not linkable through UI; already linked images are unlinked (data loss!)
* b9c6084974ed14a075e7cdc9c597eac00ca60b72 Issue #3247711 by lauriii, bnjmnm, Wim Leers: Simplify and accelerate builds: update our use of the CKEditor 5 DLL manifest
* 7f5bc51e9bdad2ec89d5099934a687fa07aae723 Issue #3246955 by lauriii: Harden drupal-media by namespacing model attributes
* f6be9296f365fe1e177fb7c5c3387dc3cbecde48 Issue #3246521 by Wim Leers, yash.rode, effulgentsia, lauriii: Make plugin.manager.ckeditor4to5upgrade.plugin a private service
* 7c8c0002cf01779957f7efbc45131ea927225280 Issue #3246647 by bnjmnm, lauriii: Filter settings are not removed when a filter is disabled

After hours of prep work to make sure the core patch is green on the first attempt I of course forget the interdiff 😅

Since #71, #3246524: Make more (all?) classes @internal and #3246280: Defense in depth: add anti-CSRF token to this module's routes have landed.

#3246169: Embedded media are not linkable through UI; already linked embedded media are unlinked (data loss!) is 95% ready, will be finished tomorrow.

Built using #3227826-65: Preparation for moving CKEditor 5 to core using commit 3ca84023f364eb773b723fa075f9be30f79e837f against d63941bc1af2e1a31debad1f202e46351eaa149d in 9.3.x. Upstream commit history since the previous build:

* 3ca84023f364eb773b723fa075f9be30f79e837f Issue #3245400 by yash.rode, Wim Leers, lauriii, effulgentsia: Add an @throws PHPDoc everywhere exceptions are thrown
* d623f091e664119f1db53303d07d78c9584b424c Issue #3246280 by Wim Leers, effulgentsia, yash.rode, lauriii: Defense in depth: add anti-CSRF token to this module's routes
* cbbae5df2f044a7303d784552f17eb3b32f0677c Issue #3246524 by Wim Leers, lauriii, effulgentsia, tim.plunkett: Make more (all?) classes @internal

#3246169: Embedded media are not linkable through UI; already linked embedded media are unlinked (data loss!) landed this morning.

#75.2 and .3 are already fixed. I'll need help to address #75.1 — but I 100% agree with that!

Built using #3227826-67: Preparation for moving CKEditor 5 to core using commit 7e3cf3bacce08f39c3c69b1081cefc2a9a15cf8b against d63941bc1af2e1a31debad1f202e46351eaa149d in 9.3.x. Upstream commit history since the previous build:

* 7e3cf3bacce08f39c3c69b1081cefc2a9a15cf8b Make ckeditor 5 asset library license link point to the currently used tag.
* 28ffe11a66060e54e1f44e4ba78677c9cae3238d Issue #3248443 by lauriii: Mark drupalMedia utils as internal
* c4b6d451672d7fde5b95698b0701409cfa237745 Issue #3243867 by Wim Leers, effulgentsia, lauriii: ckeditor5_module_implements_alter() looks like it has incorrect logic
* b3bca6c17de8c15205f7fb312da0afa13667c4c4 Issue #3246169 by Wim Leers, bnjmnm, lauriii: Embedded media are not linkable through UI; already linked embedded media are unlinked (data loss!)

Built using #3227826-67: Preparation for moving CKEditor 5 to core using commit 48d0ae0dc22ff864e2c5b057d9be5646254460d0 against d63941bc1af2e1a31debad1f202e46351eaa149d in 9.3.x. Upstream commit history since the previous build:

* 48d0ae0dc22ff864e2c5b057d9be5646254460d0 cspell:ignore downcasted

I once more really wish core/scripts/dev/code-commit-check.sh were available for contrib projects 🥲No idea why our monkeypatched variant of it did not catch this 🤷‍♂️

Green! Now just to address #75.1 (requires new patch) and .4 (requires addition to issue summary).

FYI: a few hours before #75, I updated #3238333 thoroughly for everything that happened in the past ~40 days, see #3238333-7: Roadmap to CKEditor 5 stable in Drupal 9. @lauriii as part of #75 added all additional issues he identified as FEFM: #3238333-8: Roadmap to CKEditor 5 stable in Drupal 9.

And now #3248522: Move custom CKE5 plugins outside of core/assets/vendor is done! 🥳

Built using #3227826-73: Preparation for moving CKEditor 5 to core using commit fbacec8247208f39472d3d8544c540676404dfe5 against bd80b71a6f0539a792b1f925b59d607564706fd1 in 9.3.x. Upstream commit history since the previous build:

* fbacec8247208f39472d3d8544c540676404dfe5 Revert part of #3248522: the changes in `css` that converted double quotes to single quotes.
* b2dfb1c35102cddebee8c6415d71d453474c2ac3 cspell: fix typo
* b3050c8cd622cc6775db68c46d9810a9660bd56d Issue #3248522 by lauriii, Wim Leers, bnjmnm: Move custom CKE5 plugins outside of core/assets/vendor
* 8466bb067212e3374cad037224c51df5baeef4cf Issue #3248662 by Wim Leers, lauriii: Move drupalHtmlEngine from ckeditor5.internal
* 2bb9e33411221c239d0c621d08199c2c1e063e70 Issue #3248615 by Wim Leers, lauriii: Remove dependency on zrpnr/ckeditor5-drupal-layercake

P.S.: we promise the interdiff is only scary because we moved things around 😇

@lauriii just published a change record (basically matching the https://www.drupal.org/project/ckeditor5 project page, which was indeed written as a change record for an experimental module): https://www.drupal.org/node/3249061.

We will expand that change record with guidance on how to port modules providing CKEditor 4 plugins (most can be found at https://www.drupal.org/project/ckeditor/ecosystem and https://www.drupal.org/node/2735151).
That is impossible to provide right now because:

• CKEditor 4 has a centralized place for plugins: https://ckeditor.com/cke4/addons/plugins/all — much like d.o for Drupal modules
• No such place exists for CKEditor 5. They're generally just somewhere on npm.
• Most importantly: there are no official docs, no official recommendations on how to find 1:1 ports or equivalents or recommended successors in CKEditor 5 for CKEditor 4 plugins. The CKEditor team is working on this upstream. 👍

Can we get a ckeditor5.module component in the Drupal core project, so we can move over all open issues from https://www.drupal.org/project/issues/ckeditor5?categories=All into it? 🙏😊

(Or would we prefer to move 100% of issues over? 🤔 I do not have a strong opinion. I think it's probably best to move only over the remaining open ones; the rest predate the commit history in Drupal core anyway.)

… starting with this one then 😊