Disabling/enabling plugins

[cmb]

Hi Gert,

Filebrowser is linked from the core, pagemanager is linked from the core

Not directly. The link to "Pages" is "&xhpages", the links to the filebrowser are "&images", "&downloads" etc. So other plugins can hook up on that, as it's not bound to the plugins name. But this could be solved with your suggestion:

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

The language string can be moved to the pluginloader ..

I would welcome that.

But after all: it might be senseless to have (alternative) pluginmanagers with additional features (as displaying version information), if no common agreement could be found, how the plugins will make this information available. See e.g. CMSimple SE: AFAIK no plugin author except Jens put a preview.htm/preview.png to his plugins.

Christoph

[bca]

As a relative novice at development perhaps i am looking at this with novice's eyes.

As i see it all we need is a link in the backend to a plugins page(not the drop down menu) with:
1. a simple tick box to enable and disabled plugins
2. a link to the plugin's setup/admin page and
3 .a Plugin Install/Add button

Is that too Simple?


B

[Gert]

Hi bca,

Pluginmanager_XH is a Pluginmanager, not an Plugininstaller.

1. and 2. the Pluginmanager_XH can do, 3. not.

For 3. the plugins directory would have to be writable, and that's not what I want,

Gert

[bca]

Hi Gert

Yes I appreciate all that. I was not making a comment about your PluginManager_XH, I was just making a general point about the concept.

With regard to installing/deleting a plugin - doesn't that come under Management?

B

[Gert]

With regard to installing/deleting a plugin - doesn't that come under Management?

Maybe - but the Pluginmanager_XH is not able to do that at the moment, but it's just 2 days old, it's still a baby

Gert

[cmb]

Hi B, hi Gert,

For 3. the plugins directory would have to be writable, and that's not what I want,

+ 1

IMO all installation/deinstallation has to be done via FTP. This is quite possible with PHP on the server too, but that would require the user to enter his FTP account data somewhere on the server (or to send them via HTTP). I have some concerns, that this might be a security hole. If somebody hacks a CMSimple installation that's bad -- but if somebody hacks an FTP account that's even worse!

So I would prefer a client side installer sometimes in the future, which will communicate exclusively via FTP.

Christoph

[cmb]

Hello,

I've made an alternative draft, which I've called pluginadmin. The basic idea was to change as less as possible in the core and pluginloader, to be able to use alternative plugin managers.

This variant uses $cf['pluginmanager']['external'] too. But instead of hardcoding anything else in the core, it dispatches to the installed pluginmanager. In the pluginloader (line 169ff) it reads the file init.php of the plugmanager. Then it defines a function plugin_disabled() which dispatches to %PLUGINMANAGER%_disabled(). plugin_disabled() is checked to guard the inclusion of disabled plugins.

The part of the adminmenu, which displays the plugins, is completely outsourced to the pluginmanager (%PLUGINMANAGER%_pluginmenu()). This way the pluginmanager has even more flexibility than just disabling plugins. I implemented the possibility to categorize plugins, so plugins in the same category are shown in a submenu (this way plugins, that are not so important for the end-user, could be put away, and it's possible to install many plugins, and call them directly from the pluginmenu). Besides this the pluginadmin has no separate entry in the pluginmenu, but is available via "Plugins" directly.

Note that it's a development preview, so don't use it in a production environment.

Download and unzip the package, and upload the files to a test installation (or even better test it on your localhost) in the root directory. You can change the categories in plugins/pluginadmin/data/categories.dat.

Christoph