Creating Simplest Instructions for Updating Single-Site D5 Site -- "delete sites directory"
I'm trying to figure out the simplest instructions possible for someone doing a point release upgrade on D5 (e.g. 5.6 - 5.7) who will not be doing it from CVS. (I couldn't find it in the handbook a page which specifically describes point release upgrades, I guess I missed it?) My question is, Is it appropriate to recommend to someone performing a site upgrade that they should just delete the sites directory from the fresh distro they downloaded? So the entire instructions would be. 1. back-up db 2. back up drupal directory 3. download tar ball 4. Untar tar ball 5. delete sites directory from fresh untarred drupal directory 6. Move all files and folders over to drupal directory on your site. 7. When FTP client says "okay to overwrite" say "yes" for all. Let me know if this is correct. Thanks, Shai
On Feb 3, 2008 5:51 PM, Shai Gluskin <shai@content2zero.com> wrote:
I'm trying to figure out the simplest instructions possible for someone doing a point release upgrade on D5 (e.g. 5.6 - 5.7) who will not be doing it from CVS. (I couldn't find it in the handbook a page which specifically describes point release upgrades, I guess I missed it?)
There is a page for "big" upgrades and it's basically the same for point releases: http://drupal.org/upgrade/
My question is, Is it appropriate to recommend to someone performing a site upgrade that they should just delete the sites directory from the fresh distro they downloaded?
So the entire instructions would be.
1. back-up db 2. back up drupal directory 3. download tar ball 4. Untar tar ball 5. delete sites directory from fresh untarred drupal directory 6. Move all files and folders over to drupal directory on your site. 7. When FTP client says "okay to overwrite" say "yes" for all.
Let me know if this is correct.
That's pretty similar to how I often do it (I do upgrades on so many sites it's not funny, so sometimes I use this, sometimes I use other methods). They may also need to visit update.php A slightly safer way to do it is to add a step 2.5 "remove all files on the server except for the 'files' directory and the 'sites' directory and anything else you may have added." The reason that's safer is that there is a chance that a new release removes some insecure files from the server which your process wouldn't capture. I also feel it's important to read the release notes for the new release (e.g. Drupal5.2 required people to edit or replace their settings.php which wouldn't be covered in your instructions and is probably more information than most people need to see http://drupal.org/drupal-5.2 for details). I'd suggest using SCP (perhaps via FileZilla) instead of FTP. FTP is just not safe enough any more. While the goal of "simplest upgrade instructions" is a good one, there are so many "but if X happened then you should also know Y" that it makes it really hard to do. Thanks, Greg -- Greg Knaddison Denver, CO | http://knaddison.com World Spanish Tour | http://wanderlusting.org/user/greg
What I've been doing lately is having the directory structure on the web host include version numbers. ie, my current docroot is drupal-5.7/ (exactly as the result of untarring gives you). When a new release comes out (after backing up the DB), I can just copy sites/ in and visit upgrade.php if necessary, without the harrowing experience of actually overwriting existing files or needing to worry about not deleting files that are no longer used. This way I just have to change the pointer in my web site's configuration to point to the new directory (either with DocumentRoot in apache or whatever panel interface your host gives you), and if things go badly, you can just switch it back and re-implement the database from the backup. If you want to be extra careful, you can configure the old site to actually use a backup of the database ahead of the initial switch, such that you can switch back without even the downtime of having to restore the database manually afterwards. -- Tony Yarusso http://tonyyarusso.com/
Greg, Tony, All, Greg -- great point -- sometimes the settings.php file itself changes, so you can't assume that you can always use your old one. I like the emphasis on reading the release notes. So my follow up to Greg is: for people who install via "cvs update" -- do they need to read the release notes also? What happened with them on the 5.2 upgrade? Can CVS update a settings.phpfile correctly without overriding the db connection info? Also re: Greg -- yah, it's probably cleaner to delete all the drupal files first (but not files and sites) before moving over a new install. On one site that I have we have a bunch of other directories in the Druapl directory (probably not a good idea) and this makes trickier when upgrading, need to pay attention to which directories are Drupal related, which not. That's why I thought the overwriting the old directories made sense in that situation. And thanks for the reminder not to use FTP. I presume SFTP is good enough, yes? And to Tony... great description of a method that allows for a total/simple fallback when disaster strikes. However, your method still requires moving the old "sites" and "files" directory to the new install. It's a very clean approach, but still requires those files and sites directories to be moved around. Shai On 2/3/08, Tony Yarusso <tonyyarusso@gmail.com> wrote:
What I've been doing lately is having the directory structure on the web host include version numbers. ie, my current docroot is drupal-5.7/ (exactly as the result of untarring gives you). When a new release comes out (after backing up the DB), I can just copy sites/ in and visit upgrade.php if necessary, without the harrowing experience of actually overwriting existing files or needing to worry about not deleting files that are no longer used. This way I just have to change the pointer in my web site's configuration to point to the new directory (either with DocumentRoot in apache or whatever panel interface your host gives you), and if things go badly, you can just switch it back and re-implement the database from the backup. If you want to be extra careful, you can configure the old site to actually use a backup of the database ahead of the initial switch, such that you can switch back without even the downtime of having to restore the database manually afterwards.
-- Tony Yarusso http://tonyyarusso.com/ -- [ Drupal support list | http://lists.drupal.org/ ]
On Feb 4, 2008 2:08 AM, Shai Gluskin <shai@content2zero.com> wrote:
Greg, Tony, All,
Greg -- great point -- sometimes the settings.php file itself changes, so you can't assume that you can always use your old one. I like the emphasis on reading the release notes. So my follow up to Greg is: for people who install via "cvs update" -- do they need to read the release notes also? What happened with them on the 5.2 upgrade? Can CVS update a settings.php file correctly without overriding the db connection info?
Yes, "cvs up" would handle that. But if you use multisite or use a domain specific directory instead of the "sites/default/settings.php" then you would need to edit the other settings.php files manually. (but if X happened then you should also know Y...)
Also re: Greg -- yah, it's probably cleaner to delete all the drupal files first (but not files and sites) before moving over a new install. On one site that I have we have a bunch of other directories in the Druapl directory (probably not a good idea) and this makes trickier when upgrading, need to pay attention to which directories are Drupal related, which not. That's why I thought the overwriting the old directories made sense in that situation.
Right - that works probably 99% of the time. But just in case a file is removed...
And thanks for the reminder not to use FTP. I presume SFTP is good enough, yes?
"Good enough" is all relative of course, but yes, I think SFTP is good enough for most uses. As long as it gets the password into something even mildly encrypted it will stop most sniffers. Also, thanks to you, Shai, for seizing this opportunity to gather information and update the handbooks. Well done. Greg -- Greg Knaddison Denver, CO | http://knaddison.com World Spanish Tour | http://wanderlusting.org/user/greg
Quoting Shai Gluskin <shai@content2zero.com>:
Greg, Tony, All,
Greg -- great point -- sometimes the settings.php file itself changes, so you can't assume that you can always use your old one. I like the emphasis on reading the release notes. So my follow up to Greg is: for people who install via "cvs update" -- do they need to read the release notes also? What happened with them on the 5.2 upgrade? Can CVS update a settings.phpfile correctly without overriding the db connection info?
The answer to that question can be found here[1]. As you can see there is no settings.php file in CVS. Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
Earnie, I'm on the edge of my seat to learn about how cvs handles settings.php... The hyperlink wasn't hyper :) in your post. Shai On 2/4/08, Earnie Boyd <earnie@users.sourceforge.net> wrote:
Quoting Shai Gluskin <shai@content2zero.com>:
Greg, Tony, All,
Greg -- great point -- sometimes the settings.php file itself changes, so you can't assume that you can always use your old one. I like the emphasis on reading the release notes. So my follow up to Greg is: for people who install via "cvs update" -- do they need to read the release notes also? What happened with them on the 5.2 upgrade? Can CVS update a settings.phpfile correctly without overriding the db connection info?
The answer to that question can be found here[1]. As you can see there is no settings.php file in CVS.
Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
-- [ Drupal support list | http://lists.drupal.org/ ]
Quoting Shai Gluskin <shai@content2zero.com>:
Earnie,
I'm on the edge of my seat to learn about how cvs handles settings.php...
The hyperlink wasn't hyper :) in your post.
Excuse the brain fart. [1] http://cvs.drupal.org/viewvc.py/drupal/drupal/sites/default/ Earnie -- http://for-my-kids.com/ -- http://give-me-an-offer.com/
participants (4)
-
Earnie Boyd -
Greg Knaddison - GVS -
Shai Gluskin -
Tony Yarusso