Testing the CKEditor 4 to 5 upgrade path
We need ~450,000 Drupal 8 and 9 sites to make a fully automated upgrade from CKEditor 4 to 5.
But CKEditor 4 and 5 have vastly different architectures, which has significant consequences for that upgrade path. Virtually every detail is different!
In a nutshell: CKEditor 4 leverages the browser as much as possible. Consequence: any tiny difference in behavior across browsers in low-level APIs has a huge negative impact. CKEditor 5 therefore avoids using the browser for many low-level operations, and re-implements many things. This way, it can guarantee consistency and reliability. But consequently, not all HTML is natively supported anymore!
An enormous amount of effort went into the upgrade path. But even though we developed and tested it with as many edge cases in mind as we could think of, the strongest proof is testing it on real-world sites, with actual content.
The questions we kept in mind while working on the upgrade path:
- How do we ensure that the toolbar people get to use looks as similar as possible?
- How do we ensure that all HTML that was already created in CKEditor 4 continues to work fine in CKEditor 5?
- How do we ensure the same HTML restrictions are enforced by CKEditor 5?
- How do we ensure that HTML tags/attributes/attribute values allowed by a Drupal text format match those of the corresponding CKEditor 5 text editor exactly?
- How do we communicate changes in the toolbar to the site builder?
- Does the resulting text editor experience match your expectations?
So we'd like you to test two things:
- The upgrade path for the CKEditor 4 configuration to a CKEditor 5 equivalent.
- After having done the above, testing the editing of existing content with CKEditor 5.
1. Testing the upgrade path for the CKEditor 4 configuration to a CKEditor 5 equivalent
- Install the experimental CKEditor 5 module that is included with Drupal 9.3 and newer. (Do not install the former contrib module!) Because CKEditor 5 is experimental every commit not only goes to 9.4 (and 10.0) but also 9.3!
- Go to
/admin/config/content/formats
- Find the most complex text format on your site that indicates
CKEditor
is its text editor - Click its
Configure
operation - Copy the machine name (for example:
basic_html
) - In a terminal, do
drush cget filter.format.MACHINE_NAME > MACHINE_NAME-format-before.yml drush cget editor.editor.MACHINE_NAME > MACHINE_NAME-editor-before.yml
- Return to the text format configuration page in the browser, find the
Text editor
dropdown, chooseCKEditor 5
instead ofCKEditor
. Ignore what happens for a moment, save the form and go to the next step. - In a terminal, do
drush cget filter.format.MACHINE_NAME > MACHINE_NAME-format-after.yml drush cget editor.editor.MACHINE_NAME > MACHINE_NAME-editor-after.yml
- In the browser, look at what actually happened. Write down your observations, concerns, fears, celebrations. We want to hear about it!
- Check the coordination handbook page for finding out what's happening to the additional Drupal modules you have installed that provided CKEditor 4 plugins.
2. Testing the editing of existing content with CKEditor 5.
First do step 1. Then try editing existing content. That can simply be:
- Open complex content in CKEditor 5
- Change a single letter
- Save
- Check whether the saved HTML looks like you would expect
This is especially valuable to test with the "Full HTML" text format!
Help improve this page
You can:
- Log in, click Edit, and edit this page
- Log in, click Discuss, update the Page status value, and suggest an improvement
- Log in and create a Documentation issue with your suggestion