Plugin removal strategy

[mediaformat]

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?

[Tetrahedrax]

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

trellis 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.

[dalepgrant]

You could also do this in a deploy hook.

In /deploy-hooks/finalize-before.yml (create it if it doesn’t exist) you could do:

# Uninstall blah-blah-blah plugin cleanly
- name: Uninstall blah-blah-blah plugin before removal
  args:
    chdir: "{{ project_root }}/{{ project_current_path }}"
  shell: "if $( wp plugin is-installed blah-blah-blah ); then wp plugin uninstall --deactivate yith-blah-blah-blah; fi"

Make sure you’ve added the file /deploy-hooks/finalize-before.yml to roles/deploy/defaults/main.yml under deploy_finalize_before. This will then run before Trellis swaps the release folders i.e. as late as possible.

Edit: added check to make sure plugin is installed and --deactivate flag to deactivate plugin before uninstalling.