Configure the Editor

XWiki integrates CKEditor. However XWiki doesn't offer by default all the options you'll find in CKEditor by default. The reason is that we want to offer a simple editor suited for a wiki and there are some features that are less useful in a wiki. In addition we'd like users to be able to focus on writing content and less about style. However you can tune the configuration if you wish to enable those options.

Starting with version 1.9 the recommended way to configure the CKEditor is through the dedicated "WYSIWYG Editor" section in the Wiki Administration.

If you want to configure the CKEditor globally for all the wikis in your farm then you have to copy the file META-INF/resources/webjars/application-ckeditor-webjar/<version>/config.js from WEB-INF/lib/application-ckeditor-webjar-<version>.jar to WEB-INF/classes, preserving its path, and modify it. Don't forget that the configuration properties set at wiki level overwrite the global settings.

If you have an older version of the CKEditor Integration extension installed (<1.9) and you cannot upgrade, you can still configure the editor. You have the following options:

  1. You can edit the CKEditor.EditSheet page using the Object editor, expand the first JavaScriptExtension object ("CKEditor Loader") and look for the ckeditor.replace line. You'll notice there the configuration options.
  2. On XWiki 8.1M1+ you can create a JavaScript extension with the following code:
    require(['deferred!ckeditor'], function(ckeditorPromise) {
      ckeditorPromise.done(function(ckeditor) {
        ckeditor.on('instanceCreated', function(event) {
         // The editor instance was created but it not yet initialized. Unfortunately the configuration object passed when
         // the instance was created has not been merged with the global configuration yet.
         event.editor.once('configLoaded', function(event) {
           // The editor configuration has been loaded (the instance configuration has been merged with the global
           // configuration) but the editor has not been fully initialized yet so we can modify the configuration.
 , {
              height: 200,
            }, true);

    Don't forget to set "Use this extension" to "On this wiki".

Configuration Parameters

Check out the CKEditor documentation for the full list of generic configuration parameters. Besides these, there are also some configuration parameters that are specific to XWiki. You can set any configuration parameter (either generic or XWiki-specific) using the Advanced configuration text area from the CKEditor administration section. The XWiki-specific parameters are set like this:

// 'xwiki-link' is the name of a CKEditor plugin.
config['xwiki-link'] = config['xwiki-link'] || {};
// 'autoGenerateLabels' is the configuration parameter for that plugin.
config['xwiki-link'].autoGenerateLabels = true;
applyPasteFilterAfterPasteFromWordWhether to apply the paste filter after the Word filter. Default value is true1.19
xwiki-imageresourceTypesThe resource types you can select from on the Image dialog. See for the list of supported resource types. The default value is: ['attach', 'icon', 'url']
xwiki-linkresourceTypesThe resource types you can select from on the Link dialog. See for the list of supported resource types. The default value is: ['doc', 'attach', 'url', 'mailto']
autoGenerateLabelsWhether to create links with auto-generated labels or links with explicit labels. Auto-generated labels are updated automatically when the target page is moved or renamed but they increase a bit the rendering time and the output may be technical, depending on how you configure the link label generation. The default value is false1.14
labelGeneratorThe service used to obtain the generated link labels, in case autoGenerateLabels is true.1.14
xwiki-macroinsertButtonsUsed to put dedicated insert macro buttons on the tool bar. See the following sections for more information. The default value is []1.13
xwiki-resourcedispatcherThe service used to obtain resource URLs.
xwiki-savesaveAndContinueButtonThe CSS selector for the Save & Continue button. The default value is: 'input[name=action_saveandcontinue]'
leaveConfirmationWhether to ask for confirmation when leaving the editor with unsaved changes. The default value is true
xwiki-sourcehtmlConverterThe service used to convert between HTML and wiki syntax. This is used when switching between WYSIWYG and Source modes.

Put Dedicated Insert Macro Buttons on the Tool Bar

Starting with version 1.13 you can speed up macro insertion by placing dedicated insert buttons on the tool bar. The following configuration adds two more buttons to the tool bar: the first inserts a Page Tree and the second inserts an HTML snippet.

config['xwiki-macro'] = config['xwiki-macro'] || {};
config['xwiki-macro'].insertButtons = [
    commandId: 'xwiki-macro-html-dirty',
    macroCall: {
      name: 'html',
      parameters: {
        clean: false,
        wiki: true

As you can see, there are two ways in which you can specify the buttons:

  • a simple way: you just specify the macro name
  • an advanced way: you can specify also the macro parameter values and the command name (which is needed if you add move buttons for the same macro)

Then, you can control the button icon by using some CSS in a custom skin or by using a SSX Skin Extension. Here's an example:

a.cke_button.cke_button__xwiki-macro-documenttree > span.cke_button_icon.cke_button__xwiki-macro-documenttree_icon {
 font-family: 'Glyphicons Halflings';
 position: relative;
 top: 1px;
.cke_button_icon.cke_button__xwiki-macro-documenttree_icon::before {
 content: "\e199";
 display: inline-block;
 text-align: center;
 width: 16px;

In this example we've used a font icon, but you can use whatever icon you want through CSS.

Use additional CKEditor plugins

For the CKEditor integration with XWiki we have selected a list of CKEditor plugins that we bundle by default. They provide the basic WYSIWYG editing features like text formatting, inserting links, images, tables, etc. The integration with these default plugins is supported by the XWiki Development Team, which means you can report issues and we'll look into them. There are many more CKEditor plugins available that you can integrate separately in XWiki, but you should be aware that they are not supported by the XWiki Development Team. The most common issue you can have with these plugins is that they may generate HTML that cannot be converted to the XWiki syntax.

You need to do two things if you want to integrate additional CKEditor plugins:

  1. Let CKEditor know where the plugin is located:
    CKEDITOR.plugins.addExternal('plugin name', 'plugin URL or path');

    You can put this:

    • in the "Advanced Configuration" text area from the CKEditor administration section, if you can hard-code the plugin URL/path or compute it on the client-side using only JavaScript. E.g.: assuming the CKEditor plugin is defined in the Sandbox.Foo JavaScript skin extension like this
      CKEDITOR.plugins.add('foo', {
        init: function(editor) {

      then you can specify its location with this:

      CKEDITOR.plugins.addExternal('foo', new XWiki.Document('Foo', 'Sandbox').getURL('jsx'));
    • or in a JavaScript skin extension. E.g.: assuming the CKEditor plugin is defined by resources/ckeditorPlugins/foo.js within the XWiki WAR then you can specify its location with
      require(['deferred!ckeditor'], function(ckeditorPromise) {
        ckeditorPromise.done(function(ckeditor) {
          ckeditor.plugins.addExternal('foo', "$xwiki.getSkinFile('ckeditorPlugins/foo.js')");

      Make sure the JSX is configured to be loaded automatically on the entire wiki.

  2. Enable the plugin in the CKEditor configuration:
    config.extraPlugins = 'foo,bar';

Execute JavaScript code inside the editing area (XWiki 10.10+)

The sheet (CKEditor.ContentSheet) used to render the content of the edited page inside the editing area doesn't load, by default, the JavaScript code required by the edited content. This means, for instance, that if the edited content is using a macro that requires some JavaScript code in order to be displayed properly then that JavaScript code is not executed and thus the macro output doesn't look good inside the editing area. There are multiple reasons for this behavior:

  • loading and executing the JavaScript code slows down the editor
  • the JavaScript code could modify the edited content (outside of the protected macro output) and these changes would be saved
  • the JavaScript code could throw exceptions or interfere with the CKEditor code thus breaking the editor which may lead to content loss
  • executing the JavaScript code opens the door to XSS attacks

One way to fix the macro output, while still being safe with respect to JavaScript, is to modify the macro code so that it behaves differently when executed in WYSIWYG edit mode. The macro could for instance generate a placeholder (e.g. an image) in WYSIWYG edit mode, that doesn't need JavaScript.

If this is not enough and you really want to execute the JavaScript code inside the editing area then you need to do this:

  1. Enable the loading of the JavaScript Skin Extensions from the CKEditor administration section
  2. Modify the macro code to mark the scripts that are safe to be loaded inside the editing area:
    #set ($discard = $xwiki.jsx.use('Path.To.MyMacro', {'wysiwyg': true}))
  3. Use the macro from the CKEditor and look for:
    • JavaScript exceptions in the JavaScript console
    • Content that should not be saved

    If you get this then you need to fix the JavaScript code.

Replace the Default Editor (before XWiki 8.2)

Starting with XWiki 8.2 the CKEditor is the default WYSIWYG editor so this section applies only to the older versions of XWiki.

When Editing a Page

By default this extension adds a new "CKEditor" entry to the Edit menu. This means that the CKEditor won't be available for your simple users because only the advanced users have the Edit menu. The simple users have only the Edit button/link/icon. In order to open the CKEditor by default (i.e. replace the default editor) you can navigate to the CKEditor.EditMenuEntry page and from the Objects editing mode replace the Code property of the existing JavaScriptExtension object with:

require(['jquery'], function($) {
  $('#tmEdit > a, a#tmEditDefault').attr('href', function(index, url) {
   return url + (url.indexOf('?') < 0 ? '?' : '&') + 'editor=inline&sheet=CKEditor.EditSheet';
  $('a#tmEditWysiwyg').attr('href', function(index, url) {
   return url.replace('editor=wysiwyg', 'editor=inline&sheet=CKEditor.EditSheet');

As a result the URL of the default edit link will point to the CKEditor. This has no effect though if you open the edit page directly using the URL (browser address bar). If you want the default edit URL (e.g. /xwiki/bin/edit/A/B/C) to open the CKEditor then you'll have to modify the edit.vm Velocity template (e.g. in a custom skin).

When Editing a Section of a Page

In order to be able to edit page sections using the CKEditor you need to edit the CKEditor.EditMenuEntry page as indicated in the previous section and append the following JavaScript code to the end of the Code property:

require(['jquery'], function($) {
 var modifySectionEditLinks = function() {
   // Use the CKEditor for editing page sections.
   $('.edit_section > a').attr('href', function(index, oldHref) {
     return oldHref + '&editor=inline&sheet=CKEditor.EditSheet';
 if (window.XWiki && XWiki.domIsLoaded) {
  } else {
   // XWiki 6.4+
   require(['xwiki-events-bridge'], function() {
      $(document).on('xwiki:dom:loaded', modifySectionEditLinks);

If you're using the CKEditor Integration version 1.2 or older you also need to modify the CKEditor.EditSheet page as indicated in this commit.

When Creating a Blank Page

When you create a page using the "Blank page" (or "Empty wiki page") type (template) you are redirected to the edit mode for that page. In order to use the CKEditor in this case, instead of the default WYSIWYG editor, you need to import the application-ckeditor-blank-page.xar file.


Get Connected