[support] Creating Simplest Instructions for Updating Single-Site D5 Site -- "delete sites directory"

[Shai Gluskin]

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 at 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/ ]
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/support/attachments/20080203/50a73a7b/attachment.htm