(No drush!?!? #inconceivable)
With all of the fancy ways to upgrade Drupal core floating around: drush, git, diff, patching. What if you only have FTP?
As always, the first steps are to a) plan, b) backup, and c) be flexible.
It always helps to have a plan. Write it down, think it through, practice on something other than your production site.
The basics for updating a Drupal minor version (eg., 6.20 to 6.22) are that you need to save your /sites folder and anything that you've made changes to outside of the /sites folder. Usually those changes might be to .htaccess or robots.txt. If you've made any changes to core files, hopefully you've done so systematically taking notes so that you can try to recreate those changes. Or even better that you created a patch file or have things under some sort of version control, but we're assuming low tech.
If you're moving files about by FTP, a reasonable process might be to download the /sites directory to your local machine. Then download the new version of Drupal locally and unpack it. Get rid of the /sites directory that came with the new version and drop in the recently downloaded copy of your old /sites directory. Now, upload the whole new directory to a separate location on your FTP server. Hopefully in the same parent folder that your existing Drupal site is served from, but with a different name. For example, if your directory structure looks like /home/username/public_html/drupal, you can upload to /home/username/public_html/drupal-6.22.
Then rename the drupal directory to drupal-6.20 and the drupal-6.22 directory to drupal. Now your webserver will be looking at the new files instead of the old ones.
Next backup your database and then visit update.php on your site, following all of the instructions to perform any database alterations.
This should be all of the steps necessary for one or two jump minor upgrades. Going from Drupal-6.4 to Drupal-6.22 might take a little more effort.
Also, some errors, quirks may be due to contrib modules acting differently with different versions of core. Most contrib modules try to keep updated to work with the latest core, so updating contrib modules at this point would probably be a good idea.
The benefit of this approach is that you don't have a lot of downtime while files are being uploaded. Also, you can moderately easily restore to the older version by renaming the folders again in reverse (drupal becomes drupal-6.22 and drupal-6.20 becomes drupal) and then restoring the database from the backup you made.
The official documentation recommends setting the site offline, disabling all contrib modules, setting the theme to Garland, performing the update, then reenabling modules, setting your theme back, testing thoroughly and then putting the site back online. The general consensus that I've seen in IRC, forums and blogs is that this is unnecessary for most installations. Perhaps if you have tremendous amounts of traffic or very complex sites you should consider these more detailed solutions. However, if you have that much traffic or very complex sites then command line tools and development, staging, and production deployment workflows are probably just as important.
However, having a separate copy of the site to practice on is invaluable and should be the first thing that anyone does for a site that they can't afford to have unavailable for a while.
Comments