ckeditor / ckeditor5

Powerful rich text editor framework with a modular architecture, modern integrations, and features like collaborative editing.

CKEditor 5

CKEditor 5 is an ultra-modern JavaScript rich-text editor with MVC architecture, a custom data model, and virtual DOM. It is written from scratch in TypeScript and has excellent webpack and Vite support. It provides every type of WYSIWYG editing solution imaginable with extensive collaboration support. From editors similar to Google Docs and Medium to Slack or Twitter-like applications, all is possible within a single editing framework. As a market leader, it is constantly expanded and updated.

Table of contents

• CKEditor 5
  • Table of contents
  • Quick start
    • CKEditor 5 online builder
    • CKEditor 5 predefined builds
      • Example installation
    • TypeScript support
    • CKEditor 5 advanced installation
      • CKEditor 5 Framework
  • Documentation and FAQ
  • Releases
  • Editing and collaboration features
  • Contributing and project organization
    • Ideas and discussions
    • Development
    • Reporting issues and feature requests
  • License

Quick start

CKEditor 5 online builder

The easiest way to start using CKEditor 5 with all the features you need is to prepare a customized build with the online builder. All you need to do is choose the preferred predefined build as a base, add all the required plugins, and download the ready-to-use package. Refer to the Online builder Quick start guide to follow this installation path.

CKEditor 5 predefined builds

CKEditor 5 predefined builds are a set of ready-to-use rich text editors. Every build provides a single type of editor with a set of features and a default configuration.

The following CKEditor 5 predefined builds are currently available:

• Classic editor
• Inline editor
• Balloon editor
• Balloon block editor
• Document editor

Example installation

Creating an editor using a CKEditor 5 build is simple and can be described in two steps:

1. Load the desired editor via the <script> tag.
2. Call the static create() method to create the editor.

In your HTML page, add an element that CKEditor should replace:

<div id="editor"></div>

Load the classic editor build (you can choose between the CDN, npm, and zip downloads):

<script src="https://cdn.ckeditor.com/ckeditor5/41.3.1/classic/ckeditor.js"></script>

Call the ClassicEditor.create() method:

<script>
	ClassicEditor
		.create( document.querySelector( '#editor' ) )
		.catch( error => {
			console.error( error );
		} );
</script>

You’re ready to go!

To find out how to start with other builds, check the Predefined builds guide in the CKEditor 5 documentation.

TypeScript support

CKEditor 5 is a TypeScript project. Starting from v37.0.0, it offers native type definitions. Check out our dedicated guide to read more about TypeScript support.

CKEditor 5 advanced installation

For more advanced users or those who need to integrate CKEditor 5 with their applications, we have prepared several other, advanced methods to do it. You can:

• Integrate the editor from source using webpack or Vite
• Use DLL builds
• Use some of the pre-made integrations with popular JavaScript frameworks:
  • Angular
  • React
  • Vue

CKEditor 5 Framework

CKEditor 5 builds allow you to quickly and easily initialize one of the many types of editors in your application. At the same time, CKEditor 5 is also a framework for creating custom-made rich text editing solutions.

To find out how to start building your editor from scratch go to the CKEditor 5 Framework overview section of the CKEditor 5 documentation.

Documentation and FAQ

Extensive documentation dedicated to all things CKEditor 5-related is available. You will find basic guides that will help you kick off your project, advanced deep-dive tutorials to tailor the editor to your specific needs, and help sections with solutions and answers to any of your possible questions. To find out more refer to the following CKEditor 5 documentation sections:

• Installing CKEditor 5
• CKEditor 5 features
• CKEditor 5 examples
• Updating CKEditor 5
• Getting CKEditor 5 support
• CKEditor 5 Framework
• API documentation

For FAQ please go to the CKEditor Ecosystem help center. For a high-level overview of the project see the CKEditor Ecosystem website.

Releases

Follow the CKEditor 5 changelog for release details and check out the CKEditor 5 release blog posts on the CKSource blog for important release highlights and additional information.

Editing and collaboration features

The CKEditor 5 Framework offers access to a plethora of various plugins, supporting all kinds of editing features.

