Problem/Motivation
By working on #3216015: Generate CKEditor 5 configuration based on pre-existing text format configuration for CKEditor 5, we noticed a lot of hoops to jump through.
When switching from CKEditor 4 to CKEditor 5, or just when enabling CKEditor 5, we should give the user (the site builder) a sensible result when they see CKEditor 5:
- When switching from CKEditor 4 to CKEditor 5, they should have an identical toolbar layout if at all possible
- When enabling CKEditor 5 for a text format that did not yet have a text editor configured, it should not just enable a CKEditor 5 toolbar configuration of
Heading Bold Italic
— it should automatically place toolbar items that are relevant for the allowed HTML tags!
But the current \Drupal\editor\Plugin\EditorPluginInterface::getDefaultSettings()
API makes that impossible, because it is not given any context. It is currently a poorly designed API (I can say those words because I created it ~7 years ago 🙈) because it could currently have been static
.
Steps to reproduce
See above.
Proposed resolution
Take advantage of the fact that \Drupal\editor\Plugin\EditorPluginInterface::getDefaultSettings()
is not static right now, and add optional parameters:
\Drupal\editor\Plugin\EditorPluginInterface::getDefaultSettings(FilterFormatInterface $text_format, EditorInterface $old_text_editor)
That would allow it to not return a hardcoded default, but a contextually relevant default.
Remaining tasks
User interface changes
API changes
Data model changes
Release notes snippet
Issue fork drupal-3226673
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
Wim LeersComment #4
apadernoComment #6
Libbna CreditAttribution: Libbna as a volunteer and at QED42 for Drupal India Association commentedI will give it a try on this.
Comment #9
apadernoComment #10
Libbna CreditAttribution: Libbna as a volunteer and at QED42 for Drupal India Association commentedComment #11
Wim LeersThanks for pushing this forward! 🥳
Posted a review that shows next steps on how to get the builds to pass :)
Comment #13
ravi.shankar CreditAttribution: ravi.shankar at OpenSense Labs commentedTried to address comment #11, please review.
Comment #14
Wim LeersYeah … looks like that's still considered a BC break by PHP…
😬
We'll need to think of an alternative approach … the only thing I can think of: a new interface that is optional.