Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
A small issue with the UPGRADE.txt .
It contains a list of steps to follow while upgrading a drupal site.
On current step #4 one switches to a core-theme. Good.
There should be a matching instruction reminding the administrator to switch back to his site theme after upgrading is finished. It seems logical to me to have it as step #10.5 (between current 10 and 11), before retuning the site to "online" status (step 11).
Comment | File | Size | Author |
---|---|---|---|
#22 | upgrade_beta6_1.patch | 7.55 KB | KentBye |
#20 | upgrade_beta6_0.patch | 7.55 KB | KentBye |
#18 | upgrade_beta6.patch | 7.54 KB | KentBye |
#15 | no_im_not_back_to_working_on_core.txt | 7.73 KB | Morbus Iff |
#11 | drupal-upgrade.txt-bugs-152967-11.patch | 6.98 KB | webchick |
Comments
Comment #1
webchickSeems logical to me.
Comment #2
keith.smith CreditAttribution: keith.smith commentedInitial patch attached.
Comment #3
webchickNice. I made a few changes.
1. Rolled in the bug fix from http://drupal.org/node/152964, which highlights a critical issue where following these instructions that can cause you to completely hose your site. Not good!
2. Re-numbered all of the steps accordingly.
3. Made some other minor language tweaks (re-enable, rather than re-install).
Comment #4
webchickMore...
1. For some reason we were wrapping these at like 64 characters, rather than 80. Changed. Also removed some double-spaces between sentences. We use single.
2. In doing so, it forced me to actually read the entire file, and I found another nasty surprise -- after deleting your Drupal directory and replacing it with a brand new one, it tells you:
Would've been nice to have known that I was supposed to back up these files *before* I deleted everything, hm? ;) Added another sentence to step 1.
3. The part about changing the variable had periods on the ends of sentences, so it would read:
Even though my inner grammar geek wants these to be complete sentences, of course putting a period there will kill someone's site. :P Removed.
Comment #5
keith.smith CreditAttribution: keith.smith commentedEven better.
Shouldn't we modify step #1 to include mention of the new file default.settings.php? Currently, there is just a mention of settings.php.
Comment #6
webchickGood idea. How's this?
I gotta go work on some other stuff now, but if you find any other problems and/or want to tweak the text more, feel free!
Comment #7
webchickComment #8
keith.smith CreditAttribution: keith.smith commentedI added sections regarding custom module and custom theme code that may need updating, including references to http://drupal.org/update/modules and http://drupal.org/update/theme .
Comment #9
catchiirc there's been security/bug fixes in .htaccess - and some people will have sites than run from 4.5 or 4.6 where there must've been more changes.
so:
Means they'd be overwriting those security and/or bug fixes - could keep going forever potentially. Same goes for settings.php as well.
I'd change it to
Then maybe a link to relevant drupal.org issues for changes if they're known off-hand.
Comment #10
Gábor HojtsyLet's fix this to include in the beta! I read the patch and noticed the following:
- step 3: I would not say "mask errors". This is not the real purpose... "let the database updates run without interruption" might be a better explanation. You are not masking errors, but avoiding them, this is a pretty important distinction.
- step 8: I am with catch that custom .htaccess, robots.txt and settings.php changes should not be restored by restoring the file itself, but copying over the changes themsefs. Although I don't think catch's suggestion is clear enough. A more verbose explanation would be fine.
- step 10: **No way!** I have new code on an old database, so it is impossible to go in and enable modules, the site is broken and putting out errors on all pages... Why would I do it anyway? We used to suggest updating core first and then contrib stuff in a second update.php run, right? Why disable modules, if after adding them back, we enable them again? Also we copy back stuff in step 8, and only suggest to ensure that the modules are up to date *after* we said they should be enabled. This is messy.
It would be great to fast-track a fix for this issue, being a true beta-breaker.
Comment #11
webchickI don't think this is perfect yet, but it's a starting point for further refinement:
New step 3:
(Note: it actually does both. As soon as you update core to a major version there are errors all _over_ the place about undefined functions, missing tables, etc. But I agree that the first and foremost reason is so that database updates run without interruption.)
New step 8:
New beginning of step 10:
New step 11:
New Step 12:
(following items renumbered accordingly.)
Comment #12
Gábor HojtsyThis truly gets better. But people are still asked to copy back their "sites" directory just before running update.php, which means they copy back their old modules. This should not have a side effect if they properly disabled all modules. But if not, they are better off not having those modules hanging around there.
Also it might be quite "disastrous" (psychologically at least) to go through all this update hassle and then find out that some required contrib module is not updated. So having this "ensure you have updated stuff" note at the end might be too late.
Otherwise this is looking real nice, thanks for keeping up the effort.
Comment #13
chx CreditAttribution: chx commentedI had problems staying logged in as uid 1, this might be an artefact of my buggy test environment but I would mention the free_access variable in settings.php esp because it's new.
I would be cautious with copying back sites, you might have a module lurking in there forgotten to switch off causing havoc.
I would urge people (for the reasons Gabor mention) to read the whole thing before starting.
Comment #14
webchickThanks for the feedback, Gabor!
I'm out for a few hours, so if someone could take a stab in my absence so we don't further hold up the beta, that'd be great. Otherwise, I'll re-roll this evening.
Comment #15
Morbus IffNew patch attached, based off webchick's latest. Includes a pre-amble about what they should do prior to starting the UPDATE, some revised text tweaks, and a link to where Off-line mode lives (which needs to be checked by someone with D6 - I don't have a copy so used D5's location). I think including Off-line (and Online)'s URL is important since, unlike custom themes and modules, it's a relatively hidden use-it-once-then-forget-it feature.
Comment #16
Morbus Iff(Also, note the use of ?q= in the Off-line URL was deliberate, to prevent the need for Clean URL considerations.)
Comment #17
KentBye CreditAttribution: KentBye commentedFirst off, there's a referential error in step #2. It says that you access update.php in step #11, and it's actually step #10.
And in reading through the patched version, and it might be good to mention in Step #2 that there is a workaround if you don't have access to log in as UID = 1. Say for example that you have someone else set up your Drupal site, but eventually you take over control and want to update the site yourself -- there seems to be a workaround to this scenario, but it isn't mentioned until Step #10.
Here's Step #2:
And isn't this special note in Step 10 referring to the fact that you wouldn't have access to update.php when you're not UID = 1?
And if so, then isn't it actually possible to run update.php without being UID=1 as long as you make this change?
So in step #2, it isn't entirely true that update.php "can only be run by this user."
So here' what I would propose changing Step #2 to:
Comment #18
KentBye CreditAttribution: KentBye commentedHere's a patch off of Morbus Iff's latest consolidation with my suggested change for #2 included.
Comment #19
KentBye CreditAttribution: KentBye commentedRe: "a link to where Off-line mode lives (which needs to be checked by someone with D6 - I don't have a copy so used D5's location)"
Yes, the link to http://www.example.com/?q=admin/settings/site-maintenance is correct for D6.
Comment #20
KentBye CreditAttribution: KentBye commentedOops. I said "UID=1" in my proposed change in Step #2 -- instead of "user ID 1"
Fixed in this patch.
Comment #21
Morbus IffI can't repatch right now, but error Kent: "#10 if you are unable log on". Missing "to".
Comment #22
KentBye CreditAttribution: KentBye commentedThanks Morbus
New patch adds missing "to."
Now correctly reads "#10 if you are unable to log on"
Comment #23
Gábor HojtsyAs far as I see, all our concerns are addressed, so committed. Thanks!
Comment #24
(not verified) CreditAttribution: commented