disabled plugin and Preference panel oddity

phiw13 · 2020-12-07 04:36:13

Should a plugin that has once been activate but then disabled still appear on the Preferences panel?

I am looking at com_article_image and smd_textile_bar, currently installed, disabled but both appear on the Preference panel (entry in the TOC) and those prefs can be edited and saved.

I find that rather strange.

(TXP 4.8.4 and 4.9-dev)

Bloke · 2020-12-07 09:48:21

Hmmm, that is kinda annoying. It only affects certain types of plugin that install their own prefs for core to manage. If the plugin builds its own panel, the prefs will disappear when the plugin is disabled.

We could maybe do a check on the prefs panel to see if a plugin is installed/active and only display their prefs if so. This might fall foul of a few things:

It gives a false sense of security that the prefs aren’t there any more, especially if the plugin doesn’t tidy up after itself on deletion (I’m guilty of that in, for example, smd_article_stats).
Public-only plugins aren’t loaded on the admin side so if they have any prefs that are installed and not actively managed by the plugin itself on the admin side, disabling the plugin won’t remove the prefs – the plugin is “invisible” to the admin side already.
If the plugin uses refs that don’t match the plugin name (smd_article_stats uses smd_artstat as a prefix/owner/event because of a legacy limitation of 11 characters in the event field, and I never changed it when the limit was removed in, I think, 4.6.0) then finding matching prefs when a plugin is disabled is a best-guess/wild stab-in-the-dark.

The first point isn’t much of an issue, per se. Out of sight, out of mind! The second is something we’d have to live with anyway and I don’t think it affects many – if any – plugins. The third, well, nothing much we can do if an author uses a different prefix to their plugin name. All we can do realistically is encourage authors to use the same plugin prefix everywhere throughout their code, citing that it’ll make a smoother ride for users.

Let me have a play anyway and see if we can exclude stuff from disabled/deleted plugins in core. Might be non-starter, but it’s worth a try, even if it catches most of the well-behaved plugins out there.

phiw13 · 2020-12-08 04:41:11

Thanks for having a look and some further analysis, Stef. I filed issue 1602 for tracking this.

(Probably for a TXP.next)

Bloke · 2020-12-08 09:03:27

Brill, thank you.

Myusername · 2021-06-30 07:05:17

I have a similar problem on a test site. In fact, I’ve already deleted the com_article_image plugin, and the preferences still remain there.

Bloke · 2021-06-30 08:31:29

Myusername wrote #330805:

I have a similar problem on a test site. In fact, I’ve already deleted the com_article_image plugin, and the preferences still remain there.

Are you using the latest code? That plugin should tidy up after itself on deletion.

phiw13 · 2021-06-30 09:07:39

Bloke wrote #330808:

Are you using the latest code? That plugin should tidy up after itself on deletion.

am I missing something here? I had the plugin installed but disabled. I installed the latest code base (v 0.1.1) enabled the plugin to briefly check it, including vising its pres. Then I first disabled the plugin, the preferences pane still show an entry (Article image helper). Next I deleted the plugin, same issue (even after force refreshing the prefs pane, to be on the safe side).

etc · 2021-06-30 09:22:20

Funny this AND:

"name LIKE 'abc\_file\_%' AND name LIKE 'com\_article\_image\_%'"

Should be fixed in v.0.1.2, sorry for the trouble.

Bloke · 2021-06-30 09:24:21

etc wrote #330810:

Funny this AND

Honouring its roots. But yes, should be OR, oops :)

phiw13 · 2021-06-30 09:32:11

Bloke wrote #330811:

Honouring its roots. But yes, should be OR, oops :)

Two characters instead of 3.

That seems to do the trick when uninstalling that plugin.

Textpattern CMS

Textpattern CMS support forum

#1 2020-12-07 04:36:13