whitwye

This appears to have something to do with cached JavaScript. Starting a fresh “incognito” tab in Chrome, the main page works fine. So it’s something cached. Having JavaScript from one site — even at the same IP — able to block operation of the main page of another site though is a serious bug, providing a prospect of DoS even if it doesn’t open the door to cross site scripting.

Will removing the plugin and re-installing lose all our settings for it?

Would installing manually be less likely to lose settings than using the automation?

• This reply was modified 8 years, 6 months ago by whitwye.

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.

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

Hi Bas,

I could not deactivate the plugin from the plugin screen, since the update made all of the site totally inaccessible. The update was done using WordPress’s method to update in place. It was just this plugin being updated.

So I take it that the only safe way is to deactivate it first, Then update it. Then re-activate?

Rendering the whole site inoperable is a drastic failure mode. For instance, the admin screens shouldn’t care about whether a plugin like this is operational. Would it be possible to write the code at some level so that failures are soft rather than hard, and leave everything on a site that doesn’t require the plugin still operational?

Best,
Whit

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.

Looking at a prior DB dump, wp_maxbuttons_buttons is the only table we’ve ever had for it. Where is the demand now for wp_maxbuttons_collection coming from?

The maxbuttons upgrade totally broke our site.

WordPress database error Table ‘[sitename].wp_maxbuttons_collections’ doesn’t exist for query select collection_id, collection_key, collection_value from wp_maxbuttons_collections where \n\t\t\t\t collection_key in (‘show_homepage’,’show_page’,’show_post’, ‘show_archive’) made by require(‘wp-blog-header.php’), require_once(‘wp-load.php’), require_once(‘wp-config.php’), require_once(‘wp-settings.php’), include_once(‘/plugins/maxbuttons/maxbuttons.php’), maxButtonsPlugin->__construct, maxCollections::setupHooks

Neither reverting to the old plugin code nor reinstalling the new by hand fixes this. Somehow the upgrade has screwed up the MySQL tables. No page in the site will display now – not even the admin pages. Really painful!