editor, pagemanager, filebrowser, editmenu -> option list
editor, pagemanager, filebrowser, editmenu -> option list
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.
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.
Re: editor, pagemanager, filebrowser, editmenu -> option lis
Yes.svasti wrote:Wouldn't it be user friendly to have
editor, pagemanager, filebrowser, editmenu
set via an option list?
I'd rather employ a function for this instead of a global variable, because a function is more abstract and flexible.svasti wrote:Maybe plugins would need an extra variable like $plugintype="editor" or "pagemanager" etc., so that the option list could be filled.
Let's analyse the existing plugins:svasti wrote:As there are not so many developers active, there is a good chance to agree on something like this.
- editors: TinyMCE(4) (manu), CKeditor (Holger), Codeeditor (myself)
- pagemanagers: Pagemanager (myself), Menumanger (svasti/Holger)?
- filebrowser: Filebrowser (Core), KCFinder (Holger), Ajaxfilemanager (myself)
- editmenu: -
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.
Christoph M. Becker – Plugins for CMSimple_XH
Re: editor, pagemanager, filebrowser, editmenu -> option lis
Yep, good idea!svasti wrote: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.
+1. Any ideas? ...cmb wrote:I'd rather employ a function for this instead of a global variable, because a function is more abstract and flexible.
... 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...
Re: editor, pagemanager, filebrowser, editmenu -> option lis
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.)Holger wrote:+1. Any ideas? ...cmb wrote:I'd rather employ a function for this instead of a global variable, because a function is more abstract and flexible.
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").Holger wrote:Ok for 2.0 I'd like to have a XH_RegisterPlugin() - function , which handles all plugin-information.
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 wrote: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...
Christoph M. Becker – Plugins for CMSimple_XH
Re: editor, pagemanager, filebrowser, editmenu -> option lis
Sounds good.cmb wrote: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.)
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 wrote: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).
Re: editor, pagemanager, filebrowser, editmenu -> option lis
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. )Holger wrote: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.
Christoph M. Becker – Plugins for CMSimple_XH
Re: editor, pagemanager, filebrowser, editmenu -> option lis
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?
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?
Re: editor, pagemanager, filebrowser, editmenu -> option lis
IMO it's better to open a new thread for that (no need to hurry, though ).manu wrote: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?
Christoph M. Becker – Plugins for CMSimple_XH
Re: editor, pagemanager, filebrowser, editmenu -> option lis
+1cmb wrote: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.)
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.
Re: editor, pagemanager, filebrowser, editmenu -> option lis
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.manu wrote: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.
Christoph M. Becker – Plugins for CMSimple_XH