Force deactivation function independent of theme switch

[sipy]

Hi, I'm using your library for plugin synchronization across different environments. This library is great for managing plugins, but it misses a fundamental feature for my use case. I am using git and my purpose is to have all of my environments (dev of each of my teammates, stage, prod) to be synced. Managing the plugins with git is very painful for various reasons. Requiring plugins and corresponding version is great with the TGM library but if I want to delete a plugin from my environment and notify all other environments to delete the plugin as well, there is no such a functionality offered. I can see that there is a force_deactivation feature, but it is useless in my use case because it requires the plugin deactivation only between theme switch. I need to require a plugin deactivation/deletion in the same theme as well instead. Another use case may be if your theme is not compatible with some plugins, so you must force those plugins to be deactivated in your theme. Is there a solution of my problem using this library?

Thank you

[jrfnl]

Hi @sipy, to be honest, that sound more like the kind of situation where Composer would be useful. Have you looked into that ?

[sipy]

Hello, composer would manage only the files of the plugins. The problem is when plugin needs to be updated. A plugin update could contain DB changes as well, and if you sync only your files with composers, the DB tables of the updated plugins risk to remain not updated on the different environments. TGMPA solves that with a notice message to manually update the plugin on the corresponding environment when needed.

[jrfnl]

A plugin update could contain DB changes as well, and if you sync only your files with composers, the DB tables of the updated plugins risk to remain not updated on the different environments.

If that happens, it is a case of bad plugin design. Actually, the same can be said for plugins using register_activation_hook.

Relying on an activation hook or actions being run on activation or update of a plugin will not work in all cases - like manually updating via FTP or in your case updating through Composer -. Not only that, but these hooks will also not work properly in multi-site environments.

For a much more stable code pattern to use with activation & upgrade actions, have a look at the code on the following two slides: https://speakerdeck.com/jrf/the-secret-to-mastering-wordpress-multi-site-php-world?slide=26 https://speakerdeck.com/jrf/the-secret-to-mastering-wordpress-multi-site-php-world?slide=27

If you use plugins which don't use the pattern which I describe in those slides, send them a bug report. Relying on hooks to be run on activation or upgrade is really not the way to go.

In the mean time, if there are still plugins in your setup which don't use the above code pattern, you could add a custom "master" plugin which basically does the same, but calls the activation/upgrade routines for the other plugins in your setup if/when needed.

[sipy]

Hello, thank you very much. If all the plugins use this design pattern, the problem I described does not exist and I can simply add the plugins directory back to be tracked with git as well. I will investigate if it is a standard practice along all of my current plugins to be sure every plugin is using this logic.

[jrfnl]

@sipy Unfortunately there are a lot of plugins out there which don't always adhere to these kind of best practices. Hope the ones you use do ;-)

[sipy]

I think the wordpress community (especially the worpdress.org plugin repository) should have at least a strict verification of similar kinds of situations before releasing the plugin into the repository. The summary of the answer of my request is: "You can add the plugins to the GIT repo and track them all, because they should have an implemented design pattern that updates the DB on plugin initialization if the version has been changed. BUT not all of them do it, so ensure this by yourself or deactivate and then activate them again manually on each environment on plugin update pull"

[jrfnl]

@sipy Does this mean we can close the issue here ?

[sipy]

Yes, thank you.