Third–party UI
CKEditor 5 is a modular editing framework that allows various flexible configurations. This includes the usage of a third–party user interface on top of the base editor classes.
In this guide, a classic–like editor will be bound to a completely separate, existing UI created in Bootstrap, providing the basic structure and toolbar items necessary to start editing.
# Readying the editor side
The ready–to–use builds of CKEditor like Classic or Inline come with a dedicated default user interface and a theme. However, to create an editor instance bound to a Bootstrap UI, only a limited subset of features is required. You need to import them first:
Note that instead of Bold
, which loads the default bold UI and bold editing feature, just the BoldEditing
is imported. It provides the engine features associated with editing any bold text but does not come with the actual UI.
Respectively, ItalicEditing
, UnderlineEditing
, HeadingEditing
and UndoEditing
are also imported.
Having imported the very basic editor components, you can define the custom BootstrapEditor
class that extends the Editor
:
# Creating the Bootstrap UI
Although the editor is ready to use, it is just a bare editable area — which is not much use to the users. You need to give it an actual interface with the toolbar and buttons.
Refer to the Bootstrap Getting started guide to learn how to include Bootstrap in your web page.
With the Bootstrap framework loaded in the web page, you can define the actual UI of the editor in HTML:
Although Bootstrap provides most of the CSS, it does not come with styles dedicated for WYSIWYG text editors and some tweaking is needed:
# Binding the UI with the editor
At this stage, you should bind the editor created at the very beginning of this guide with the Bootstrap UI defined in HTML. All the UI logic will be wrapped into a separate class matching the EditorUI
interface. You may have noticed this line in the constructor of the BootstrapEditor
:
Define the BootstrapEditorUI
and then have a closer look at the content of the class:
Almost every feature in the editor defines some command, e.g. HeadingCommand
or UndoCommand
. Commands can be executed:
But they also come with default observable properties like value
and isEnabled
. These are the entry points when it comes to creating a custom user interface because their values represent the actual state of the editor and can be followed in simple event listeners:
To learn more about editor commands, check out the Command
API. You can also console.log
the editor.commands
collection of a live editor to learn which commands it offers.
Knowing that, fill out the missing methods of the BootstrapEditorUI
.
# Binding the buttons to editor commands
_setupBootstrapToolbarButtons()
is a method that binds Bootstrap toolbar buttons to the editor features (commands). It activates the corresponding editor commands upon clicking and makes the buttons listen to the state of the commands to update their CSS classes:
# Binding the dropdown to the heading commands
The dropdown in the toolbar is a more complex case.
First, it must be populated with heading options for the users to select from. Then, clicking each option must execute a related heading command in the editor. Finally, the dropdown button and the dropdown menu items must reflect the state of the editor, for example, when the selection lands in a heading, a proper menu item should become active and the button should show the name of the heading level.
# Running the editor
When the editor classes and the user interface are ready, it is time to run the editor. Just make sure all the plugins are loaded and the right DOM element is passed to BootstrapEditor#create
:
Once everything works as expected, you may want to create a custom build of your editor to ship it across the applications. To learn more check out the Creating custom builds guide.
Every day, we work hard to keep our documentation complete. Have you spotted an outdated information? Is something missing? Please report it via our issue tracker.