Totally borked site

Appreciate the quick replies.

5.5.9-1ubuntu4.11 – this is a straight Ubuntu 14.04 system.

There’s nothing to look at right now since I had to totally restore the site files and DB from backups to get past the blank screens.

Hi,

Let’s try to keep the conversation to one topic only, so I’ll write everything here.

1) The best way to handle white page of death with plugins is to login to your site using FTP, then going to the plugins directory and rename the directory of the plugins ( i.e. add _off ) . Visiting the site will deactivate the plugin and the admin will start to work again. Then you can try to activate the plugin normally and see what the issues are.

2) When updating old plugins to a new major version it’s recommended to deactivate the plugin first. Unfortunately with many plugins upgrading many versions can cause new issues for your site ( we try to avoid those of course! )

3) I suspect you have error log on to display errors on the site. For production sites this should be always off. I think this is what was causing the problem with logging in to the site.

4) Yes, we always try to be out of the way as much as possible. The plugin doesn’t load itself, or files on pages outside of the plugin usage. The only thing, is describing when it should get into action, adding the menu pages and, ironically, a check if the database is loaded properly.

But of course it can always be better, so according to your report I’ll do some tests to see if there is a better way of preventing it.

Sorry for the long text, but I hope it will help.

Hi Bas,

Wonderfully fast response. Appreciate it.

1. The renaming of the plugins directory was something I wasn’t aware of as a procedure. I’d googled for how to disable plugins manually, but no luck finding that advice. Thanks. I’m not administering the server through FTP. It’s our server.

2. If plugins should be deactivated first, why doesn’t WordPress’s automated plugin update mechanism do so? We can deactivate them from its menu. We can upgrade them from its menu. There’s no reason the upgrade couldn’t first call the deactivate code and then reactivate after updating, just if it had been active before. I know that’s not your fault, but if plugins upgrades are safer this way, what are the WordPress devs optimizing for? A few seconds of speed in the process?

3. I saw the errors in Apache’s error log. This was not from some WordPress “error log on” option (if there is such a thing). I would never run Apache without error logging. There was no problem with logging onto the site as such. The problem was every single page, including wp-admin, simply came up blank, while the error log showed the failed attempt to find the DB table that didn’t exist. So there was no option to even try to log in. And reloading pages from the already-logged-in session, they also came up fully blank – no code at all came through for them.

Best,
Whit

(2) Yes that’s a big discussion in the community. I believe the hook runs almost always except for doing updates via the updates panel ( so in the plugins panel it does run ). And probably some exceptions with WPMU, and on moonless days.

Also the worst case that -should- happen is a one-time error ( one too much but ok ), and then the plugin create the correct database tables.

So I’m going to test with this scenario in any case to see if I can crash it and then how to prevent that. Failed queries should not crash the whole thing, but I’ll doublecheck.

Thanks for your input in that!

On a second restored version of the site, identical to the configuration where the straight update produced the trouble, followed your advice to deactivate before upgrade, and it worked fine.

Good to hear, resolving this topic then. Will do my part on the testing as said ??

I did some testing by messing and bluntly deleting the database tables under various situations but I didn’t really find anything that could cause white pages. Maybe it was a combination of factors including the upgrading.

I made some tweaks though to remove that query from running at all on the admin site and I found a little bug in the version checker so that everything should be even more robust now.