I added the tip about the WordPress Automatic Upgrade plugin. Since I've been using this plugin, I've never reverted to the manual upgrade process. It makes it so much easier. --Tom 16:37, 26 April 2008 (UTC)
I've rather significantly changed the instruction: IMHO, it's better to keep all template files (even 1.3 is downwards compatible) and to sort out potential conflicts with ready-made themes and plugins later. I've left the instruction to delete .htaccess, even if I'd never do such a thing. What are your opinions? -- serendipity 10:15, 16 Dec 2004 (GMT)
Maybe instead of the statements warning folks, we should have links for relevant upgrade guides, and rewrite this to say that this is the upgrade guide for 1.2 and older.
For reference Upgrade 1.5>1.5.1 thread on Forum
Consider adding something that makes it clearer for someone asking How To Upgrade From 1.5 to 1.5.1.3? : MichaelH (talk) 22:00, 3 Jul 2005 (UTC)
It says you will be prompted to upgraded the database, but I was not. It looks like the text was left over from the 2.0.4-2.0.5 upgrade instructions and should be removed? Mickwest 17:47, 5 Jan 2007 (UTC)
Maybe we should add something about keeping wp-content never updated might lead to have a very outdated Akismet version.
It says we need to make a backup of index.php, but then index.php is not deleted, following the instructions. --Blonkm 13:01, 20 Apr 2007 (UTC)
Honestly I think the instructions in five steps suck. I have done the update several times and there's a lot of information in there, which I think is either not necessary or should be rephrased.
For example:
Important: If you are upgrading to WordPress 2.2.1 from 2.0.x, 2.1.x, or 2.2, then someone who wrote a previous version of this page thinks it important for you to delete any WordPress filenames that may have changed. Take a look at the Delete the old WordPress files section for clarification.
So what now? Is this important? Who is someone? Why did he think it is important? Either it is, or it isn't.
Here's my suggestion of simpler instructions (see User:Felix/Upgrading_WordPress). Can someone who is into all the upgrading details check whether they're valid?
Thanks for your help, --Felix 05:20, 24 Jun 2007 (UTC)
The guide suggests that we utilize the Maintenance Mode plugin during upgrades, then goes on later to tell us to de-activate all plugins before upgrading. You can't do one if you do the other.
I've redrafted much of this page. Based off of trac ticket http://core.trac.wordpress.org/ticket/11280 there was a desire for a friendlier set of instructions, and hopefully this is they. I've also changed the terminology to Update rather than Upgrade to match the version 3 terminology. I believe most of the detail has been maintained here, though if there is anything else it may well belong in the upgrading extended documentation rather than here, so that this is as clutter-free as possible.
mrmist 22:56, 20 March 2010 (UTC)
So many problems happen because plugins aren't deactivated before both the manual and automatic update. Therefore, it should be in the Manual Update instructions. Not just in the Upgrading WordPress Extended instructions. Please don't remove this step again.
Yaelkmiller 19:37, 22 February 2012 (UTC)
I miss a note (here), that the root directory have to be also with the webserver user and the folder permissions.
--Joker234 21:37, 28 April 2014 (UTC)
Please read this section carefully. I would suggest to write it again from scratch, because it seems to either contain wrong facts or is written down in a very misleading way.
A few examples:
Criteria (a) says "all of your WordPress files must be owned by the user under which your web server executes".
One paragraph down in the additional criteria (b) it says, "On shared hosts, WordPress files should specifically NOT be owned by the web server.".
These are conflicting propositions. Therefore, I would expect "One-click Update" should NEVER work on reasonably configured shared hosts. Is that correct? Then, please write it that way!
The paragraph on shared hosts goes a long way to describe how to make the files group writable, if they have different owners (as it happens e.g. with different upload accounts). But when I trust the criteria (a), group-writability won't help, if the owner is not the user under which the web server executes.
So why even bother to describe group-writability at all?
If I take criteria (a) for granted ("files must be owned by the user under which your web server executes"), then criteria (b) ("files must be either owner writable by, or group writable by, the user under which your Apache server executes") seems to be rather artificial.
Yeah, that section was confusing. I've updated it. If you think it needs more clarification, just say so. -Jdgrimes (talk) 14:05, 22 September 2015 (UTC)