This guide describes integrating the revision history feature as a standalone plugin.

If you are using the real-time collaboration feature, refer to the Real-time collaboration features integration guide.

The revision history plugin provides an API for creating and managing named revisions of the document. To save and load the revisions from your database you need to provide a proper integration.

This guide will discuss two ways to integrate CKEditor 5 with revision history plugin:

The adapter integration is the recommended one for two reasons:

Revision history is a commercial plugin and a license key is needed to authenticate. If you do not have one, please contact us. Let us know if you have any feedback or questions!

If you already have a valid license, please log into your user dashboard to access the plugin settings.

If you have more than one licence for CKSource products (comments, track changes, revision history or pagination), you may use any key of those generated in the dashboard.

Before you start creating an integration, there are a few concepts you should be familiar with. This guide will explain how to create a custom build with the revision history plugin, what data structure do the revisions use and what the plugin API looks like.

Make sure that you understand all of these concepts before you proceed with the integration.

The revision history plugin is not included by default in any CKEditor 5 build. To enable it, you need to create a custom CKEditor 5 build that includes the revision history plugin.

You can also easily create your own CKEditor 5 build with the revision history feature included using the CKEditor5 online builder.

You need to install the @ckeditor5/ckeditor5-revision-history package using npm:

To make the revision history work, you need to import revision history plugin and add it to the list of plugins.

An updated src/ckeditor.js should look like this:

Note that your custom build needs to be bundled using a webpack.

Read more about this topic in the installing plugins guide.

The examples below implement the wide sidebar display mode to display comments and suggestions.

When you have the revision history package included in your custom build, prepare an HTML structure for the editor sidebar and revision history. After that you can enable the revision history plugin.

To browse through the saved revisions, the feature uses an additional editor instance on top of the original editor instance. To enable that, you will need to provide an HTML structure for both the original editor and the revision history editor. The HTML elements for the revision history editor structure should be hidden by default.

To set up the feature, you need to:

Edit the sample/index.html file as follows:

When you open the sample in the browser, you should see the WYSIWYG editor with the revision history plugin. However, it still does not load or save any revision data and the user is not defined. You will learn how to add those later in this guide.

In this solution, users and revisions data are loaded during the editor initialization and revisions data is saved after you finish working with the editor (for example when you submit the form containing the WYSIWYG editor).

The integration below uses the revision history API. Making yourself familiar with the API may help you understand the code snippets. In case of any problems, refer to the revision history API documentation.

After you include the revision history plugin in the editor, you need to create your own additional plugin that will initialize users and existing revisions.

It is important to load the revisions data during the plugins initialization step, i.e. using the init() method of the integration plugin that you will provide (as in the example below).

First, dump the users and the revisions data into a variable that will be available for your plugin.

Note, that the revisions data may be very heavy for large documents, which will have an impact on your application loading time. Since the adapter integration loads the revisions data on demand, it is the recommended integration type for applications handling bigger documents with many revisions.

If your application needs to request the revisions data from the server asynchronously, you can create a plugin that will fetch the data from the database instead of putting the data in the HTML source. In such a case, your plugin should return a Promise from the Plugin.init method to make sure that the editor initialization waits for your data.

You can also refer to an example shown in the adapter integration section.

This publishing contract, the “contract”, is entered into as of 1st June 2020 by and between The Lower Shelf, the “Publisher”, and John Smith, the “Author”.

The Author grants the Publisher full right and title to the following, in perpetuity:

These rights are granted by the Author on behalf of him and their successors, heirs, executors, and any other party who may attempt to lay claim to these rights at any point now or in the future.

Any rights not granted to the Publisher above remain with the Author.

The rights granted to the Publisher by the Author shall not be constrained by geographic territories and are considered global in nature.

Then, prepare a plugin that will read the data from appData and use the Users and RevisionsRepository API.

Document data and revisions data have to be kept in sync for the feature to work correctly.

It is important that you always save revisions data and document data together.

To save the revisions data you need to get it from the RevisionsRepository plugin first. To do this, use the getRevisions() method.

Then, use the data to save it in your database in a selected way. See the example below (remember to update your HTML structure to contain a button with get-data id, e.g. Get editor data).

It is recommended to stringify the revisions’ attributes property value to JSON and to save it as a string in your database. Then parse the value from JSON when loading revisions.

Below you can find the final implementation.

This publishing contract, the “contract”, is entered into as of 1st June 2020 by and between The Lower Shelf, the “Publisher”, and John Smith, the “Author”.

The Author grants the Publisher full right and title to the following, in perpetuity:

These rights are granted by the Author on behalf of him and their successors, heirs, executors, and any other party who may attempt to lay claim to these rights at any point now or in the future.

Any rights not granted to the Publisher above remain with the Author.

The rights granted to the Publisher by the Author shall not be constrained by geographic territories and are considered global in nature.

An adapter integration uses an adapter object — provided by you — to immediately save revisions data in your data store.

This is a recommended way of integrating revision history with your application as it lets you handle the client-server communication in a more secure way. For example, you can check user permissions, validate sent data or update the data with information obtained on the server side.

Additionally, revisions may include significant amount of data. Loading multiple revisions of a big document may adversely impact the loading time of your application. When using an adapter, the revision data is loaded on demand, when needed, which improves the overall user experience.

It is important to load the revisions data during the plugins initialization step, i.e. using the init() method of the integration plugin that you will provide (as in the example below).

