MyBB Community Forums

Well, not actually. The sorting of active/deactivated plugins only checks if the plugin is activated and shows it under the proper table. It ignores the returned value of its _is_installed() routine.

I don't really see the problem here - if a plugin is activated it's save to say it's installed too. If a plugin adds the install function later the plugin needs to be deactivated anyway to remove the old change(s).

Checking is_installed everytime (we'd also need to change the loading of plugins) would also add a lot of new queries as most plugins run a query in is_installed.

(2014-10-24, 07:15 AM)Jones H Wrote: [ -> ]I don't really see the problem here - if a plugin is activated it's save to say it's installed too. If a plugin adds the install function later the plugin needs to be deactivated anyway to remove the old change(s).

Checking is_installed everytime (we'd also need to change the loading of plugins) would also add a lot of new queries as most plugins run a query in is_installed.

I also don't see any point of this change, I think we should reject this.

Quote:Checking is_installed everytime (we'd also need to change the loading of plugins) would also add a lot of new queries as most plugins run a query in is_installed.

We already run the routine. The value is already checked, just not taken into consideration when building the active/deactivated table lists.

The plugin is misplaced then.

Also, I don't think dropping functionality over performance in a page barely visited to be a valid reason to not to fix an issue.

Then the link are wrong. The plugin class doesn't check the is_installed function when loading plugins: https://github.com/mybb/mybb/blob/featur...hp#L27-L42 It only uses the active cache array, which is also used to build that table. If you change it there you'd also need to change the load function. And that is called on every page.

This is probably better classified as a plugin issue. Plugins shouldn't rely on multiple tables in the _is_installed() routine, especially when new are added during updates, but only one that never gets removed (for example).

At the end it comes to annoying plugin author practices.

Just think about this little example:

Plugin version 1.0: only template changes, using activate function -> cache sets plugin as active, plugin is loaded by the plugin class
Plugin version 2.0: table gets added, is_installed uses "return $db->table_exists('plugintable');". However it's still in the active array and loaded by the plugin class.

If we'd only add your change to the acp it's shown as deactivatet/not installed while it's still loaded in the frontend. So we have two options here:

1. Show it as activated/installed in the acp with the correct links
   
2. Check is_installed in the plugin class and for the table
   

Let's use the second as an example: every plugin we have installed checks it's status against one table. So we'd add one query per plugin on every page. Eg this page has 32 queries atm and a normal forum has around 10 plugins installed, that'd increase the query number by 30%. For boards with many plugins even more. And that on every page?

Oh sure, I didn't meant to run the routine while loading the plugins, that would be crazy.

But using your example, there may be situations where administrators delete plugin files when they shouldn't. But again, that may be an issue with bad plugin authors practices.

Fixing this may not be worth it at the end, just thinking about a solution makes my head overheat.

If they delete files without deactivating/uninstalling the plugin there's nothing we (or the author) could do. We should simply update the links: If the plugin is activated the deactivate link should be shown, regardless of the return value of is_installed.

Sounds good enough to me.