Textpattern CMS support forum

You are not logged in. Register | Login | Help

#11 2018-03-23 16:00:49

uli
Moderator
From: Cologne
Registered: 2006-08-15
Posts: 4,185

Re: Situation around plugin (de-)activation in preferences

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)


In bad weather I never leave home without wet_plugout, smd_where_used and adi_form_links

Offline

#12 2018-03-23 16:47:35

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 8,611
Website

Re: Situation around plugin (de-)activation in preferences

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)


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#13 2018-03-24 14:48:29

uli
Moderator
From: Cologne
Registered: 2006-08-15
Posts: 4,185

Re: Situation around plugin (de-)activation in preferences

I’ve read your post(s) several times, but for my graphic designer brain your considerations sound quite complicated, I can hardly follow. Additionally, what you’re aiming at seems too much for what Textpattern has represented throughout its existence.

My suspect is it might be easier to accomplish to switch off all plugin-use altogether with switch “a”, and with switch “b” turn off only admin side ones, so the website is running normally for the public. (Then, of course, hiding/graying-out switch b as long as switch a is ON.)

Then, on the Plugins panel, a banner should inform about the deactivated-in-prefs setting, be it a general or an admin-side deactivation.

On Diagnostics, an additional sentence might give an analogous hint to anyone reading that text.
To those only? Quite hard to spot.

Which brings in one more idea: It might be useful to indicate the plugin deactivation in each admin panel, so that the deactivation is not forgotten when the admin is sidetracked somehow.

Bloke wrote #310287:

There’s no such thing as a “public-only” plugin.

I think there’s nothing to misunderstand in this sentence, and you’ll have tested thoroughly. Yet it sounds hard to grasp to me that e.g. the many conditional plugins aren’t public-only.


In bad weather I never leave home without wet_plugout, smd_where_used and adi_form_links

Offline

#14 2018-03-24 20:34:54

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 8,611
Website

Re: Situation around plugin (de-)activation in preferences

uli wrote #310313:

what you’re aiming at seems too much for what Textpattern has represented throughout its existence.

Sorry if it’s confusing but that’s how Textpattern works now, and has worked since at least 4.0.7 (or whenever admin-only plugins were introduced, and probably before).

  • On the public site, both admin AND public plugins are always loaded UNLESS you set the Use plugins pref off.
  • On the admin-side, only admin-side plugins are loaded UNLESS you set the Use admin-side plugins pref off.

So, consider this:

  1. You turn OFF admin-side plugins (Use admin-side plugins in prefs). No Extensions panels appear, there are no extra plugin features on the admin side. Nothing plugin related runs at all.
  2. You visit the Diagnostics panel. It still shows that some plugins with admin-side components are active. Why? Because they are! Because if you visit the public site, they still run. They might have public tags defined in them.

The fact you’ve turned off the plugins on the admin-side does not affect their status on the public site. So what is showing on Diagnostics is correct. Although you might no longer be able to administer their settings, they are still technically active.

The only plugins that should not be shown on Diagnostics in this situation are the ones designated as “admin-only” (type 3). The fact they are still shown is a bug and we should hide them in this specific case.

Now consider this:

  1. You turn OFF public plugins (Use plugins in prefs). No public tags are available from any plugins.
  2. You visit the Diagnostics panel. It still shows that plugins with admin-side components are active. Why? Because they are! Because if you visit the admin side, they still run.

The only time you should see no plugins in the Diagnostics panel is if BOTH plugin-related prefs are off. That, again, is a bug and should be fixed, because currently they are listed as active.

My suspect is it might be easier to accomplish to switch off all plugin-use altogether with switch “a”, and with switch “b” turn off only admin side ones, so the website is running normally for the public. (Then, of course, hiding/graying-out switch b as long as switch a is ON.)

Yes, but this raises a backwards-compatibility issue. We’d have to work around it (by introducing a third pref and phasing out the old ‘Use plugins’ one). For now, we should probably just relabel them:

  • Allow plugins to run on the public site.
  • Allow plugins to run on the admin side.

it might be useful to indicate the plugin deactivation in each admin panel, so that the deactivation is not forgotten when the admin is sidetracked somehow.

No, sorry. The choice of not running plugins might be a conscious one on behalf of an admin. Maybe the site doesn’t need any. Or they’re disabled for security reasons. We shouldn’t nag people on every panel for something they might have chosen to do.

On the plugins panel, sure, a helpful indicator of which types are disabled might be handy. Similarly on the Diagnostics panel just before the list of “active” plugins, maybe. Beyond that, nothing.


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#15 2018-03-24 20:45:54

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 8,611
Website

Re: Situation around plugin (de-)activation in preferences

uli wrote #310313:

it sounds hard to grasp to me that e.g. the many conditional plugins aren’t public-only.

