This came up recently with the WordPress upgrade to 3.0 (and subsequent 3.0.1 bug fix). A lot of people had problems upgrading from WordPress 2.9.2 to 3.0, and for the most part, the fixes were simple.
There was a known ‘memory bug’, where WordPress didn’t request enough memory from the server when upgrading and, since 3.0 is a bit bigger than 2.9.2, it failed. This was fixed with the plugin Memory Bump. Once you upgraded to 3.0, you could remove this plugin, because the new WordPress version took care of it on it’s own. There were other issues, though most of them seemed to be plugin conflicts or people using weird versions of PHP. I even had a note I kept handy:
We’re in the process of pushing out a plugin for this: http://wordpress.org/extend/plugins/memory-bump/
In the meantime, you can also add this to your wp-config.php file:
define('WP_MEMORY_LIMIT', '256M' );
The issue is that WP *may* need more than the default 32 MB to upgrade to 3.0, due to the increased package size over 2.9. This is a “known issue”.
3.0 handles this by always bumping you to a very high memory limit in the admin area, so you won’t see this once you’ve hit 3.0.
Weird Errors and blank screens
Rename your plugins folder to plugins-old (via FTP or SSH) and see if that fixes it. If so, name the folder back to plugins and reactivate your plugins, one at a time, testing between each copy.
Believe it or not, those two answers were probably 90% of what I posted on the WordPress forums for the better part of a week. That and ‘Yes, these plugins don’t work on 3.0 yet’ (and I had a list for that too!).
Then came Zarathustra — I mean WordPress 3.0.1 — and people began to have new issues. The most common was something like this:
Downloading update from http://wordpress.org/wordpress-3.0.1.zip…
Unpacking the update…
Verifying the unpacked files…
Installing the latest version…
Could not copy file.: [some file]
The file would be different for pretty much everyone.
As far as I know, we’ve not found a fix yet, however I pointed out that when the auto-upgrade fails, you should try installing the update manually. It’s not that hard. It’s basically copying files to a server and if you can’t do that, I don’t think you should be running your own self-hosted site. This is why I run the techside of a site for someone else. Know your limits, I always say (my limits self-tests haven’t always been non-destructive, by the way).
In this support post for the failed install, riddle said:
I’d like to get back to the original poster’s point: 3.0.1 automatic upgrades are too unreliable for the very WP admins who most need one-click upgrades.
ipstenu’s reply (“This is a problem with your server setup, most likely, not WP. The most likely reason would be that your PHP setup doesn’t like the way WP 3.0.1 is unzipping and copying files.”) misses the point. If there are common PHP configurations under which the automatic upgrade won’t work, then at a minimum the upgrade script should test for them before breaking the site.
And I replied:
You just hit the nail on the head as to WHY automagic upgrades fail.
There aren’t config standards for PHP and server software that are across the board on every server known to man. Each company has their own settings and standards, and even then (as I pointed out to a coworker yesterday), unless you clone a machine onto the exact hardware, you’re still going to have an inexact copy.
Servers are snowflakes, man. It sucks, but that’s it.
WordPress is able to say ‘Your server must be able to do these things to RUN WordPress’, but even then, someone may have a wildly weird setup where stuff works poorly. It’s the nature of the beast and it’s impossible to test everything.
If the automatic upgrade fails, do it manually. It’s not that hard (copying files). Heck, it’s easier than installing manually the first time!
And really this is the problem with all software, web or otherwise. There’s a reason software has ‘minimum requirements.’ It’s the bare minimum someone tested on and the software worked. WordPress says ‘To run this software, you need PHP 5.2 and MySQL 5.0.15’ (as of of 2011, so get on that now!) and that’s pretty much it. That’s all you need to have WordPress run, but that’s not all you need to do everything you could possibly do with WordPress, and this includes those pretty auto-magical upgrades.
For what it’s worth, I come at my viewpoint from someone who spent 3 years doing application testing. I had to make sure all the apps used together worked together on every computer. Which is impossible. There’s no way I could promise that every app someone might use will always work on a computer with every other app. To make our goal realistic, we ‘certified’ applications, and would list any known conflicts, as well as everything we knew it worked well with or needed tweaks.
Knowing that, and knowing that servers are setup with just as much variation as desktops, means that when someone says that WordPress should have standards it works on I think they’re just naive. There’s really no such thing as a ‘standard.’ There’s no standard location for temporary files, there’s no standard location for a home folder, and there sure as hell is no standard setup for installing PHP on a Red Hat box. There are variables galore that could cause all sorts of issues. There are application conflicts, configuration miss-matches, setup issues and, of course, the fact that there are so many different types of ‘standard *nix servers’ that are used, with hundreds of patches and tweaks, that the target’s moving so fast, I think it just hit you in the head.
So why doesn’t your automated upgrade work when you click the button on WordPress? The possibilities aren’t endless, but they’re pretty thick. You’re better off learning how to do the manual upgrade if you have wild errors no one’s seen before.
And I hold by my belief that if you can’t perform a manual upgrade, you need to rethink your capabilities of running a website on your own. If you’re running MultiSite and you can’t do it, you’re going to be in a world of hurt one day, and I will do the ‘Told you so’ dance.