Troubleshooting migration from CKEditor 4

This article describes some issues that you may encounter when migrating from CKEditor 4 to CKEditor 5.

Unlike CKEditor 4, CKEditor 5 implements a custom data model. This means that every piece of content that is loaded into the editor needs to be converted to that model and then rendered back to the view.

Each kind of content must be handled by a dedicated plugin. For instance, the ckeditor5-basic-styles package handles HTML elements such as <b>, <i>, <u>, etc. along with their representation in the model. The feature defines the two–way conversion between the HTML (view) and the editor model. Content that none of the enabled features recognizes is dropped.

There is no equivalent of config.allowedContent = true. To keep your content, consider the following options, starting with the least amount of work:

1. Enable the feature that handles the markup. Some content is dropped only because the matching plugin is missing from your setup. Refer to the Migrating existing data section of the migration guide for legacy markup that CKEditor 5 maps once the right plugins are loaded.
2. Use the General HTML Support feature. It preserves elements, classes, attributes, and styles that no feature covers, and it requires no code.
3. Write a plugin. For markup that needs actual editing behavior rather than preservation, implement the conversion yourself. Refer to the Creating plugins section.

There is no such thing as the contents.css file anymore. This is because in CKEditor 5 the features bring their own content styles, provided via CSS files.

Refer to this CKEditor 5 How-to question.

Refer to this CKEditor 5 How-to question.