I recently did a blanket update for all plug-ins for a WordPress site (good idea security-wise, bad idea, turns out, otherwise). This revealed a surprising three problems within the whole ecosystem. Here they are in descending order of importance: fixing the first makes the other two non-issues, fixing the second removes the third issue, fixing the third still would solve the problem but requires more user action.
1: dependency disconnect
As plug-ins for WordPress are basically just zip files that are expanded into a folder, there is a disconnect between what the plug-in might actually need and what is provided by the server. The only way, really, is to install and hope for the best. If the installation goes wrong in any sort of way, you might need to go to the file system and remove the plug-in folder altogether to get the site back up and running. There is a mechanism for first installing and then activating, you will be able to figure out if something’s missing through “trial and error”.
2: breaking update with no deactivate / activate cycle
The latest version of the plug-in requires the php-mbstring module to be available. The earlier versions did not. This means that you were able to install and activate the plug-in in the past and it would work fine.
In my case (running on Amazon Linux at the time) the solution was to simply install php-mbstring and restarting php-fpm:
yum install php-mbstring systemctl restart php-fpm
3: lack of documentation
In this case, the problem was Google’s Site-Kit plug-in for WordPress. It ties the site to Google’s new way of doing analytics. The installation documentation is available at https://sitekit.withgoogle.com/documentation/getting-started/install/ and is pretty comprehensive but misses one little detail.
Some plug-ins, like this one, plug themselves absolutely everywhere. This shows up even on the management toolbar, so the moment you log in to the admin side, it gets invoked. Not having a way of properly tracking the dependencies down to what’s installed on the system, while protecting the service itself from a potential attack vector, makes it susceptible to missing small little details.
I’m hoping someone else will google the problem and find this page and save some time troubleshooting.