MU Upgrade 3.0.5 > 3.1 Admin Stopped Working, Plugins Hard to Find

I did the manual upgrade and had the same problem. I tried to log into the admin and have the exact same issue with the nameless howdy and everything. I have multi sites and lots of plugins but haven’t tried turning them off yet.

Yeah, that’s why a lot of the time it’s suggested you turn off plugins before upgrading. It’s basically a collision with calls the plugin makes and calls WP makes.

tl;dr: Plugin’s acting badly.

Does it help to deinstall all plugins and re-install?

My dashboards are running so slow post-upgrade. It’s taking 2-3 minutes to get links to open.

Anyone else having this issue?

@lpstenu, yes, in a Drupal install I’d turn everything “off” then “on” again, but I’ve not done that with WP in years. Part of the attraction of WP is the simplicity of upgrades. If this step is really required, then WP should manage the off and on again as part of the auto upgrade, in fact, I thought it did just that.

Note, I’ve done half a dozen single site upgrades to 3.1 without incident, I think this is a mixup in the multisite plugin handling, probably something that has to do with the shift of plugins to the network admin area.

@illovich, yes, deinstalling and reinstalling the plugins helped. Of course, since the dashboard was broken I had to do this by removing the plugins from the wp-content/plugins folder, then going to the dashboard so that WP could notice they were missing, warn me, and turn them off, then return the plugins to the plugins folder and “network activate” them again. But yes, doing that dance did resolve the problem I was experiencing.

@rewetherly, no, my dashboards do not seem to be slow. They are pretty much responding as normal.

eceleste – It’s only required with SOME plugins. I’m sure you can look at the vast number of plugins, calculate that with the number of installs and combinations of plugins, there’s no possible way for WordPress to test every single variation of installs, right? ?? There are thousands of plugins and millions of installs. We’d need a couple crays to pull that sort of regression testing, and even THEN, we’d miss something. Certain things are impossible, and testing everything is one of them.

I’m not saying it to downplay, just to make you aware than WordPress works most of the time like this. It sucks you got caught with a bad one. Wish we could know which one. Are you using a lot of plugins?

@lpstenu, note that this error was not any sort of plugin incompatibility. I’m not saying WP could solve that for users, you are quite correct to point out how difficult that would be.

In this case I started and ended with the same plugins running and not causing any problems. Zero compatibility issue with 3.1.

What was a problem was the upgrade process. Somehow that hosed the admin side of the WP MU site until all plugins were removed, reinstalled, and reactivated. I have no idea why that made a difference. But if some investigation shows that to be the case, then the WP MU upgrade process could certainly note which plugins are active, remove all plugins, reinstall them after the base upgrade, then use the note to reactivate the appropriate plugins. That would not require any sort of regression testing.

Again, I had no problems with any plugins in 3.1, they are all working just fine. And yes, I use quite a few (about a dozen) on this MU site.

Actually, it WAS a plugin incompatibility. You have a PLUGIN that was conflicting with the upgrade Process.

Seriously. That’s what happened to you. Seen it before.

OK, that’s new to me and may be the case. If so, then why did I not have to continue or complete the upgrade process to fix the problem. Again, all I did was remove and return all plugins.

Also, if this is the case, why does WP allow any plugins to run during the upgrade? Plugins only run because WP calls them. Running them during an upgrade seems like a very bad architectural decision. Wouldn’t it be simple enough to ignore all plugins and plugin code during an upgrade?

Granted, I know nothing of the internal WP auto-upgrade process, so I could be misunderstanding a lot. Now I’m kind of curious, so a pointer to where to learn more would be good.

I can explain this better when I’m not feeling like a hippo sat on me (stupid flu bug…) so I apologize for the brevity.

The automated upgrade first downloads the zip (essentially), then removes deprecated files, then copies the new files up, and THEN you re-activeate the site. That’s why, when we do an upgrade manually (like I prefer to) the last step is always to VISIT your admin section ?? That’s when database stuff gets done. So, option one here is that your database stuff wasn’t done yet (there was a bunch of stuff from 3.0.5 to 3.1 so the network needed to get kicked).

But even if I presume that DID happen, there’s still a … boot order (for lack of a better term). Based on how plugins are written, how they call various and sundry WP calls can be pretty disparate. Some handle all this really well, some don’t.

Why does WP let you keep plugins on? Well, most of the time this works without a hitch, as you’ve noticed yourself ?? So because they’ve trapped MOST of the causes for that, just like they’ve managed MOST of the kinks out of the auto-upgrade, they permit you to keep plugins on. But when things go blaaaaargh (technical term ?? ), we resort back to the old ways. Manual upgrade, turn off the plugins, etc etc.

(I’d also posit that since SOME plugins don’t uninstall so great- like WP Super Cache literally needs to UNINSTALL stuff, or other plugins that delete settings when uninstalled – it’s less traumatic to take the risk, since the negative payoff is so low. I could do a better job, but I’d need a white board and a red bull.)

That is a really helpful summary. I was wondering when the db stuff was handled. Yes, given what I saw it could easily have been something getting in the way of that step. A later visit to the admin section may have kicked the remaining upgrade into gear.

I noticed a speed issue with admin on a 3.1 upgrade and found it was the database that hadn’t been upgraded properly, a visit to /wp-admin/upgrade.php was all it took to get full speed back again!

HTH

I tried doing the automatic update (before reading all this…. I figured it’d be automatic!), and now my site is completely down.

Fatal error: Cannot redeclare is_rtl() (previously declared in /home/content/d/o/w/downpick/html/wp-includes/locale.php:347) in /home/content/d/o/w/downpick/html/wp-includes/locale.php on line 349

visiting /wp-admin/upgrade.php as recommended informs me that I’m up to date, but my admin page is down, my main page is down, and I seemingly can’t get in there to make any sorts of amendments. I did have some plugins running, and would love to disable them, but I can’t get in there.

Anyone have any suggestions?

@downpick… Can you get to the filesystem in which your blog is installed? If so, navigate to the “wp-contents” folder and rename your “plugins” folder to something like “plugins-off”. That way WP won’t find them and will run (we hope) without them. Then create a new “plugins” folder and move your plugins back one by one till you identify the troublemaker.

Good luck!

Then create a new “plugins” folder and move your plugins back one by one till you identify the troublemaker.

Actually, once you get back in, go to the plugins page, make SURE nothing is listed, and then just rename plugins-off back to plugins ??

Works just as well, with less hassle.