Opened 11 years ago
Closed 9 years ago
#24642 closed defect (bug) (wontfix)
readme.html in core download does not warn about >2 version upgrades
Reported by: | esmi | Owned by: | |
---|---|---|---|
Milestone: | 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)
Change History (14)
#1
@
11 years 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"
#2
@
11 years 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.
#3
@
11 years 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.
#4
follow-up:
↓ 5
@
11 years 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?.
#5
in reply to:
↑ 4
@
11 years 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?)
#6
@
11 years 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.
#8
@
11 years ago
Perhaps someone should pull together a few of these support threads, triage, and file bug reports for any issues users are running into?
#9
@
11 years 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.
#10
follow-up:
↓ 12
@
11 years 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.
#11
@
11 years 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.
#12
in reply to:
↑ 10
@
11 years 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.
Updated readme.html file