There should be some guarantee at plugin loading order

[Martin Kou]

The iframedialog plugin is now having to use onLoad to load its code because the plugin system is always loading iframedialog first, running iframedialog's init() first, and even running iframedialog's onLoad() first.

So far we've been able to get iframedialog plugin to load correctly with the onLoad() hack. But if someone else's plugin needs the iframedialog plugin to be loaded before loading theirs, they'll have to find some even dirtier ways to do it. The requires array in plugin definition doesn't help here.

This situation is clearly not sustainable. We'll need to find some way of guaranteeing the loading order of plugins based on their dependencies. If that's not possible, we should at least guarantee the calling order of some of their initialization functions.

[Martin Kou]

With [topological sorting ​http://en.wikipedia.org/wiki/Topological_sorting], it should be possible to guarantee the init() or onLoad() functions of plugins being required are called before the corresponding functions at the current plugin. i.e. if I have a plugin like this...

CKEDITOR.plugins.add( 'myPlugin', { requires : [ 'iframedialog' ], ... } );

and then the iframedialog subsequently requires the dialog plugin, then it should be guaranteed that the dialog plugin is initialized first, then iframedialog, and finally myPlugin - no matter how they're ordered in the config.plugins string.

Currently, plugins the appear in the config.plugins string are first loaded according to the order they appear; then, the first level of required plugins that didn't appear in the config.plugins list are loaded; after that, the second level of required plugins (i.e. those required by the first level) are loaded; the process repeats itself until there's no more required plugin that hasn't been loaded.

[Frederico Caldeira Knabben]

That's ok, and we could even consider implementing something that executes "init" in the dependency order. But, this is not a bug. The requires property is there to indicate that other plugins are to be loaded, not to be executed in a specific order.

Currently, to avoid execution order issues, we don't need hacks. It's possible to use the "beforeInit" and "afterInit" properties. When plugins are loaded, "beforeInit" is called for all plugins, then "init" and finally "afterInit". Plugins that are known to be used by others, like "iframedialog", should use "beforeInit" for its initialization stuff.

[Frederico Caldeira Knabben]

I would avoid having adding code that we don't really need right now, and we're not talking about a couple of lines here.

Can the "iframedialog" issue be fixed by other means, as explained in my previous comment?

[Frederico Caldeira Knabben]

There are also a few other problems here:

• I'm not sure we can rely on object properties to guarantee the order. It looks like a buggy point.

• A much simpler solution can definitely be found.

[Garry Yao]

Reference patch

[Garry Yao]

Proposing a simplified way to guarantee plugins methods been executed in dependency order, it should have almost same result as topology sorted algorithm.

[Frederico Caldeira Knabben]

Milestone CKEditor 3.x deleted

[xmo]

Noting that I encountered this issue: I didn't see any note that dependencies had no impact on loading order (only on plugins being loaded at all) and thus expected them to be (I believe this to be a reasonable expectation when dependencies have to be specified).

My context was having a plugin B alter/extend a plugin A (actually extending two different plugins but that's not a big issue), plus said plugin already uses afterInit so that's no help.

(bypassed the problem by reimplementing the behavior I needed from the old "base" plugins in the new one after tracking down the disappearance of topological sorting somewhere deep in the bowels of ckeditor's resources loading)

[Frederico Caldeira Knabben]

@xmo, for now, you may give a try to the ​pluginsLoaded event. Not a solution I know, but a good workaround.