Environment
- OTOBO 11.0.15 / current
rel-11_1
- CKEditor 5 (47.6.1 bundled)
Problem
Since the CKEditor 5 migration there is no way for OTOBO packages (add-ons) to provide their own CKEditor plugins.
In rel-11_1 the active plugin list is nicely configurable via Frontend::CKEditorPlugins — thank you for that! However, Core.UI.RichTextEditor.js resolves each configured name against the CKEditor5Wrapper ES module namespace only:
for (let pluginName of PluginList) {
let Plugin = CKEditor5Wrapper[pluginName];
...
}ES module namespace objects are not extensible, so a package cannot register anything there. Adding a custom plugin name to Frontend::CKEditorPlugins can only ever produce Couldn't find plugin — the mechanism is limited to plugins compiled into the CKEditor bundle.
(In rel-11_0 there was a plain-object registry window.CKEditor5Plugins built in Core.UI.CKEditor5Wrapper.js, which packages could extend. That registry is gone in rel-11_1.)
Use case
We are porting CKEditor 4 era behavior that customers rely on, implemented as small CKEditor 5 plugins shipped by a package, e.g.:
- a clipboard normalizer that restores Excel cell background colors on paste (see the companion issue about paste from Excel),
- an image border toggle button (CKEditor 4 had a border field in the image dialog; CKEditor 5 has none).
Both work fine as CKEditor 5 plugin classes written against the exposed window.CKEditor5Wrapper namespace — the only missing piece is an official way to register them.
Proposal
Resolve plugin names against a mutable registry as fallback:
let CustomPlugins = window.CKEditor5CustomPlugins || {};
let Plugin = CKEditor5Wrapper[pluginName] || CustomPlugins[pluginName];A package then ships a loader JS file that registers its class in window.CKEditor5CustomPlugins and adds the plugin name to Frontend::CKEditorPlugins via SysConfig. No core behavior changes for standard installations.
A pull request implementing this is ready and will be linked here.
Environment
rel-11_1Problem
Since the CKEditor 5 migration there is no way for OTOBO packages (add-ons) to provide their own CKEditor plugins.
In
rel-11_1the active plugin list is nicely configurable viaFrontend::CKEditorPlugins— thank you for that! However,Core.UI.RichTextEditor.jsresolves each configured name against theCKEditor5WrapperES module namespace only:ES module namespace objects are not extensible, so a package cannot register anything there. Adding a custom plugin name to
Frontend::CKEditorPluginscan only ever produceCouldn't find plugin— the mechanism is limited to plugins compiled into the CKEditor bundle.(In
rel-11_0there was a plain-object registrywindow.CKEditor5Pluginsbuilt inCore.UI.CKEditor5Wrapper.js, which packages could extend. That registry is gone inrel-11_1.)Use case
We are porting CKEditor 4 era behavior that customers rely on, implemented as small CKEditor 5 plugins shipped by a package, e.g.:
Both work fine as CKEditor 5 plugin classes written against the exposed
window.CKEditor5Wrappernamespace — the only missing piece is an official way to register them.Proposal
Resolve plugin names against a mutable registry as fallback:
A package then ships a loader JS file that registers its class in
window.CKEditor5CustomPluginsand adds the plugin name toFrontend::CKEditorPluginsvia SysConfig. No core behavior changes for standard installations.A pull request implementing this is ready and will be linked here.