At the risk of making this more complicated than it is:

  • The plugin type (0-5) determines where it runs – public side (0) or admin side (3) or both (1). Ignore ‘Ajax mode’ for now, that’s a distraction.
  • Inside the plugin code, the author can do a check “Am I running on the public site? or “Am I running on the admin side?” and execute relevant code based on where it is running

It’s perfectly feasible to construct a plugin that is designated as “Admin” (type 1) – remember, this type really means “Both admin and public” but is poorly labelled – and have code inside it that is only executed if the plugin is running on the public site! It’s poor design and wastes processor cycles on the admin side to load a plugin that’s never used there, but it’s possible.

Likewise, you could construct a “type 1” plugin that has no public components, because you do an ‘if’ inside the code to detect only the admin-side case. Again, wastes cycles to load it on the public site, but it’s possible. It’s down to the plugin author to choose the appropriate type.

However:

  • it’s not possible to write a “type 0” plugin that runs on the admin-side. They are never loaded there.
  • it’s not possible to write a “type 3” plugin that runs on the public site. They are never loaded there.

How’s that?!


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

#16 2018-03-25 14:02:32

Destry
Moderator
From: Haut-Rhin
Registered: 2004-08-04
Posts: 4,144
Website

Re: Situation around plugin (de-)activation in preferences

+1

It has got more consideration here than it ever has up to this point.

I think what’s important for you, Stef, and probably what Uli is getting at, is: as devs, you have the diagnostics feedback written in the way that best gives you the information you need to troubleshoot a given persons problems when they share their diagnostics info.

One of those, ‘dev’s choice’ things.

How’s that‽ ;)


The text persuades, the *notes prove。

Offline

#17 2018-03-27 12:41:11

uli
Moderator
From: Cologne
Registered: 2006-08-15
Posts: 4,185

Re: Situation around plugin (de-)activation in preferences

Thanks, Stef, for your explanations.

The thing you seem to put most effort in ( = the considerations I didn’t understand—and all these consideration were probably addressing the dev team, not me), is listing all really active plugins, while I was just thinking of a simple remark inside the Diagnostics textarea like
Below plugins might be currently disabled via the plugin settings on Preferences > Publish
(and a similar banner in the Plugins panel, respectively)
Hence I was speaking of “too much”. But certainly your plan will be much more useful for the user and all people offering help in the forum, than were my simplistic idea.


In bad weather I never leave home without wet_plugout, smd_where_used and adi_form_links

Offline

#18 2018-03-27 12:47:28

etc
Developer
Registered: 2010-11-11
Posts: 3,106
Website

Re: Situation around plugin (de-)activation in preferences

uli wrote #310313:

it sounds hard to grasp to me that e.g. the many conditional plugins aren’t public-only.

A possible reason is that previewing unpublished articles happens on the admin side, which is a bit weird. So public-only tags wouldn’t be available in previews.


etc_[ query | search | pagination | date | tree | cache ]

Offline

#19 2018-03-27 12:57:24

uli
Moderator
From: Cologne
Registered: 2006-08-15
Posts: 4,185

Re: Situation around plugin (de-)activation in preferences

etc wrote #310402:

previewing unpublished articles happens on the admin side

Oh——K!


In bad weather I never leave home without wet_plugout, smd_where_used and adi_form_links

Offline

#20 2018-03-27 13:49:12

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 8,611
Website

Re: Situation around plugin (de-)activation in preferences

uli wrote #310401:

I was just thinking of a simple remark inside the Diagnostics textarea

Yes, and we may still do this (perhaps in 4.7.1 or later now, to save burdening translators with yet another new string). Not sure it’s entirely necessary but we’ll see what happens.

For now I’m just looking at the simplest option to denote that plugins on the Plugins panel are – or may be – deactivated globally. In reality this will only be possible for:

  • Type 0 (solely Public, if Use plugins is off).
  • Type 3 (solely Admin, if Use admin-side plugins is off).
  • Type 1 (public+admin IF both options are off in prefs).

On the Diagnostics panel, likewise. I will make it omit:

  • Type 0 if Use plugins is off.
  • Type 3 if Use admin-side plugins is off.
  • The entire list if both options are off.

Beyond that, we’ll worry about using a proper system of flags, perhaps something like I mentioned above, in another version.

etc wrote #310402:

previewing unpublished articles happens on the admin side

Yes, and this is a direct by-product of us forbidding access to unpublished content on the public site. If we relax this in teh status-mods branch and make it (perhaps) so that logged-in users with article.preview capability can view articles on the public site, then we can forego this nonsense situation.

That will probably require changes to <txp:article/> and <txp:article_custom/> tags (and maybe other tags that take a status) to permit all statuses to be displayed.

It would be a boon for people who wanted to show all articles to logged-in users (via the new <txp:if_logged_in> tag perhaps) and offer direct links to the admin side for editing. But we’d need to be very careful not to expose such articles to regular visitors, even if the URLs were typed by hand. Future future…


The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.

Txp Builders – finely-crafted code, design and Txp

Offline

Board footer

Powered by FluxBB