Situation around plugin (de-)activation in preferences

Destry · 2018-03-25 14:02:32

+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‽ ;)

uli · 2018-03-27 12:41:11

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.

etc · 2018-03-27 12:47:28

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.

uli · 2018-03-27 12:57:24

etc wrote #310402:

previewing unpublished articles happens on the admin side

Oh——K!

Bloke · 2018-03-27 13:49:12

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…

Bloke · 2018-03-27 19:35:46

Try the bleeding edge dev and let me know how you get on. In the Plugins panel I’ve struck out any plugins that are not considered, and omitted them from the Diagnostics panel entirely.

Just remember the caveats in my post above. It can only omit/strike out plugins that it knows for sure are not active based on the settings. If there’s any doubt (i.e the plugin could appear on both admin and public sides) then the plugin is considered ‘active’.

EDIT: I wanted to display the strikethrough only on plugins that had ‘Yes’ (since if a plugin is locally disabled, it doesn’t matter what the global setting is) but since it does an AJAX call to toggle it and that function is used elsewhere (e.g. the Sections panel) I can’t hijack it to toggle the strikethrough. Perhaps if we had a strikeout class or something instead of wrapping the content in <s>...</s> tags that would be better as we could then target whether we act upon the class or not, on a per-panel basis. Maybe that’s something we look into in future.

Last edited by Bloke (2018-03-27 19:43:21)

uli · 2018-03-29 12:01:08

I’ve currently not enough time to play with it exhaustively, sorry. For the moment, I’ve just looked at it in the demo, one plugin, rss_admin_db_manager.

The current state, i.e. just striking through the “Active” indicator in the Plugins panel, is a little free of unequivocal information on what the strike-through means, when there is no banner, no hover-help etc.

Re Diagnostics I’ve finetuned my initial opinion a little: I’d not remove inactive plugins entirely, cause that withholds information on what may have lead to the user’s complications. I’d find it useful to separate the list of all (installed, usually active) plugins in two groups, one that’s deactivated 100% sure, and one we can’t tell safely, and give these groups an apt caption each.

Bloke · 2018-03-29 13:07:08

uli wrote #310438:

The current state, i.e. just striking through the “Active” indicator in the Plugins panel, is a little free of unequivocal information on what the strike-through means.

True. All extra strings, though. I’m trying to minimize those (he says, having just added some Plugin code that requires more strings, and potentially more changes with the new/create changes).

Re Diagnostics… I’d not remove inactive plugins entirely, cause that withholds information on what may have lead to the user’s complications.

How? If they’re not active (turned off by hand in the Plugins panel or definitely deactivated via the prefs) then they can’t possibly be causing any issues, because they’re not loaded.

The only situation I can think of is that, when asked to post diagnostics, someone turns on/off plugins or tinkers with the prefs first. And if that’s the case, the results may well be different and the problem might go away, leading to them solving the issue themselves. Am I missing a use case?

EDIT: if the cause of the issue is “tag not found” on the public site, then the act of omitting the plugin also leads to the swift resolution!

I’d find it useful to separate the list of all (installed, usually active) plugins in two groups, one that’s deactivated 100% sure, and one we can’t tell safely, and give these groups an apt caption each.

That’s certainly a possibility. Before considering it, I’d like to find if I’ve missed anything with regards the above.

Last edited by Bloke (2018-03-29 13:08:41)

uli · 2018-03-29 20:35:32

Bloke wrote #310440:

The only situation I can think of is that, when asked to post diagnostics, someone turns on/off plugins or tinkers with the prefs first.

That’s what I meant, for the forgetful, for hasty people, non-techies and other muddlers. People like me.

Textpattern CMS

Textpattern CMS support forum

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

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

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

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

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

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

uli wrote #310313:

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

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

etc wrote #310402:

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

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

uli wrote #310401:

etc wrote #310402:

#21 2018-03-27 19:35:46

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

#22 2018-03-29 12:01:08

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

#23 2018-03-29 13:07:08

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

uli wrote #310438:

#24 2018-03-29 20:35:32

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

Bloke wrote #310440:

Board footer