Plugin removal strategy

plugins
1

We have recently started a deep dive into Performance of a long running site. This particular project has gone through various phases, developers, etc.

One thing we’ve noticed is a number of old plugin tables still present in the db.

My current thinking is that because composer remove just deletes the plugin, we need to manually deactivate the plugins (this is typically where plugins cleanup, deleting options, meta, and custom tables) before deploy a release with composer changes.

Has anyone else come across this, how are you managing/automating this?

2 Likes
2

I’ve noticed the same thing.

Here’s what I do:

composer remove bla-bla-bla

composer update

commit composer.json

ssh web@123.456.789

cd /srv/www/example.com/current && wp plugin uninstall bla-bla-bla

exit

composer deploy production

I usually don’t do this however. The small amounts of data left behind by (most) plugins should be negligible. Now, getting the admins to not upload the same image 7 times for 7 different articles instead of reusing it, that’s a different type of optimization issue with a PICNIC-related solution. Sigh.

3 Likes