From collaborative editing support providing comments and tracking changes, through editing tools that let users control the content looks and structure such as tables, lists, and font styles, to accessibility helpers and multi-language support - CKEditor 5 is easily extensible and customizable. Special duty features like Markdown input and output and source editing, or export to PDF and Word provide solutions for users with diverse and specialized needs. Images and videos are easily supported and CKEditor 5 offers various upload and storage systems to manage these.

The number of options and the ease of customization and adding new ones make the editing experience even better for any environment and professional background.

Refer to the CKEditor 5 Features documentation for details.

Contributing and project organization

Ideas and discussions

The development repository of CKEditor 5 is located at https://github.com/ckeditor/ckeditor5. This is the best place for bringing opinions and contributions. Letting the core team know if they are going in the right or wrong direction is great feedback and will be much appreciated!

Development

CKEditor 5 is a modular, multi-package, monorepo project. It consists of several packages that create the editing framework, based on which the feature packages are implemented.

The ckeditor5 repository is the place that centralizes the development of CKEditor 5. It bundles different packages into a single place, adding the necessary helper tools for the development workflow, like the builder and the test runner. Basic information on how to set up the development environment can be found in the documentation.

See the official contributors' guide to learn how to contribute your code to the project.

Reporting issues and feature requests

Report issues in the ckeditor5 repository. Read more in the Getting support section of the CKEditor 5 documentation.

License

Licensed under the terms of GNU General Public License Version 2 or later. For full details about the license, please check the LICENSE.md file or https://ckeditor.com/legal/ckeditor-oss-license.

ckeditor5's Issues

Introduce tests for the currently developed features

Tests for current code must be introduced after/together with the following ckeditor5 issue:
#1

Introduce the Events API

According to the following talk: ckeditor/ckeditor5-design#7

A builder's option to create non-AMD and AMD-without-polluting packages

Continuation of #6 (diff)

Define and explain the project schedule (ETA)

Keeping in mind that:

• defining 1.0's ETA without explaining the scope of this release will be pointless,
• we should release early and release often, what means that there will be smaller milestones and the solution will be usable in some specific, limited cases earlier than 1.0.0

we should define at some point (the sooner the better) a roadmap leading to the version 1.0.0. We should explain each milestone and what kind of stability and feature completeness we expect to reach at that point.

Unify some assertion styles in the tests

This topic was already discussed at the very beginning of CKEditor5 implementation, but I still can find some tests using "wrong" syntax.
As we talked here we've chosen to use expect(A)to.equal(B) over expect(A)to.equals(B) that produces a grammatically incorrect sentence. We should review all the existing tests having that in mind.

Introduce utils lib

Will close ckeditor/ckeditor5-design#13

Make .fire() return a promise

It would be interesting to have .fire() return a promise.

This would enable:

• Listeners to throw errors.
• Have asynchronous listeners (Yeah!!!)

Emitters would be able to do this (e.g.):

editor.fire( 'something' )
    .then( function() {
        // Do something on success.
    } )
    .catch( function( err ) ) {
        // Handle errors.
    } );

Introduce the CKEDITOR.isDebug property

Related to https://github.com/ckeditor/ckeditor5-core/issues/38.

We need a property which will allow us to conditionally disable/enable some debug logs. For instance it could be used as follows:

if ( CKEDITOR.isDebug ) {
    if ( doSomeSuperUnnecessaryDebugChecks() ) {
        throw new CKEditorError( 'sth-broke: Kaboom!' );
    }
}

Later on we'll need to work on #27 to make it fully functional.

The idea here is that this isn't necessarily constant (as it might need to be switchable while debugging something) and that it's something different than already existing CKEDITOR.isDev (as we may want to build a debug version of CKEditor).

Introduce a simple error logging system and error class

Implement ckeditor/ckeditor5-design#14 (comment)

Introduce CKEDITOR.create

This ticket is related to the creation part described here:
https://github.com/ckeditor/ckeditor5-design/wiki/Editor-Instances

Numbered List Adds Items when switching from Source to Preview Mode

CKEditor 4 with the current Editor Options configured:

            language: 'en',
            uiColor: '#741275',
            allowedContent: true,
            removePlugins: 'image',
            extraPlugins: 'image2,uploadimage,colorbutton,table,tableresize,tabletools,dialogadvtab',
            filebrowserImageUploadUrl: '/scripts/uploadImage.php',
            colorButton_enableMore: true

Replicate:
Open Page
=> Add/Remove Numbered List
=> Add some items to the list

