XH 1.6.2 Disabled / hidden plugins

Discussions and requests related to new CMSimple features, plugins, templates etc. and how to develop.
Please don't ask for support at this forums!
Post Reply
Holger
Site Admin
Posts: 3470
Joined: Mon May 19, 2008 7:10 pm
Location: Hessen, Germany

XH 1.6.2 Disabled / hidden plugins

Post by Holger » Thu Feb 06, 2014 1:21 pm

Hi,

this time I'm working on a new backend-plugin which contains beside other things a "Plugin-Manager".
Disabling plugins could easy integrated by using $cf['plugins']['disabled'].
To hide plugins from the adminmenu I've planned to use JS on client side.
But IMO that's a bad and tricky solution when it comes to a plugin-menu with more than only one column.

So it comes in mind why not having a $cf['plugins']['hidden'] variable beside the disabled-option?
IMO that's useful and a "plugin-manager" must only provide the form to handle the variables (BTW: it's a pleasure to use the new API of 1.6 for this plugin :) ).
And a user can manipulate the plugins-menu without a additional plugin.

There are more possible ways to include that feature. On a first look, the final cleanup seems to be the easiest:

in function XH_finalCleanUp($html):
replace the line

Code: Select all

$adminMenu = call_user_func($adminMenuFunc, XH_plugins(true)); 
with something like this:

Code: Select all

global $cf;

$hiddenPlugins = explode(',', $cf['plugins']['hidden']);
$hiddenPlugins = array_map('trim', $hiddenPlugins); 

$plugins = array_diff(XH_plugins(false), $hiddenPlugins);

$adminMenu = call_user_func($adminMenuFunc, $plugins); 
Simple and easy. I'm not sure what you think about it but IMO it's like a little dirty hack.

So maybe the "cleanest" and most reusable way might be changing XH_plugins($admin = false)
to XH_plugins($staus = '').

The function should contain code to switch between the string in $satus:

case 'admin' : only active plugins with admin.php (as XH_plugins(true) now)
case 'visible' : all active plugins with admin.php and not contained in $cf['plugins']['hidden']
case 'all' : all installed plugins, active or not //just to be complete, maybe usefull for future extensions
default : only active plugins (as XH_plugins() now)

So in final_cleanup the code becomes

Code: Select all

$adminMenu = call_user_func($adminMenuFunc, XH_plugins('visible')); 
I know that the changed XH_plugins() causes some changes in the core, but the function is not so often called if I'm right.
If we decide to change XH_plugins() we should not wait too long, because the changes may cause incompatibilities in future extensions.
By now, I'm not aware about extensions using that function. But that might change soon.

Anyway, I'm fine with the first solution too.
What do you think?

cmb
Posts: 14225
Joined: Tue Jun 21, 2011 11:04 am
Location: Bingen, RLP, DE
Contact:

Re: XH 1.6.2 Disabled / hidden plugins

Post by cmb » Thu Feb 06, 2014 1:44 pm

Just some very quick thoughts for now.

Having the possibility to hide plugins from the menu seems very reasonable. We may consider to somewhat extend this, so a plugin does not need admin.php to be shown there in the first place. I've published already some plugins that have an empty admin.php, only to show up in the menu, while the actual administration is handled in index.php resp. classes/Controller.php. And there are meta_tags and page_params which have a fully working admin backend, but that's disabled by renaming their admin.php to _admin.php.

At least on the first glance, I would prefer to change XH_plugins() over adding more code to XH_finalCleanUp(), especially as the latter function is harder to debug (any further output is suppressed, as well as any notices/warnings after $errorList is built; even writing debug info to a file might not work as expected as the Apache SAPI resets the CWD).

Yet another possibility would be to use an own admin menu function ($cf[editmenu][external]). At least we have to consider what happens if a user uses this option.
Christoph M. Becker – Plugins for CMSimple_XH

manu
Posts: 1086
Joined: Wed Jun 04, 2008 12:05 pm
Location: St. Gallen - Schweiz
Contact:

Re: XH 1.6.2 Disabled / hidden plugins

Post by manu » Thu Feb 06, 2014 3:19 pm

What's the main benefit, Holger, to put more complexity into it? Is it just the wished drop down plugin menue?
At the moment it's plain simple:
If you have to manage config / language / backend functions, just place an admin.php there. When there isn't, nothing shows up.
$cf['plugins']['disabled'] is really handy if you want to test a new plugin version: rename the old one, install the new one, if tests are ok, delete the old one.
But perhaps I probabely overlook something?
regards
manu

cmb
Posts: 14225
Joined: Tue Jun 21, 2011 11:04 am
Location: Bingen, RLP, DE
Contact:

Re: XH 1.6.2 Disabled / hidden plugins

Post by cmb » Thu Feb 06, 2014 4:04 pm

