Contributing Code and Providing Patches to CKEditor 4
# Setting Up the Development Environment
Fork the CKEditor repository and clone your fork.
Set the development tools up if you are planning to make changes in the editor code. If you want to make a simple typographical change or a change in the comments or API docs, then you can skip the next steps.
npm install -g grunt-cli
Install CKEditor’s development dependencies (Grunt plugins, Bender.js, etc.)
cd ckeditor4 npm install
Set the testing environment up, because your changes in the editor code will need tests.
Install Git hooks (currently there is only one hook that will run a linter and code style checker when you make a commit):
Note: You can run linter and code style checker on the files that were modified (and not committed yet) by executing the default Grunt task:
Or on the entire repository (it takes a while…):
grunt jshint:all && grunt jscs:all
When the environment is set up and running you can start working on your patch. First, create a separate branch to group your changes. If there is an issue on our GitHub issues page use its number, otherwise create a new issue yourself and use its number or just pick any meaningful name:
git checkout -b t/12345
Note that all patches which change the editor code must include tests.
Every change which can be tested automatically should have at least one automated test. Read about writing tests in Bender.js.
If you do not know how to write tests for your patch, you can make an incomplete pull request and the core team will give you some hints or perhaps someone else from the community will step in.
Some types of features or bugs cannot be tested automatically. In such cases, create a manual test (see this one for instance).
To see manual tests in the Bender.js dashboard you need to change the filter from
# Creating a Pull Request
Once your patch is ready, tested and committed, push your branch to your CKEditor 4 fork:
git push origin t/12345
A CKEditor 4 core developer will review your patch. We will check things like:
- Is it clear what the patch is meant to do?
- Does the patch have tests?
- Do the changes fix the issue or do what they were meant to do?
- Is the code style correct?
Reviewing takes a lot of time and the core team is not always able to find time for it. We are sorry for any late replies that may happen!
# Changes That Cannot Be Accepted as a Pull Request
There are two main groups of changes that usually cannot be accepted as pull requests:
- New plugins. If you want to propose a new functionality which does not require changes in the core plugins, we kindly ask you to create a new plugin and add it to the Add-Ons Repository. The reason for that is that the core developers are able to maintain a limited number of plugins.
- Changes in language files. All localization fixes and improvements should be done through the CKEditor UI Translation Center. Read more in the Localization guide.
# Proposing Incomplete Patches
It may happen that you are unsure about the change that you want to make (e.g. whether you are heading in the right direction) or that you do not know how to write tests for it. Do not worry and just propose an incomplete patch. Try to explain what obstacles you encountered, so that the core team or other developers would be able to help you.