My test source:

<ol>
    <li>item1</li>
    <li>item2</li>
    <li>item3</li>
</ol>

In Source mode add some line breaks between items

Test Source now looks like:

<ol>
    <li>item1</li>
    <li>item2</li><br>
    <li>item3</li><br>
</ol>

Toggle between Source/Preview mode. CKEditor will start adding line breaks and list items

After 1 iteration Test Source now looks like:

<ol>
    <li>item1</li>
    <li>item2</li>
    <br />
    <li>item3</li>
    <br />
    <br />
    &nbsp;
</ol>

Keep toggling and it becomes

<ol>
    <li>item1</li>
    <li>item2</li>
    <br />
    <li>item3</li>
    <br />
    <br />
    <br />
    <br />
    <br />
    <br />
    <br />
    &nbsp;
    <li>&nbsp;</li>
    <li>&nbsp;</li>
    <li>&nbsp;</li>
    <li>&nbsp;</li>
    <li>&nbsp;</li>
</ol>

Start using ES6 classes

As a result of ckeditor/ckeditor5-design#63.

Introduce CKEDITOR.create

Introduce the CKEDITOR.create method and the Editor class stub required by it.

Handle typing

When user type in the editor changes should be applied on the document model. To do so mutation observer have to be implemented.

Introduce the AMD API

The AMD API must be introduced according to its prototype.

package.json should be indented with tabs

Move `model` and `collection` out of the `mvc` directory

We understood that "model" is a basic concept in the API that relates to data in general. It reflects the API state.

While this concept participates in MVC, it is not exclusive for it, therefore it doesn't make much sense scoping it with a mvc directory.

Ofc, this applies to "collections" as well.

Builder configuration

This topic reminds me why I wanted to reuse some of the existing grunt tasks for the build process instead of writing the builder task on our own... Right now there's no way to configure the build process from the Gruntfile. The only way to change anything (e.g. disable uglify during r.js optimization, change the output path etc.) is to play with the builder's source code.

Introduce the minimum API for the AMD development in ckeditor5

There is a minimum API necessary for the development of the AMD API in the ckeditor5 repo:

• ckeditor module (CKEDITOR namespace).
• utils module with the extend() method.
• plugin module (Plugin class).

Parent should be a model property

Changes introduce in https://github.com/ckeditor/ckeditor5-core/pull/27 adds parent attribute as an editable property. I believe we should go deeper and add parent to the Model. If the parent is set it means that:

• all events will bubble to the parent,
• child models listen on parents destroy event and call theirs destroy functions/events if parent is destroyed,
• the parent can be passed to the config so the child config will use the parent config, like editable do (this.config.parent = parent.config).

So:

editor.parent = CKEDITOR;
editable.parent = editor;
nestedEditable.parent = editable;

Thanks to this all events will bubble from editable to editor then to the CKEDITOR, the destroy on the editor will be passed to all editable, destroy on CKEDITOR will remove all editors and restore the original content.

If the parent is no set it will be CKEDITOR.

I believe that in this case one generic solution (parent in Model) is better then many separated (parent in editable, EditorConfig for bubbling config, adding destroy listener manually, bubbling events).

Make the dev version AMD only

I've been doing my best to try to make the dev version of v5 (the code in ckeditor5) in a way that it works out of the box in websites using CKEditor,in the very same way the build version would work. Essentially, we're talking about having the CKEDITOR namespace exposed and ready to be used.

The problem is that the CKEDITOR namespace is made by code present in several files in ckeditor5-core which need to be downloaded before the namespace gets ready. So, to do it, we limited the number of features in CKEDITOR on startup, extending it asynchronously while loading core.

Now I'm working on #3, to introduce CKEDITOR.create(). Here again, we would have to have a fake create() function that would just save the creation call to be really executed just later, when core is loaded. We do this in v4 and it "works", but it's a mess and the code is dirty.

To make it worst, we would like create() to return a Promise, which is a class from core. So, if core is not available, we would have to return something the looks like a promise and so on... more dirty and unclear code.

Therefore, I think we're going to the wrong direction.

In short, we're not able to make the CKEDITOR namespace work right with the dev version, so we should make it AMD only.

In any case, we require RequireJS to run dev code. So we'll always have AMD in place.

This means that, when using the dev code, one should always do something like the following:

