WordPress.org

Make WordPress Core

Opened 10 months ago

Last modified 9 months ago

#24642 new defect (bug)

readme.html in core download does not warn about >2 version upgrades

Reported by: esmi Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 2.7
Component: Text Changes Keywords: close
Focuses: Cc:

Description

If you plan on upgrading across more than two major releases, please consider upgrading incrementally to avoid potential conflicts and minimise the risks of database damage.

http://codex.wordpress.org/Upgrading_WordPress_Extended

The readme.html makes no mention of this and simply points users of WordPress 2.7 or above to the 1-click auto-update. This greatly increases the risks of plug-in/theme conflicts and database damage.
I'd suggest updating the readme.html & changing:

If you are updating from version 2.7 or higher, you can use the automatic updater:

to:

If you are updating from version 2.7 or higher and are no more than more than two major releases behind the current version, you can use the automatic updater:

Then a new section immediately afterwards:

Updating Older Versions Manually

If you are currently more than two major releases behind the current version, you may need to carry out a series of smaller manual upgrades. Please refer to the instructions in Upgrading_WordPress_Extended?.

Attachments (1)

readme.html (9.4 KB) - added by esmi 10 months ago.
Updated readme.html file

Download all attachments as: .zip

Change History (13)

esmi10 months ago

Updated readme.html file

comment:1 dd3210 months ago

The codex should probably have that statement removed.

There is no need to do incremental updates with WordPress, you can update from WordPress 1.5 to 3.5.2 directly, and/or from 2.7 to 3.5.2 directly with the built in updater.

It appears that paragraph is rooted in the times of "Update from 2.5 to 2.7, and then let the builtin upgrader take you to 2.9"

comment:2 esmi10 months ago

Long experience helping out on the support forums suggests otherwise. Large single upgrades have a far greater chance of failing with multiple problems - including damaged databases.

comment:3 mark-k10 months ago

IMHO manual upgrades version by version are impractical, If it is really needed then maybe there should be an "Upgrade to next version" button in addition to "Upgrade to latest" for this kind of situations.

esmi, isn't it correct that the people that come to the forums are the ones with the problems so it is hard to estimate what percentage it is from the overall upgrades?

IMO if the upgrade fails it is a bug and should be fixed. Putting notices in a file that in practice no one reads will not help much.

comment:4 follow-up: esmi10 months ago

esmi, isn't it correct that the people that come to the forums are the ones with the problems so it is hard to estimate what percentage it is from the overall upgrades?

Absolutely! But some of these users are actually reading the readme.html file (hooray!) and trying to carry out massive 7-version upgrades in a single step. And failing catastrophically Why would a note that points to the relevant Codex page be such a big problem?.

comment:5 in reply to: ↑ 4 mark-k10 months ago

Replying to esmi:

esmi, isn't it correct that the people that come to the forums are the ones with the problems so it is hard to estimate what percentage it is from the overall upgrades?

Absolutely! But some of these users are actually reading the readme.html file (hooray!) and trying to carry out massive 7-version upgrades in a single step. And failing catastrophically Why would a note that points to the relevant Codex page be such a big problem?.

I just don't think it really solves anything. If the software suggests to do a one step upgrade then why should a user question it? and if I'm running 2.8 how exactly am I supposed to know that 3.0 is not the next version? I will guess that most users don't know what is the version numbering scheme of wordpress so they can't know across how many major versions they are upgrading (aside - what is exactly major version, is 2.8.1 is major? how do someone know that 3.x are all major versions and not minor?)

comment:6 esmi10 months ago

They don't but let's at least bring the readme in line with the Codex. Being confronted by conflicting information is a problem for those people who do go out and read documentation.

comment:7 SergeyBiryukov10 months ago

  • Component changed from General to Text Changes

comment:8 dd3210 months ago

Perhaps someone should pull together a few of these support threads, triage, and file bug reports for any issues users are running into?

comment:9 SergeyBiryukov10 months ago

From the thread that led to this ticket:

My problem with 2. is that I overwrote the files with 352 and as per the readme I deleted the old WP files, meaning I no longer have a wp-config.php.

http://wordpress.org/support/topic/upgrade-from-271-to-352-failed

The readme currently says in the "Updating Manually" section: "Delete your old WordPress files, saving ones you've modified." (tags/3.5.2/readme.html#L45) Perhaps it should explicitly state that you should never ever delete wp-config.php and wp-content when doing a manual update.

comment:10 follow-up: nacin9 months ago

  • Keywords close added
  • Version changed from trunk to 2.7

Strongly disagree with this. If a database is getting damaged going seven releases, it was going to get damaged going one release too. Or, there is a single very bad five-or-six-year-old bug that no one has ever fixed, or reported. Our database upgrade routines are often very light, especially since 2.8. In fact there was/is no DB upgrade at all for 3.1, 3.2, and 3.6; and the upgrade routines for 2.9 and 3.0 were incredibly light. The routines for 3.3, 3.4, and 3.5 all "did things" but nothing that should cause complete database corruption, even if run all together at once.

comment:11 markjaquith9 months ago

Agree with Nacin here. If one is going to go wrong, it is the massive taxonomy upgrade that happened so many years ago. Since then, we've really been good about making the DB upgrade light. If we had another really massive one to do in the future, I'd consider an alternative approach. Like, some sort of batching, or an on-the-fly upgrade like we're doing in 3.6 for fixing revisions on a post.

comment:12 in reply to: ↑ 10 SergeyBiryukov9 months ago

Replying to nacin:

Strongly disagree with this. If a database is getting damaged going seven releases, it was going to get damaged going one release too.

It's not just database upgrade routines, it's timeout and memory_limit issues too (3.5.2 package is almost twice as large as 3.0).

One scenario I could actually reproduce is a fatal error (Allowed memory size of 33554432 bytes exhausted) when updating directly from 2.9.2 to 3.5.2.

[14491] was added to fix that, and after manually updating to 3.0 first, the automatic update from 3.0 to 3.5.2 works fine. Of course, Memory Bump would help too if the user knows what to look for, however if display_errors is off (which I guess is the default for many hosts), the issue may not be obvious.

Note: See TracTickets for help on using tickets.