Situation around plugin (de-)activation in preferences

uli · 2018-03-23 13:23:40

Currently I’m troubleshooting some things with active/inactive plugins and notice that—though plugins are de-activated in preferences—I’m getting a list of active plugins displayed in Diagnostics. This is not helpful because

It’s not true, they’re activated, at best
Reading this is irritating/misleading while in the troubleshooting process, not only for less proficient Textpatterners
It brings wrong information to the forum for getting troubleshooting help

Now, while plugins are de-activated via prefs, you’re not informed about this situation in the plugins panel. Usually plugins will be de-activated/re-activated there, so if you forget about your previous proceedings in the preferences and then look after “not working” plugins, you’ll go to the Plugins panel and see: “Yes, the darn things are active. So why doesn’t it work?” An indicator could help here, informing that plugin use is turned off generally or turned off for admin side plugins.

Which brings me back to the preferences for admin side plugins: In my understanding, this setting might be invisible or greyed out with “Allow plugins” set to No. That would make the situation there a little more self-explaining/less error prone.

Bloke · 2018-03-23 13:32:43

Umm, wot?

How do you deactivate a plugin from the Preferences panel? You can only activate and deactivate them from the Plugins panel (or from ied_plugin_composer, but that’s broken right now for 4.7.0).

When a plugin is deactivated it’s prefs should disappear from the Preferences panel. I’ve broken smd_article_stats in recent commits so I need to fix that. But on the whole, plugin prefs should only be active if the plugin is active as dictated by the Yes/No on the Plugins panel.

EDIT: Hang on, just got what you’re talking about.. the global admin-side plugins on/off toggle in prefs. Sorry. Let me investigate!

Last edited by Bloke (2018-03-23 13:33:29)

uli · 2018-03-23 13:34:33

I mean the general use of plugins, on the tab “Publish”.

Bloke · 2018-03-23 13:35:36

Yeah, got it sorry. I was being dim. Investigation in progress…

uli · 2018-03-23 13:41:18

Bloke wrote #310267:

You can only activate and deactivate them from the Plugins panel

So much about my remark “Usually plugins will be de-activated/re-activated there” ;)

Bloke · 2018-03-23 13:44:02

Yeah, I didn’t read properly. Mea culpa.

I’ve just been a little confused by the options actually:

Use plugins? really should read Use public-side plugins? because it only seems to affect those on the main site. Admin plugins still continue to run unless you turn off the Use admin-side plugins? toggle.

In either case, the Diagnostics panel should act accordingly. I’ll get it to take those settings into account. Thanks for the report.

uli · 2018-03-23 13:49:41

Thanks! What do you think about the ~~two other~~ last point?

An indicator in Plugins panel informing on deactivated plugins (Admin/Public) turned off from the prefs panel
~~Not listing active plugins in Diagnostics as long as plugins are deactivated globally~~

Edited because … see below

Last edited by uli (2018-03-23 13:53:03)

uli · 2018-03-23 13:52:15

Bloke wrote #310271:

In either case, the Diagnostics panel should act accordingly.

Ah, missed that one.

uli · 2018-03-23 14:01:18

I/me wrote #310270:

So much about my remark “Usually plugins will be de-activated/re-activated there” ;)

Bloke wrote #310271:

Yeah, I didn’t read properly. Mea culpa.

No, didn’t want to underline any misunderstandings. I just see your line “You can only activate and deactivate them from the Plugins panel” as a proof for my theory that the Plugins panel is THE place for deactivating plugins, and hence there is a need for a hint on the Plugins panel informing on the global deactivation of plugins done from the prefs when that setting makes the use of plugins impossible.

Hm, have I been clear enough here?

Bloke · 2018-03-23 15:22:42

uli wrote #310274:

there is a need for a hint on the Plugins panel informing on the global deactivation of plugins done from the prefs when that setting makes the use of plugins impossible.

Yes, you’re right. We have the following options:

Some kind of banner or something on the Plugins panel that admin plugins, or public plugins, or both are deactivated globally.
An indicator alongside each plugin to show that plugins of this type are deactivated globally.
Some kind of other indicator for each plugin (dimmed? strikethrough?) that such plugins are not currently enabled globally (as distinct from still being enabled individually).
An indication of the plugin’s type via another column in the table. A possible option would be to indicate the global status here, maybe?

Not exactly sure how best to show this. Any better ideas?

The problem is compounded by the fact we technically have 6 “types” of plugin. And they’re (annoyingly) not easily accumulable in terms of internal representation.

To the layperson, we have “public” and “admin” but for plugin authors (and people debugging things) the full range of types is something that is potentially very useful information. Perhaps we should add that to the list of plugins on Diagnostics, alongside the (m) marker? I’ll probably do that.

Anyway, one thing that’s been bubbling away at the back of my mind for ages is that our plugins type designators are, quite frankly, crap. Here’s what we have:

0 = public : only on the public side of the website (default)
1 = public+admin : on both the public and admin side
2 = library : only when include_plugin() or require_plugin() is called
3 = admin : only on the admin side (no AJAX)
4 = admin+ajax : only on the admin side (AJAX supported)
5 = public+admin+ajax : on both the public and admin side (AJAX supported)

In terms of programming, that means an activated “admin-side” plugin is loaded:

a) On the public-side, unless it’s designated admin-only (type 3).
b) On the admin-side for regular panel actions.
c) On the admin-side for AJAX calls if it’s of type 4 or 5.
d) AND only check a, b, and c conditions if the Use admin-side plugins pref is set.

An activated public-side plugin is loaded:

a) On the public-side if its type is unset or 0.
b) On the public-side if its type is 5.
c) AND only check a and b conditions if the Use plugins flag pref is set.

Activated library plugins are never loaded autoamtically, only when explicitly called by other plugins.

What a mess!

We really need to unpick all this and introduce proper type flags, for example:

define('PLUGIN_TYPE_PUBLIC', 0x0008);
define('PLUGIN_TYPE_ADMIN', 0x0010);
define('PLUGIN_TYPE_LIBRARY', 0x0020);
define('PLUGIN_HAS_AJAX', 0x0040);

That system has the following properties:

No need for explicit values for each type combination, meaning fewer overall values.
Combinations can be specified more intuitively, e.g. PLUGIN_TYPE_PUBLIC | PLUGIN_TYPE_ADMIN | PLUGIN_HAS_AJAX means a public-side and admin-side plugin with Ajax support, equivalent to our current type ‘5’. Easy
All values are opt-in (unlike the current ‘public’ flag, which is 0 and can’t therefore be implied).
Much easier to parse and apply in code using bitwise operators.
The numbers are higher than the highest current value we have, which allows for a migration path from “crappy type numbers” to “proper flags” :-)

The trick is to figure out how to map the current system to the flags. If it’s not too much hassle, I might just do that now. If I put a translation function in place in our new Plugin class, that should suffice to make it backwards compatible but allow us to start using the new flags from 4.7.0. And, crucially, it’ll make it a truckload easier to filter them out by type on the Diagnostics panel.

Phew!

uli · 2018-03-23 16:00:49

Bloke wrote #310278:

Phew!

I certainly didn’t want to stir up as much as it seems it has become now.
But if things get better in the end …

We have the following options:

Some kind of banner or something on the Plugins panel that admin plugins, or public plugins, or both are deactivated globally.

An indicator alongside each plugin to show that plugins of this type are deactivated globally.

Some kind of other indicator for each plugin (dimmed? strikethrough?) that such plugins are not currently enabled globally (as distinct from still being enabled individually).

An indication of the plugin’s type via another column in the table. A possible option would be to indicate the global status here, maybe?

The first one is what I thought should be enough. That’s Textpattern style, like the current banner in the forum.

Then, having read the palette of options you mention, I think a mixture of your second and third point has merit. I’d find it sufficient when—in the Active column—the terms Yes/No were striked through. I see no need, though, to inform the user why a certain plugin is deactivated when s/he has a banner on top of the page with a generalized plugin type info.

Last edited by uli (2018-03-23 16:04:24)

Bloke · 2018-03-23 16:47:35

uli wrote #310279:

I certainly didn’t want to stir up as much as it seems now.

Well, it kinda needs doing anyway as it’s not very good.

I’m not entirely sure my initial thought on using the 4 status flags is enough as I don’t know if it’s easy to cater for extracting “admin only”. It’s not just accumulated logic, it’s pulling out rows that match public|admin|ajax but NOT just admin. Can that be done cleanly in bitwise logic when querying MySQL? I don’t know. My MySQL-fu wrt bitwise stuff is severely lacking.

I’d find it sufficient when—in the Active column—the terms Yes/No were striked through.

Yes, I like that. But I just thought of something. When Use plugins is ON and Use admin-side plugins is OFF, all plugins except those designated admin-only are still active on the public side.

So what exactly do we show as struck out? And what would we exclude from the Active plugins on Diagnostics? The only ones we know for sure that are not loaded are the “admin only” plugins. All others are on, unless you toggle Use plugins OFF. Only then would there be no active plugins running. And only if both prefs were off.

If Use plugins is OFF and Use admin-side plugins is ON, only those designated as ‘admin-only’ remain active.

The upshot is that only in the latter case would you ever see a few admin-side-only plugins available in the list, with everything else struck out. Any other combination of prefs would leave the list unaltered, and all plugins except admin-only active.

The bottom line is that all plugins are considered fair game on the public-site at all times regardless of their type. There’s no such thing as a “public-only” plugin. The only time their type is taken into consideration is for admin-only (well, and library plugins but they’re not loaded at all unless requested).

Last edited by Bloke (2018-03-23 16:50:40)

Textpattern CMS

Textpattern CMS support forum

#1 2018-03-23 13:23:40