manu wrote:$cf['plugins']['disabled'] is really handy if you want to test a new plugin version: rename the old one, install the new one, if tests are ok, delete the old one.
In this case I would simply prefix the folder of the old version with a dot, e.g. pagemanager/ -> .pagemanager/. :)
Christoph M. Becker – Plugins for CMSimple_XH

Holger
Site Admin
Posts: 3470
Joined: Mon May 19, 2008 7:10 pm
Location: Hessen, Germany

Re: XH 1.6.2 Disabled / hidden plugins

Post by Holger » Thu Feb 06, 2014 9:49 pm

manu wrote:What's the main benefit, Holger, to put more complexity into it? Is it just the wished drop down plugin menue?
At the moment it's plain simple:
If you have to manage config / language / backend functions, just place an admin.php there. When there isn't, nothing shows up.
It seems there is some misunderstanding.
I'm not interested bringing much more complexity into sth. The main benefit is to provide a plugin-manager which makes it easy possible to
- deactivate a plugin
- to hide a plugin in the dropdown-menu (while keeping admin.php loaded) - just to keep the menu small or to hide some configurations from the user

As there had been some hot discussions in the past about that and such a pluginmanager seems to be a key-feature in CMSimple4, I thought it is a good idea to code such a tool. I'm aware about the possibilities to deactivate a plugin or to hide it's entry, but thinking on the old discussions, it seems to be some "often wanted" feature doing that with an easy to handle form.
From my personal view, I don't need it and - to be honest - I can't remember that there had been really much requests by the users.
But anyway, with 1.6 it's easy possible to do - and much easier with small changes in the core.
manu wrote:If you have to manage config / language / backend functions, just place an admin.php there. When there isn't, nothing shows up.
So you can rename the admin.php to hide a plugin. But the functions there won't be available any more. I bet that a lot of plugins will break with that solution.
manu wrote:$cf['plugins']['disabled'] is really handy if you want to test a new plugin version
$cf['plugins']['disabled'] is complete useless in regard to this topic, because the new version will have the same foldername. So the easiest way is just renaming the folder (.v1-plugin, .v2-plugin, .v3-plugin, ..., plugin) and prepend a dot to the name to prevent loading the plugin.
cmb wrote:Yet another possibility would be to use an own admin menu function ($cf[editmenu][external]). At least we have to consider what happens if a user uses this option.
Thought about that too. But at the end it will be a dirty copy of the original with the problem to restore the screen-offset. Much code for nothing. And BTW, im fine with the original menu.

The general question is: is that additional $cf-var acceptable and the feature useful in general?

As I said above: all of this is "nice to have" but for my personal usage even $cf['plugins']['disabled'] is not a "must be" and could be removed.
Some users might see things from another POV...

@cmb:
my code above seems not to be the easiest way. Everything will work, if we just change function XH_adminMenu(), because $cf['plugins']['hidden'] is only useful there :
insert before line:

Code: Select all

$total = count($plugins);
the following code:

Code: Select all

$hiddenPlugins = explode(',', $cf['plugins']['hidden']);
$hiddenPlugins = array_map('trim', $hiddenPlugins);
$plugins = array_diff($plugins, $hiddenPlugins);
and make $cf global in the function.
No further changes are necessary. And if $cf['plugins']['hidden'] is given, it'll work out of the box.

I'm still not sure if it's better or necessary to change XH_Plugins(). But if so, it'll be the best just to add one more argument to the function. But it seems that will not work, because the parser ignores more arguments after the first "false" is passed to the function :cry: .

But anyway, it's fine with me to change nothing, then hiding has to be done with JS...

cmb
Posts: 14225
Joined: Tue Jun 21, 2011 11:04 am
Location: Bingen, RLP, DE
Contact:

Re: XH 1.6.2 Disabled / hidden plugins

Post by cmb » Thu Feb 06, 2014 11:13 pm

Holger wrote:As there had been some hot discussions in the past about that and such a pluginmanager seems to be a key-feature in CMSimple4
At least, it seems that the discussion about whether to add a pluginmanager to CMSimple_XH or not caused the forking of CMSimpleCoAuthors (surely the feature that gave its name was more crucial, though, and most likely there were other reasons). However, the main benefit of the plugin manager in CMSimple v4 seems to be related to the new subsite feature, where each subsite can have disable undesired plugins.

Anyway, having more features seems always to be a good thing, at least if these features are offered as plugins, so they don't encumber any user who doesn't like or need them. So I'm all for having a plugin manager. And actually, some kind of plugin management is quite customary these days in other applications, for instance, browsers. The plugin manager might be extended with additional features, and maybe eventually replace parts of the current plugin administrations in the future (most notably the "info" screen).
Holger wrote:
cmb wrote:Yet another possibility would be to use an own admin menu function ($cf[editmenu][external]). At least we have to consider what happens if a user uses this option.
Thought about that too. But at the end it will be a dirty copy of the original with the problem to restore the screen-offset. Much code for nothing. And BTW, im fine with the original menu.
ACK. However, that could be a temporary workaround, iff we decide to postpone changes to the core for 1.6.2.
Holger wrote: Everything will work, if we just change function XH_adminMenu(), because $cf['plugins']['hidden'] is only useful there:

Code: Select all

[/quote]
ACK. It would be useful for other admin menu plugins, but even if there'll be any, these can easily split $cf[plugins][hidden] for themselves. Surely not the cleanest API, but (a) quite inline with the tradition and particularly $cf[plugins][disabled], and (b) perhaps better than complicating the parameter of XH_plugins(). 

[quote="Holger"]I'm still not sure if it's better or necessary to change XH_Plugins(). But if so, it'll be the best just to add one more argument to the function. But it seems that will not work, because the parser ignores more arguments after the first "false" is passed to the function.[/quote]
Well, that is, because optional arguments have to come after mandatory arguments, so the second parameter has also to be optional, and respectively the $admin argument has to be given even when false, if the second argument is passed. BTW: there is an [url=https://wiki.php.net/rfc/named_params]RFC for named parameters[/url] which might be implemented in PHP 5.6, which would offer a solution -- we'd have to wait some years to be able to make use of it, though. ;)

Is it already on the roadmap?
Christoph M. Becker – Plugins for CMSimple_XH

manu
Posts: 1086
Joined: Wed Jun 04, 2008 12:05 pm
Location: St. Gallen - Schweiz
Contact:

Re: XH 1.6.2 Disabled / hidden plugins

Post by manu » Fri Feb 07, 2014 10:20 am

cmb wrote:
manu wrote:$cf['plugins']['disabled'] is really handy if you want to test a new plugin version: rename the old one, install the new one, if tests are ok, delete the old one.
In this case I would simply prefix the folder of the old version with a dot, e.g. pagemanager/ -> .pagemanager/. :)
Gosh, it's that easy! Coming from win I didn't have this idea. And it even works on XAMPP (say win Servers?), perfect!
@Holger: Never mind. I was in a hurry yesterday. I missunderstood you would rewrite the plugin loader. Now I understand, a plugin manager. And for keeping this modular you need the "visible" property. Aaah, a nice idea, my mind is a bit slow. And with this we could have all the "hidden/disabled/etc." controls remote in your plugin. And in the plain core code there would be the" preceeding ." solution to disable a plugin. A nice idea.
regards
manu

cmb
Posts: 14225
Joined: Tue Jun 21, 2011 11:04 am
Location: Bingen, RLP, DE
Contact:

Re: XH 1.6.2 Disabled / hidden plugins

Post by cmb » Fri Feb 07, 2014 11:49 am

manu wrote:Coming from win I didn't have this idea. And it even works on XAMPP (say win Servers?), perfect!
Well, the plugins/ folder is traversed by opendir()/readdir(), and as this will return the current (.) and the parent directory (..) these have to be stripped out. Before XH 1.6 that has been done by (simplified):

Code: Select all

if ($dir != '.' && $dir != '..') { 
I found the following to be simpler, faster and having the nice side-effect:

Code: Select all

if ($dir[0] != '.') { 
I can imagine that similar reasoning made *nix use the dot-prefix for hidden files and folders.

PS: Note, that adding a dot-prefix is somewhat different to disabling a plugin via the configuration. For instance, disabling jQuery in the configuration will disable any access to the plugin administration and ignore the autoload setting, but other plugins (such as Pagemanager) will still be able to use it. Renaming the folder will break those other plugins.
Last edited by cmb on Fri Feb 07, 2014 12:01 pm, edited 1 time in total.
Reason: added PS
Christoph M. Becker – Plugins for CMSimple_XH

cmb
Posts: 14225
Joined: Tue Jun 21, 2011 11:04 am
Location: Bingen, RLP, DE
Contact:

Re: XH 1.6.2 Disabled / hidden plugins

Post by cmb » Tue Feb 11, 2014 10:51 am

cmb wrote:Is it already on the roadmap?
Now it is. :)
Christoph M. Becker – Plugins for CMSimple_XH

cmb
Posts: 14225
Joined: Tue Jun 21, 2011 11:04 am
Location: Bingen, RLP, DE
Contact:

Re: XH 1.6.2 Disabled / hidden plugins

Post by cmb » Sat May 10, 2014 5:03 pm

Holger wrote:Everything will work, if we just change function XH_adminMenu(), because $cf['plugins']['hidden'] is only useful there
I have implemented this solution (r1274).
Holger wrote:I'm still not sure if it's better or necessary to change XH_Plugins().
Somehow that would be cleaner, because the list of plugins is passed as an argument to XH_adminMenu(). Sometime we may consider to either change XH_plugins() or to remove the $plugins argument form XH_adminMenu(), but IMHO there's no need to do that now.
Christoph M. Becker – Plugins for CMSimple_XH

Post Reply