Note that this sample does not contain the comments and track changes adapters. Check the comments integration guide and track changes integration guide to learn how to build a complete solution. Also note that those snippets define the same list of users. Make sure to deduplicate this code and define the list of users only once to avoid errors.

Before we move to the actual implementation it is important to note that document data and revisions data should be always kept in sync. This means that whenever one is saved, the other should be saved as well. This is natural for “load & save” integration but for adapter integration, we need to keep that in mind. Mismatch in the data will result in the feature not working correctly.

Additionally, document data should not be further post-processed after it is saved. To be precise, it should not be changed in a way that would result in a different model, after the document data is loaded.

First, define the adapter using the RevisionHistory#adapter property. The adapter methods allow you to load and save changes in your database. Read the API reference for RevisionHistoryAdapter carefully to make sure that you integrate the feature with your application correctly.

Each change in revisions is performed immediately on the UI side. However, all adapter actions are asynchronous and are performed in the background. Because of this, all adapter methods need to return a Promise. When the promise is resolved, it means that everything went fine and a local change was successfully saved in the data store. When the promise is rejected, the editor throws a CKEditorError error, which works nicely together with the watchdog feature. When you handle the server response, you can decide if the promise should be resolved or rejected.

While the adapter is saving the revision’s data, a pending action is automatically added to the editor PendingActions plugin, so you do not have to worry that the editor will be destroyed before the adapter action has finished.

Now you are ready to implement the adapter.

This publishing contract, the “contract”, is entered into as of 1st June 2020 by and between The Lower Shelf, the “Publisher”, and John Smith, the “Author”.

The Author grants the Publisher full right and title to the following, in perpetuity:

These rights are granted by the Author on behalf of him and their successors, heirs, executors, and any other party who may attempt to lay claim to these rights at any point now or in the future.

Any rights not granted to the Publisher above remain with the Author.

The rights granted to the Publisher by the Author shall not be constrained by geographic territories and are considered global in nature.

It is recommended to stringify the revisions’ attributes property value to JSON and to save it as a string in your database. Then parse the value from JSON when loading revisions.

The adapter is now ready to use with your rich text editor.

This publishing contract, the “contract”, is entered into as of 1st June 2020 by and between The Lower Shelf, the “Publisher”, and John Smith, the “Author”.

The Author grants the Publisher full right and title to the following, in perpetuity:

These rights are granted by the Author on behalf of him and their successors, heirs, executors, and any other party who may attempt to lay claim to these rights at any point now or in the future.

Any rights not granted to the Publisher above remain with the Author.

The rights granted to the Publisher by the Author shall not be constrained by geographic territories and are considered global in nature.

Revision history uses pending actions feature. Pending actions are added when revisions data is being updated through the revision history adapter, to prevent closing the editor before the update finishes.

When the revision history feature is used, it is crucial to keep the revisions state in synchronization with the document data. Because of that, if there are any revisions saved for a document, the editor initial data will be discarded and the data saved with the most recent revision will be used instead.

Since the editor initial data is discarded, you can lower the data load by setting document initial data to empty (applies only to documents for which at least one revision was created).

If the editor initial data was set, and it was different from the revision data, a warning will be logged in the console.

If you are using the real-time collaboration feature, refer to the Autosave for revision history section in the Real-time collaboration features integration guide.

Below section describes how to correctly integrate revision history with the autosave plugin. This way you can frequently save both your document data and your revisions data, and keep them in sync.

Although this guide provides ready-to-use snippets, we encourage you to also read How revisions are saved and updated section to get a better understanding of this subject.

If the autosave plugin is enabled, the autosave callback is additionally called when the revision history view is opened.

The integration differs a bit whether you use adapter or not.

Update the revision and make sure that the updated or created revision is saved together with the editor data:

Integration when using the adapter is easier, because your revision adapter should save the document data as well, as was already shown in the earlier examples.

Since the adapter already takes care of saving both revision data and the document data, all that needs to be done in the autosave integration is to update the revision:

Presented integrations will simply keep on updating the same revision until the user explicitly saves or names the current revision or closes the editor.

This may result in creating a very big revision, containing a lot of changes. To prevent that, autosave integration could create new revisions basing on your custom strategy.

For example, you may decide to save the current revision (unsaved changes) after chosen number of autosave callbacks since the last saved revision:

Similarly, you can implement a saving strategy that would include time since the last saved revision, number of operations, or multiple variables used together to decide if a new revision should be saved.

Understanding how and when revisions are updated and saved is important when it comes to writing custom code that integrates with revision history, including autosave integration.

There are always at least two revisions available for a document: the initial revision and the current revision. If the document is new and no revisions has been created for it yet, the two revisions are created when the editor is initialized.

The initial revision contains the editor data from when the document was initialized for the first time. It can be empty or contain some content. The initial revision’s id will equal to document id or to 'initial' if the document id is not specified.

The current revision is a revision that stores all unsaved document changes, i.e. changes that has not been saved in earlier revisions. It is always on top of the revisions list. If a new revision is created it will contain all unsaved changes and will be added below the current revision. Then, the current revision will be empty, until again updated with new, unsaved document changes. An empty current revision is not shown on the revisions list.

Note, that the current revision is not updated automatically when document is changed. The update can be done using the revisions feature API. It is enough to update the current revision only when you need to save it – e.g. in the autosave callback. The update is also triggered when the revision history view is opened. In this case, either autosave callback is called, or the current revision is updated (if autosave plugin is not used).

A new revision can be saved using the revisions feature API. Also, a new revision will be created when:

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.