Disabling/enabling plugins

[Holger]

Same procedure as with filebrowser and pagemanager

Hmm. Not really. Because there is already a plugin named "pluginloader" in the plugins-folder - but today only with language-files.
The pluginmanager-plugin is like a "delete-folder-plugin" for the filebrowser .

and: "I did it my way"

Ok, that's true .

The most work was the "polished backend" (the admin.php) of Pluginmanager_XH.

I meant the most work at runtime - not your work. Anyway - where is the problem to move that code to /pluginloader/admin.php???

That might be much easier

You should read a bit more careful my suggestions. "Easier" was not assigned to your radio-buttons. It was assigned to use $cf and config.php for your configuration instead of reinventing the wheel with a txt-file and own read / write functions.
Using the existing functions of the PL to handle reading and writing data is IMO easier than writing similar new own functions. Isn't it?

Holger

[cmb]

Hi Gert, hi Holger, hi B,

Also I get any files that are in the root folder showing in the plugin list eg OLDindex.php where I renamed the original index.php

Oh, a stupid mistake in admin.php

There's still a minor issue: a file "plugins/readme" for example, will be reported as plugin.

And I thought about disabling standard plugins: it might be a nice feature, to be able to do so, at least for the ones that could be replaced: Pagemanager, Filebrowser, tinyMCE. So a user can try out an alternative (well, it's not really a problem to keep the others enabled, but anyway it's something to consider).

why not putting a admin.php to /plugins/pluginloader/
and a config.php to /plugins/pluginloader/config?

So the array with the disabled plugins can be stored in a $cf['pluginloader']['....'] - variable and you can use the default
functions of the PL to manage them - maybe with a polished backend like tinymce or ckeditor.

Indeed, a good idea! But if pluginloader/ would be handled as normal plugin, it would be necessary to load it at first though.

What can be easier than 2 radio buttons for every plugin

There already where some ideas about introducing some kind of typing to the core and pluginloader configuration (checkboxes, radiobutton, select etc.) This might be nice and unified way to handle things. OTOH: Pluginmanager_XH could be used as additional plugin to allow for a more userfriendly way to handle things.

Christoph

[Holger]

But if pluginloader/ would be handled as normal plugin, it would be necessary to load it at first though.

Why?
Anyway, that small change in /plugins/index.php should not harm.

I think the pluginloader should have an own admin.php, not only to disable plugins...

Holger

[Gert]

Also I get any files that are in the root folder showing in the plugin list eg OLDindex.php where I renamed the original index.php

There's still a minor issue: a file "plugins/readme" for example, will be reported as plugin.

In my (corrected) installation not.

And I thought about disabling standard plugins: it might be a nice feature, to be able to do so, at least for the ones that could be replaced: Pagemanager, Filebrowser, tinyMCE. So a user can try out an alternative

Alternative editors, pagemanagers and filemanagers are working furthermore, even if the user can't disable the standard plugins. Like it has been before.

I think, it should not be possible to disable one of the standard plugins.

However, I have uploaded a modified download some minutes ago, there are the standard plugins visible, but you can't disable them. They are marked as Standard Plugins. But you can access the backends of the plugins by Pluginmanager.

!!! FOR TESTING PURPOSES ONLY - use with caution !!! (for CMSimple_XH 1.5.3 only)

Download beta04 (new): http://www.ge-webdesign.de/cmsimple/dlc ... php?id=376

I think, all is very comfortable, clear and understandable now,

Gert

[Gert]

Using the existing functions of the PL to handle reading and writing data is IMO easier than writing similar new own functions. Isn't it?

I have used code from my other plugins, storing data in data files from a nice backend (TemPlug_XH, FotoGalerie_XH) - was very easy to adapt it. As I wrote: I did it my way

Gert

[Holger]

As I wrote: I did it my way

It's no problem doing it your way - as long it is just a third-party-plugin with hacked core-parts.
But when there are plans for putting that to the main distribution, I'll suggest doing it the usual CMSimple-way.

[cmb]

Hi Holger, hi Gert,

But if pluginloader/ would be handled as normal plugin, it would be necessary to load it at first though.

Why?

If another plugin is loaded before the pluginloader, the pluginloader couldn't disable the plugins, if it would be the responsibility of pluginloader/admin.php, what seems quite natural to me. OTOH: the code to disable the plugins might remain in plugins/index.php.

There's still a minor issue: a file "plugins/readme" for example, will be reported as plugin.

In my (corrected) installation not.

Yes, indeed. Don't know what happened when I tested this with the earlier beta04.

I think, all is very comfortable, clear and understandable now,

Yes, it is! But I'm not too happy with the allocation of the code. Currently the filename of disabled_functions as well as the file file format are hardcoded in the pluginloader, but it's still possible to uninstall Pluginmanager_XH. So somebody might consider to write an alternative Pluginmanager, but to keep it fully integrated, he has to name it "pluginmanager". This might result in some confusion. So I think it's better to either integrate Pluginmanager_XH even more tightly (as Holger suggested), or to couply it more loosely, as done with Pagemanager_XH for example. I would prefer the latter ("Infinite Diversity in Infinite Combinations" ), but probably that's hard to accomplish, so the former solution might be best.

Christoph

[Gert]

Hehe, the one wants a fully integrated solution (Pluginloader), the other one wants "Infinite Diversity in Infinite Combinations"

I don't think, that CMSimple_XH needs several options, just to enable/disable plugins.

With the Pluginmanager_XH it is the same as with Subsites: CMSimple_XH works as before with the modifications of cms.php and index.php of the pluginloader, even if Pluginmanager_XH is not installed, where is the problem?

Gert

[cmb]

Hi Gert,

I don't think, that CMSimple_XH needs several options, just to enable/disable plugins.

No, of course not. And it might not need the choice between several editors, filebrowsers and possibly pagemanagers too. But it seems some users are quite happy with having the choice.

And a pluginmanager could facilitate more than just disabling plugins: displaying their version number, perhaps even create a preformatted list of info about the installed plugins to post it here in the forum, if the need arises; displaying a short description (perhaps an icon) as done in CMSimple SE; checking if an update is available (and give perhaps links to available translations). And I'm quite sure, that others might find further interesting possibilities. But of course, all this could be added to the Pluginmanager, or done by another plugin.

With the Pluginmanager_XH it is the same as with Subsites: CMSimple_XH works as before with the modifications of cms.php and index.php of the pluginloader, even if Pluginmanager_XH is not installed, where is the problem?

But Subsites is no plugin! And IMO it's not reasonable to make changes to the core, just to use a particular plugin. It might result in an accumulation of special handling for several plugins: Advancedsearch and Coco could make good use of a hook for the search function to include their own search.php, so the user can disable these plugins without the need to copy the original search.php back to cmsimple/. Pdeditor_XH could increase it's usability by far, if it were called after all other plugins, so it could display the pagedata tabs instead of simple inputs.

Consider the current situation: AFAIK no other standard plugin required changes to the core only for this particular plugin, let alone that a language string of the plugin is used in the pluginloader or that the plugin is linked from the core. That would be an innovation.

Christoph

[Gert]

And IMO it's not reasonable to make changes to the core, just to use a particular plugin.

There is no problem to set $cf['pluginmanager']['external'] and use it in the core files instead "pluginmanager" ...

let alone that a language string of the plugin is used in the pluginloader ...

The language string can be moved to the pluginloader ...

... or that the plugin is linked from the core. That would be an innovation.

Filebrowser is linked from the core, pagemanager is linked from the core ... I don't understand ...