customConfig conflicts with other CKEDitor instance customConfig

[julkue]

Type of report

Bug

Provide detailed reproduction steps (if any)

I'm using Pimcore as Content Management System, which implements CKEditor as their WYSIWYG editor for rich text fields. It allows specifying a customConfig file (Reference) for each field, which will be passed to CKEditor. This is a follow-up from pimcore/pimcore#1124 since Pimcore mentioned that the following bug is related to CKEditor itself.

In the backend interface, where users can edit fields using CKEditor, I have several different fields on one page, all with an individual CKEditor instance and sometimes with different configuration files (customConfig).

Imagine the following situation:

One instance of CKEditor for field A with the following custom config file contents (acutally doesn't matter, it's just differently to the other field below):

CKEDITOR.editorConfig = function(config) {
  config.enterMode = CKEDITOR.ENTER_BR;
  config.shiftEnterMode = CKEDITOR.ENTER_BR;
  config.autoParagraph = false;
  config.removeButtons = 'Form,Checkbox,Radio,TextField,Textarea,Select,Button,HiddenField,Anchor,Image,Flash,Table,HorizontalRule,Smiley,SpecialChar,PageBreak,Iframe,Format,Font,FontSize,Styles,About,NumberedList,BulletedList,Outdent,Indent,CreateDiv,JustifyLeft,JustifyRight,JustifyBlock,BidiLtr,BidiRtl,JustifyCenter,Language,Link,Unlink,Anchor,Image,Flash,Table,HorizontalRule,Smiley,Iframe,PageBreak,Blockquote';
  config.disallowedContent = 'a';
};

Then another instance of CKEditor for field B with the following custom config file contents (acutally doesn't matter, it's just differently to the other field above):

CKEDITOR.editorConfig = function(config) {
  config.removeButtons = 'Image';
  config.disallowedContent = 'img';
};

And finally, another CKEditor instance for field C with the exact same custom config file like field A.

Now, in this case field C should have the exact same toolbar like field A, because they are referencing to the same customConfig file. But because field B - with a separate CKEditor instance - is rendered between those two fields, with a different configuration, field C and any subsequent CKEditor instance gets the configuration of field B - the wrong configuration.

So, just to visualize the issue, this is the toolbar for field A:

In this screenshot you can also see field B ("Content"), which has a different customConfig.

And this is the config for field C:

In this screenshot you can see that field C get's a the wrong toolbar, it should look like field A.

Expected result

A CKEditor instance should always use the provided customConfig.

Actual result

When mixing several CKEditor instances with different customConfig files, CKEditor uses the wrong configuration.

Other details

• Browser: Firefox (latest, 70)
• OS: Windows 10
• CKEditor version: 4.11.2
• Installed CKEditor plugins: None

[Comandeer]

Fixing this bug can be tricky as currently all loaded configuration is de facto global. We will need to find the way to limit configuration just to the one editor's instance.

[julkue]

@Comandeer Thanks for your reply and the confirmation. I personally see e.g. the following options:

• The property customConfig accepts an object, e.g. {file: '/xyz.js', 'function': 'theName'} whereas function would be the function that CKEditor tries to call, similar to jsonp. This allows configuring different function names per instance, replacing CKEDITOR.editorConfig – these functions would then also receive config as parameter like today
• Switching to JSON, so loading a JSON file instead of a JS File. Since the file can be read directly by CKEditor, it can handle it directly. This, however, removes the ability to configure JS functions, which I think can't be an option

What do you think?

[shaselboeck]

We also need a solution if we use several modules on one side, each using a WYSIWYG editor.

[Wirsing84]

We urgently need a fix for this in our CMS landscape, otherwise we must consider moving to an alternative to CKEditor

+1

[f1ames]

@julmot @shaselboeck @Wirsing84, thanks for your input, we will be looking into this issue in the upcoming weeks and hopefully will be able to come up with a reasonable solution here.

[jacekbogdanski]

Closed in #4173