Split the core 9.5.x ckeditor history into a new 1.0.x branch and cut a 1.0.0 release

Of course: this won't work until #2 is committed 😬 Because the d.o composer facade maps the core_version_requirement to a composer constraint. Committing…

https://dispatcher.drupalci.org/job/drupal_contrib/606666/console → tests are running for the very first time! 🥳

Yay, tests ran, and mostly passed! 🥳

43 passes, 5 failures: https://www.drupal.org/pift-ci-job/2462950.

This patch should get us down to 4 failures.

The failed test output makes no sense. It strongly suggests that the core module is still enabled, instead of my contrib module overriding it, which should ALWAYS happen — it's a feature of Drupal core!

Added debug output.

Also updated CKEditorToolbarButtonTest and CKEditorUpdateOmitDisabledPluginSettings now. I'm skeptical they will work on the first try, but let's find out!

+++ b/tests/src/Kernel/CKEditorTest.php
@@ -51,6 +51,7 @@ class CKEditorTest extends KernelTestBase {
+    var_dump(\Drupal::service('extension.list.module')->get('ckeditor'));

@@ -279,6 +280,7 @@ class CKEditorTest extends KernelTestBase {
+    var_dump($expected);

WTF! Neither of these show up in the output!? 🤯

Converted #6 + #8 into a merge request, let's see how that goes.

Couldn't find any answers in https://www.drupal.org/project/quickedit's commit history either (since it is only testing against 9.5 and has not run in ~2 weeks), nor https://www.drupal.org/project/bartik (no automated tests running at all).

🤞

In hindsight, I should've split the 10.0.x history, not the 9.5.x history. It does not make sense to install this module on Drupal 9.5, because:

1. on 9.5, it's still available in Drupal core (albeit with lifecycle: deprecated)
2. on 10.0, it should be available as a contrib module, but still with lifecycle: deprecated!

So, creating a new MR to update this to mark it deprecated and limit it to ^10.

That will also address the last test failure, because #3290810: Remove updates added prior to 9.4.0 (9.4.4 for ckeditor) and add 9.4.0 database dumps (correctly!) removed the sole post-update hook and removed the test, so keeping that test coverage around in contrib is pointless too.

Actually, no, what I did is consistent with what https://www.drupal.org/project/quickedit did: quickedit was deprecated in 9.5.0, just like ckeditor.

Therefore it follows that we must have the same compatibility guarantees. git diff 9.5.x 10.0.x -- core/modules/ckeditor shows pretty significant differences which if applied would make it incompatible with Drupal 9.5.

Instead of what I wrote in #13, I just need to make the 3306630-make-tests-pass merge request execute the update test conditionally: only on 9.5, not on 10.

1. We need to match what the currently RTBC #3304326: Deprecate CKEditor 4 module in 9.5 will do: mark it deprecated. Created new merge request for that: https://git.drupalcode.org/issue/ckeditor-3306630/-/tree/3306630-depreca...
2. The core/ckeditor asset library will not exist in Drupal 10.0.0. Therefore we should move that asset library into this module. Created new merge request for that: https://git.drupalcode.org/issue/ckeditor-3306630/-/tree/3306630-ckedito...

#17:

… ugh and this means that the git subtree split I did so far for the contrib module actually is in principle … inaccurate. It does not include the core/assets/vendor/ckeditor stuff. But then again, I don’t see how it realistically could, since it’d also entail moving files and retaining parts of the contents of the commit history 🤔 (All of core/assets/vendor/ckeditor, but only a subset of core/core.libraries.yml.)

So … would not having that history be acceptable? Would just be doing https://git.drupalcode.org/issue/ckeditor-3306630/-/tree/3306630-ckedito... in its current form be acceptable?

P.S.: also, should we provide a core/ckeditor asset library just for BC purposes? Although I cannot seem to find a single example of a module declaring an asset library on behalf of another extension 😅

RE: subtree split in #20: confirmation from @xjm and @lauriii that retaining the full vendor history is unnecessary, so https://git.drupalcode.org/issue/ckeditor-3306630/-/tree/3306630-ckedito... is fine as-is! 🚢

I cannot merge https://git.drupalcode.org/issue/ckeditor-3306630/-/tree/3306630-ckedito... in good conscience until #3306909: Get Drupal Security Team approval to commit vendor/ckeditor.js to the drupal/ckeditor project is answered/clarified.

I'm 99% certain the test failures are due to #3306545: Replace ckeditor with ckeditor5 in the 9.4.x database dumps in Drupal 10.0.x & 10.1.x. Investigating.

The 3306630-after-3306545-ckeditor4-is-no-longer-installed MR made tests green again in HEAD. Merging that, and then re-testing the 3306630-ckeditor-asset-library MR.

Ugh, that merge request's commit has the brain-dead default title. 😬 The GitLab UI failed numerous times, so I didn't catch it this time. What a nightmare UX. 🤯 Why it is not smart enough to prompt me for a commit message if this is the n>1th merge request on the same issue fork is beyond me …

All done. Keeping marked [PP-1] to indicate that #3306909: Get Drupal Security Team approval to commit vendor/ckeditor.js to the drupal/ckeditor project is needed prior to tagging 1.0.0. But went ahead and tagged 1.0.0-rc1 so we can proceed in #3270438: Remove CKEditor 4 from core and #3306563: [Meta] Tasks to remove CKEditor (4) from core and move to contrib.

https://www.drupal.org/project/ckeditor/releases/1.0.0-rc1 is live 🚀

#3306909: Get Drupal Security Team approval to commit vendor/ckeditor.js to the drupal/ckeditor project was marked fixed 👍

https://www.drupal.org/project/ckeditor/releases/1.0.0 is out! 🚢