In this section you will learn about plugins and configuration options provided for integration of CKEditor 4 into CoreMedia Studio. While some of them were more or less private or undocumented API, you may have relied on them to extend CKEditor 4 behavior. You will get to know, how to deal with their provided features or configurations when upgrading to CKEditor 5.

Plugin cmstyles

cmstyles was a mostly invisible plugin, which, for example, added commands for underline, strikethrough. With CKEditor 5 the design pattern “HTML first” is used.

HTML first means, instead of inserting CoreMedia Rich Text 1.0 compatible <span> tags with corresponding classes, now data-transformation is used to transform, for example, HTML element <u> to <span class="underline">.

Nevertheless, it also added undocumented style commands similar to styling in CoreMedia Site Manager, like color_lime or background_color_fuchsia.

Plugin classstyles

The classstyles plugin provided the opportunity to define custom classes to be applied to matching elements as described in Section 10.2.2.3, “Adding Custom Rich Text Style Classes”.

A possible alternative in CKEditor 5 is the Styles feature. In general, we recommend choosing alternative plugins instead, which are more dedicated to the use-case like choosing font families, background colors, etc. This is because classes applied by Styles are additive, i.e., there is no way to toggle between certain styles.

For details of integrating custom plugins, have a look at Section 10.1.3, “CKEditor 5 Customization”. For configuration of the plugins, it may be helpful to read and understand: Section 10.1.1.2, “Design Principle: HTML First”.

If you find no suitable plugin, we recommend developing your own plugin, like, for example, a list styling plugin with custom UI and commands, applying different styles to lists like using arrows instead of bullets in front of list items. For a start have a look at the corresponding guide: Creating a basic plugin.

If you find a suitable plugin, but the representation especially in data view does not match your expectations, you may instead want to adapt model processing. See Section 10.1.1.1, “Glance at CKEditor 5 Architecture” for the general architecture. Given the plugin uses the style attribute, you may want to apply a corresponding mapping to class attribute. This is best done in a plugin, which adds handlers for dataDowncast and upcast. This plugin should validate, if the plugin it augments with additional processing is actually available.

Plugin elasticbbcode

There is no replacement for the elasticbbcode plugin, yet. Thus, for editing BBCode, you still have to use CKEditor 4.

Plugin cmsymbolfontmapper

The CKEditor 4 plugin is replaced by a plugin for CKEditor 5. For details, see Section 10.1.2.3, “Font Mapper Plugin”. Note, that the previously available configuration options are not available. Instead, you have to map the corresponding configuration and apply it to the CKEditor 5 configuration within CoreMedia Blueprint.

Plugin cmrichtextdataprocessor

cmrichtextdataprocessor has been replaced by Rich Text Plugin. As its successor, cmrichtextdataprocessor was responsible for mapping CoreMedia Rich Text 1.0 to some format, that could be edited within CKEditor.

While cmrichtextdataprocessor always was private API, understanding its concepts based on CKEditor 4 data-processing was important for introducing new elements or attributes, for example. That is why Section 10.2.3, “Debugging CKEditor 4” exposes details to understand the data-processing in CKEditor 4 and where to hook into (in other words: which listener priorities to choose), to apply corresponding mappings.

With Rich Text Plugin CoreMedia provides configuration options, to apply similar mappings as it was possible for CKEditor 4. Understanding them is crucial, to migrate your mappings you designed for CKEditor 4 to CKEditor 5.