require( [ 'ckeditor' ], function( CKEDITOR ) {
    CKEDITOR.create( ... );
} );

Then, the build version will offer the CKEDITOR namespace as well, but we'll not have it in the dev version.

I need a confirmation for this so I can work on this change.

Operation builder

It should be possible to bold part of the document using simple command in JavaScript console:

var builder = new Builder( document );
builder.addAttribute( range, bold );
builder.modification.render();

To do so, Builder and Modification classes should be created. Modification is a set of transactions with additional information about changed nodes.

Confusing Model's variables naming (attribute vs property)

I've just like to let you know that differentiation between Model's property and attribute is not clear.
I get the impression that is a "potato, potato" problem - #26 (comment).
After talking with @pjasiun I get that attribute is a property that someone can listen to its changes.

This might give some problems:

• Newcomers would have to read a documentation on in and remember which one is which.
• For me attribute and property are synonims which other devs might found confusing - again one will have to remember which one use in which case.

Maybe giving attribute more meaningful name would make sense?
Ideally no docs should be needed or name would be connected to function so it will be easily remembered.

Builder should shorten log messages

Followup of https://github.com/ckeditor/ckeditor5-core/issues/38.

All usages of log.error(), log.warning(), CKEditorError() must be processed and the messages should be removed (only error names should be left). Additionally, we may decide to add some validation (may be built into this step) that error messages have the correct format.

Note: Theres' no support yet for placeholders in the error messages (they were mentioned in ckeditor/ckeditor5-design#14 (comment)). I don't think we must have, so I didn't want to unnecessarily complicate things.

Tests for the builder

Obviously a mast-have.

(Nota bene all other Grunt tasks need tests too.)

Introduce the Mixin class

Following recent talks, to make the use of mixins more elegant, we should introduce the Mixin class.

The following is a usage example of it:

var EmitterMixin = new Mixin( {
    method1: ...,
    method2: ...
} );

function TargetClass() {}

EmitterMixin.mixin( TargetClass.prototype );

The constructor basically accepts the mixin properties and the class exposes a single mixin() method to mix such properties in a target.

Document Model

Create a document model data structure. It should contains:

• linear data,
• document tree,
• main document model class with applyTransactionapply method,
• transactions operations.

Applying transactions should create or remove linear data and nodes.

One it() should contain only one test case

This one: https://github.com/ckeditor/ckeditor5/blob/master/tests/ckeditor/basepath.js#L37 contains two.

One of the bad things that we do in CKE4 is merging maaaany tests into single test functions which is bad for multiple reasons:

1. It looks that we have less tests that we really have :D.
2. It's hard to figure out which of these sub cases fails when it fails.

Ofc this ticket is only a symbolic reminder about the new era ;).

One of the basePath tests fails on Firefox

A test called "basePath should work with script tags - \ckeditor\ckeditor.js" fails on Firefox. Tested with FF version 37.0.1.

Introduce promises lib

Will close ckeditor/ckeditor5-design#43

Create a document model on editors creation

When editor is created:

• document model should be created (linear data + document tree),
• editable data should be load, transformed to linear data, and fill document model,
• document model should be rendered, so the filtered content will replace the original content in the editable element.

Introduce utils lib

Will close ckeditor/ckeditor5-design#13

Disable ckeditor with class

I don't know it is already answered but I can't find how to disable ckeditor with a class name given.

First, I replace all textareas using:

CKEDITOR.replaceAll();

Then, I what to disable all textareas that have disable class name:

<textarea class="disable" name="editor"></textarea>

How can I do that using class instead of its name?

Thanks!

Introduce implementation examples

The ckeditor5 repo should contain a set of examples of implementations. It has the purpose of both showcasing the different uses of CKEditor as well as being a tool to drive the development of all necessary features.

We predict the following implementations:

