editor, pagemanager, filebrowser, editmenu -> option list

[svasti]

Wouldn't it be user friendly to have

editor, pagemanager, filebrowser, editmenu

set via an option list? Users would only have to put a new e.g. editor into the plugins folder and the option list in Settings CMS would adjust itself.

Could be done? Maybe plugins would need an extra variable like $plugintype="editor" or "pagemanager" etc., so that the option list could be filled. As there are not so many developers active, there is a good chance to agree on something like this.

It would fit nicely into the new config concept.

[cmb]

Wouldn't it be user friendly to have

editor, pagemanager, filebrowser, editmenu

set via an option list?

Yes.

Maybe plugins would need an extra variable like $plugintype="editor" or "pagemanager" etc., so that the option list could be filled.

I'd rather employ a function for this instead of a global variable, because a function is more abstract and flexible.

As there are not so many developers active, there is a good chance to agree on something like this.

Let's analyse the existing plugins:

• editors: TinyMCE(4) (manu), CKeditor (Holger), Codeeditor (myself)
• pagemanagers: Pagemanager (myself), Menumanger (svasti/Holger)?
• filebrowser: Filebrowser (Core), KCFinder (Holger), Ajaxfilemanager (myself)
• editmenu: -

So currently there are only four devs involved, so an agreement should be achievable.

One minor problem we must not forget: if somebody writes another respective plugin that doesn't conform to this specification, it can't be selected (unless the user would edit metaconfig.php appropriately).

Anyway, you should put it on the roadmap.

[Holger]

Wouldn't it be user friendly to have
editor, pagemanager, filebrowser, editmenu
set via an option list? Users would only have to put a new e.g. editor into the plugins folder and the option list in Settings CMS would adjust itself.

Yep, good idea!

I'd rather employ a function for this instead of a global variable, because a function is more abstract and flexible.

+1. Any ideas? ...
... Ok for 2.0 I'd like to have a XH_RegisterPlugin() - function , which handles all plugin-information.

But right know?
The first thing come into my mind is a file (.xhEditor, .xhEditmenu ...) in the plugin root folder.
That won't break existing code.
OTOH why not break? All devs of those plugins are active at the moment...

[cmb]

I'd rather employ a function for this instead of a global variable, because a function is more abstract and flexible.

+1. Any ideas? ...

Off the top of my head: something like XH_registerPluginType($type, $plugin = null) which should be called during plugin loading (passing the second parameter). This stores the plugin/type in a static variable. Called without the second parameter, it will return an array of registered plugins for the $type. (An object is more elegant, though, but sticking with a function for now is quite inline with the rest of the current code, and works around PHP 4 limitations.)

Ok for 2.0 I'd like to have a XH_RegisterPlugin() - function , which handles all plugin-information.

I like that! There was a discussion quite a while ago about the plugin version only, but that didn't go anywhere. Hopefully, there'll be an agreement for XH 2.0. Anyway, I put it on the roadmap (preferably, there should be an own thread to discuss "the details").

But right know?
The first thing come into my mind is a file (.xhEditor, .xhEditmenu ...) in the plugin root folder.
That won't break existing code.
OTOH why not break? All devs of those plugins are active at the moment...

I agree that breaking existing code is quite acceptable in this case (actually, that shouldn't be much of a problem; AFAIK currently the only respective plugins that work with XH 1.6 are TinyMCE, Pagemanager and CKEditor -- only the latter is an "external" plugin, and there could be an update for XH 1.6.1).

[Holger]

Off the top of my head: something like XH_registerPluginType($type, $plugin = null) which should be called during plugin loading (passing the second parameter). This stores the plugin/type in a static variable. Called without the second parameter, it will return an array of registered plugins for the $type. (An object is more elegant, though, but sticking with a function for now is quite inline with the rest of the current code, and works around PHP 4 limitations.)

Sounds good.

I agree that breaking existing code is quite acceptable in this case (actually, that shouldn't be much of a problem; AFAIK currently the only respective plugins that work with XH 1.6 are TinyMCE, Pagemanager and CKEditor -- only the latter is an "external" plugin, and there could be an update for XH 1.6.1).

Ha, I'm about running the build-script for hi_KCFinder 2.0, which is compatible with (betters said "requires at the moment") XH 1.6. But that should not be a problem.

[cmb]

Ha, I'm about running the build-script for hi_KCFinder 2.0, which is compatible with (betters said "requires at the moment") XH 1.6.

Good news! (I have to admit that Ajaxfilemanager_XH is far from being compatible with XH 1.6---it's too much of a mess, internally. )

[manu]

Sounds all good to me.
A registerPlugin() could be achieved before 1.6.1., as we are just few.
I'm standby.

regards
manu

For 2.0 are there any thoughts about a general data store? A super object with all properties attached on?
Or should this be started in a new thread?

[cmb]

For 2.0 are there any thoughts about a general data store? A super object with all properties attached on?
Or should this be started in a new thread?

IMO it's better to open a new thread for that (no need to hurry, though ).

[manu]

Off the top of my head: something like XH_registerPluginType($type, $plugin = null) which should be called during plugin loading (passing the second parameter). This stores the plugin/type in a static variable. Called without the second parameter, it will return an array of registered plugins for the $type. (An object is more elegant, though, but sticking with a function for now is quite inline with the rest of the current code, and works around PHP 4 limitations.)

+1
Before to invent this, all developers have to admit and update their plugins in advance (with backwards compatibility). Then the (developer) documentation has to be updated properly. After all that is done, the core is ready for this improvement.

[cmb]

Before to invent this, all developers have to admit and update their plugins in advance (with backwards compatibility). Then the (developer) documentation has to be updated properly. After all that is done, the core is ready for this improvement.

That's a bit of a chicken-and-egg-problem. Until there is no API defined (at least specified, so a plugin developer can add it to his development environment), it is hard to make the change, as any modification to the API specification would break the new plugin version.