Opened 9 years ago

Last modified 9 years ago

#12383 confirmed New Feature

Custom config file loading order

Reported by: Sheldmandu Owned by:
Priority: Normal Milestone:
Component: General Version:
Keywords: Cc:


Hi guys, may I suggest changing the loading order of custom config files (using the customConfig parameter) to what would make more sense and follow the concept of inheritance from generic to more specific.

At present the config defined in any config js file is overridden by config defined in any config js file imported using the customConfig parameter. All of this is then overridden with in-page config.

It would be much more logical and practical to slightly modify the config loading order so that config defined in any config js file referenced from the current config is loaded first and then overridden by the config in the current context.

This would allow chaining config files with more specific config overriding more generic config defined in imported files.

For example consider the following scenario: In-Page Config customConfig: 'product_description_editor_config.js' ...

product_description_editor_config.js customConfig: 'generic_description_editor_config.js' ...

generic_description_editor_config.js customConfig: 'common_editor_config.js' ...

product_summary_editor_config.js customConfig: 'generic_summary_editor_config.js' ...

generic_summary_editor_config.js customConfig: 'common_editor_config.js' ...

common_editor_config.js customConfig: ...

As it stands the configuration defined in common_editor_config.js would override any config defined in generic_description_editor_config.js which would in turn override config defined in product_description_editor_config.js.

All of this would then be overridden with what's defined in in-page config.

This limits a developers ability to chain and override configuration in much the same way as they would in CSS or object inheritance. This basically means you can only define configuration in common_editor_config.js that's not going to override any other config in the the config js files that reference it, which significantly limits the use of being able to chain config files.

May I suggest that the loading order is reversed so that config defined in files referenced using customConfig parameter is loaded first and then overridden by config in the file that has the customConfig parameter.

I understand that this may be a breaking change for some people who upgrade, but given the current limited use of overriding, I think the impact will be minimal.

Change History (3)

comment:1 Changed 9 years ago by Sheldmandu

Hi guys, I've had a look at the source and it seems the changes would be limited to loadConfig function in editor.js. However, due to the current design it looks like the change will be somewhat tricky and would require the design of the whole function to be reconsidered.

Given the current design with the customConfig being overridden when the function assigned to the editorConfig being called, the simplest way may be to also add the functions to an array in the scriptLoader.queue callback function and then call the functions again recursively in reverse order once the last one is reached with a new reloadConfig(index) function, which would then fire the customConfigLoaded event once the index gets back down to 0.

comment:2 Changed 9 years ago by Piotrek Koszuliński

Status: newpending

I posted my reply in

I'll wait for Frederico's opinion, but I would say that both options are wrong - that we do now and that what you proposed.

comment:3 Changed 9 years ago by Piotrek Koszuliński

Keywords: config loading order removed
Status: pendingconfirmed

Based on very interesting discussion in the thread I linked in comment:2, I confirm this ticket. Inheritance would make much more sense than extension.

However, this is too far in 4.x branch, so it's unlikely that we are going to work on this issue, especially that in CKEditor 5 the feature may be gone completely.

Note: See TracTickets for help on using tickets.
© 2003 – 2022, CKSource sp. z o.o. sp.k. All rights reserved. | Terms of use | Privacy policy