• Forms: CKEditor used inside forms.
• Inline: several editing spots in a document with the editor toolbar floating.
• Inline Page: an app toolbar at the top which is used by CKEditor when editing spots in the page are focused.
• Comments: CKEditor in use for comments in an article.
• Single Line: rich-text editing on a single line.
• Input: CKEditor used as a simple form input field (on steroids ;)).
• Custom: A totally customized editor based on CKEditor.
• E-Mail: CKEditor used to write e-mails.
• Medium: A Medium-like editor.
• GitHub: an editor that output GitHub's markdown with potential to replace the textareas used by GitHub on wiki and issues.
• Stack Overflow: an editor that output Stack Overflow's markdown with potential to replace the textareas used by Stack Overflow.
• Gmail: an editor with the same UI features available in the Gmail editor.
• JQuery UI: an editor that uses JQuery UI as the UI library.
• An example with the placeholder widget (used e.g. to display dynamic data from an external data set directly in the editor).
• Twitter-like example.

This is an "umbrella issue". Every implementation should be handled on separate issues.

Introduce tests and Bender.js

The infrastructure for testing must be created, including proper bender configuration.

Stable release date

Apologies if this has been answered elsewhere: I had a look and couldn't find it anywhere else.

Do you have an estimated date when a stable version of ckeditor5 will be available?

Introduce Model (MVC)

Independently of other MVC aspects, the first thing to get developed is the Model class, providing the basics for model data and observables.

Mark model attributes using @attribute instead of @property

Currently we use one tag for all of them what requires reading the code to understand their meaning. Let's introduce an @Attribute tag and we'll find a way to extend JSDoc to handle it.

Introduce the build process

The build process must be introduced.

Introduce promises lib

Will close ckeditor/ckeditor5-design#43

Change Emitter to EmitterMixin

Following our talks, mixins should be named UpperCamelCased postfixed with "Mixin". We need to change what we have so far accordingly.

Plugins path resolution

The RequireJS "plugin" plugin must be created as well as the features to resolve CKEditor plugins paths.

Builder should set CKEDITOR.isDebug to false and remove unreachable code

In https://github.com/ckeditor/ckeditor5-core/issues/38 we proposed couple of logging mechanisms, one of them being the CKEDITOR.isDebug property which can be used to wrap debug code.

         *      if ( CKEDITOR.isDebug ) {
         *          if ( doSomeSuperUnnecessaryDebugChecks() ) {
         *              throw new CKEditorError( 'sth-broke: Kaboom!' );
         *          }
         *      }

The builder should have an option (enabled by default) to set that property to false and also to remove unreachable code. The Uglify.js has a --define option which allows to preset some variable and then remove code that will not be reachable, but I'm not sure if it's going to work with an object property. If this will be a problem, then we can:

1. Rename CKEDITOR.isDebug to CKEDITOR_DEBUG, but that would be ugly, as we also have CKEDITOR.isDev which could also be covered by a similar mechanism.
2. Add our own extension to Uglify.js which will check this.

CKEDITOR._getBasePath() has insufficient tests

It may have 100% tests coverage, but this means that every statement is executed, not that every statement is correct. Since there's a pretty complex regexp used in which we already had bugs in CKE4, more tests are required.

Furthermore, we have good tests for this in v4. Why not porting them?

Can't run tests because of "Uncaught Error: Mismatched anonymous define() module"

On 21b0cf9 and ckeditor/ckeditor5-core@237ba98 when running tests I get:

require.js:166 Uncaught Error: Mismatched anonymous define() module: function () {
      return (root.sinon = factory());
    }
http://requirejs.org/docs/errors.html#mismatch
bender.js:105 Error: Deferment unlock timeout - please check your plugins
    at client.js:433

Do I miss something?

package.json should be indented with tabs

Introducing the Plugins API

Introduce the Plugins API according to the design docs:
https://github.com/ckeditor/ckeditor5-design/wiki/Plugins

Define JSHint globals

Based on https://github.com/ckeditor/ckeditor5/pull/11/files#r23282090.

I wasn't sure if I shouldn't report this ticket in ckeditor/ckeditor5-design repository, but we'll need this one anyway, so let's start here :).

Introduce the first "creators"

The basics for the following creators should be introduced:

• Inline Editor Creator (ckeditor5-plugin-inlinecreator)
• Classic Editor Creator (ckeditor5-plugin-classiccreator)

The minimal expected features:

• Make the minimal necessary DOM manipulation expected by the creator.
• Load input data from the source element.
• Initialize the root editable.
• On destroy:
  • Revert the initial DOM manipulation.
  • Set output data back to the source element.

Introduce the Configuration System

The overall specs for the Configuration System are available here:
https://github.com/ckeditor/ckeditor5-design/wiki/Configuration