Go to main content

Textpattern CMS support forum

You are not logged in. Register | Login | Help

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

phiw13
Plugin Author
From: Japan
Registered: 2004-02-27
Posts: 2,340
Website

disabled plugin and Preference panel oddity

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)


Where is that emoji for a solar powered submarine when you need it ?

Offline

#2 2020-12-07 09:48:21

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 10,244
Website GitHub

Re: disabled plugin and Preference panel oddity

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:

  1. 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).
  2. 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.
  3. 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.


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

Online

#3 2020-12-08 04:41:11

phiw13
Plugin Author
From: Japan
Registered: 2004-02-27
Posts: 2,340
Website

Re: disabled plugin and Preference panel oddity

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

(Probably for a TXP.next)


Where is that emoji for a solar powered submarine when you need it ?

Offline

#4 2020-12-08 09:03:27

Bloke
Developer
From: Leeds, UK
Registered: 2006-01-29
Posts: 10,244
Website GitHub

Re: disabled plugin and Preference panel oddity

Brill, thank you.


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

Online

Board footer

Powered by FluxBB