Revised on Wednesday, 24 August 2011 - to improve update speed.
For updating a Drupal 6 site with Cpanel and phpMyAdmin, such as from 6.20 to 6.22. Updating Drupal 7 core is practically the same, while D7 modules can be updated directly on the site.
Original Drupal instructions are in: http://drupal.org/upgrade/ and the upgrade.txt file of the drupal core. Those instructions take precedence, so use these instructions here at your own risk. They do work well on my particular version of Cpanel and phpMyAdmin.
Multisite/multidomain: if you use these you are probably an intermediate/advanced user. Note that you have multiple settings.php files.
The quick overview is followed by a step-by-step guide:
Overview
Below is for Drupal 6. Drupal 7 only differs in the ability to update to new module versions directly, without downloading to local computer and uploading to the site.
Preparation is essential. Make fresh backups of the code and the database. Go to the status report and download the new drupal core and module versions as shown there to your local computer. Upload the new drupal core version tar.gz file to the site root, that is where main drupal files reside. Extract it and it creates a directory DrupalX.X.
Login as user one, switch to default theme and put the site in maintenance mode.
Delete all Drupal code from the server - except, do not delete and be sure to keep the entire existing "sites" directory, the existing ".htaccess" and "robots.txt" files, and of course the newly uploaded Drupal core tar.gz file. Also keep any non-core file you or the cpanel system might have added ("cgi-bin", ".ftpquota", possibly "php.ini", fantastico, symlinks).
Go into the new dupalX.x directory that was created by the extraction. Here, delete its "sites" directory and the ".htaccess" and "robots.txt" files. Then, move the entire remaining contents of the dupalX.x directory into the root. Delete the remaining empty dupalX.x directory. Run update.php.
Now upload any new module versions. Delete the old modules and extract the new versions. Run update.php. Practically done.
Now re-enable the original theme and take the site out of maintenance mode. Done.
More or less optional, but good to do from time to time: check the new versions of settings.php, .htaccess, robots.txt for significant updates. Synchronise if needed.
Step-by-step
Prepare
Its good to stay organised.
Make a few directories to contain Drupal core, modules and themes. It's good to keep these separate from any specific site files and backups.
-websites --admin ---drupal ----Drupal6 -----drupal-core-v6.22 ------drupal-6.22.tar.gz (downloaded file) -----libraries -----modules -----themes
Make working directories on yhour computer to contain the backups, that is the backup database file and the backup code file. Generally I make a new directory for every backup, so that things don't get confused:
-site --backups --- sitename-121130-v6.22 ---- sitename_drp_complete_121130.sql (database backup) ---- sitename_drp_emptycaches_121130.sql (database backup) ---- sitemane_pubtml_121130.tar.gz (compressed public_html backup)
"drp_complete" is the original, complete database, and "emptycache" is a copy of that database from which I have emptied cache tables that were 1 MiB or larger. This is needed because my hosting service does not allow database uploads with tables larger than 1 MiB. So the emptychache version is the one I re-upload when something goes wrong. If I want to reinstate the complete version, I need to ask hosting support to do it for me (your hosting service's policies may differ).
Backup
Backup the database with Cpanel phpMyAdmin. Before backing up, it makes sense to "Clear cached data" at Site configuration > Performance (this reduces the size of the database contents and may reduce risk of mysql error 1153, for the case that you want to re-install the backup)*.
Then export the sql database tables and save them on your computer. There is now a simplification and slight change with new Cpanel versions. Log into Cpanel, go to phpmyadmin, click on the database name, click export (on the right side). Basically you could use default Quick/minimal options, default SQL and click Go. But, better to immediately add the current date to the name of the backup file. Click Custom, in file name add: _[theactualdate]. Then move to the bottom and click Go. Save the file.
Backup the site's file system in a compressed copy with Cpanel file manager: Open Cpanel, go to file manager, select public_html, check mark select all, click compress, check mark gzipped. Choose a "save as" name such as sitename-pub-html-date-version.tar.gz. When changing file name do not use the "delete" button (it causes a file deletion), but use backspace. Click OK. Find the file in the "public_html" (if not, the "home") directory on the server. Download it to the computer and save it.
These backups are important. Always keep the SQL file and the code base intact and together (they are a pair). Do not mess with them. You absolutely need these if something goes wrong - and it's pretty easy to restore things with these two files.
Download Drupal Core
Find the update on site Home > Administer > Reports > Available updates. Download the new core file and save it on your computer.
Earlier here, I recommended to extract the core on local computer and perform replacement of the "sites" directory, the existing ".htaccess" and "robots.txt" there, then compress and upload the edited version. I considered this safer. Two reasons for a change, one being to eliminate the small risk of losing proper file permissions and two, doing this online with Cpanel is simply faster.
Prepare Update
- Login as User1 - if not, you can't update and may lose access to your site (to fix, see UPGRADE.txt #10) - Switch to Garland theme (D6) or Bartik theme (D7) in Site building > Themes, disable/uncheck all others - Put the site in maintenance mode in Site configuration > Maintenance mode (to get back in: site.tld/user/login) - Turn off (not uninstall) all non-core modules (remember to turn exactly these back on later) -- this is official instruction, yet some specialists say it's not needed to turn them off (generally I don't) -- if turned off, best to make a web page image of the modules overview page to remember which modules are enabled.
Upload New Drupal Core
Upload the new core file Drupal X.X.tar.gz to where your site's Drupal files are located. This is usually public_html or a custom location. Extract it in that same directory. The extraction creates a new directory named DrupalX.X, which contains a complete new core. By the way, this is perfectly safe, because it makes no operational changes to your current Drupal site, yet.
Now delete three items from these newly uploaded drupal core files.
Go into the new drupal core directory that the extraction made, that is the DrupalX.X directory. In this new directory delete the new update's vanilla "sites" directory, the ".htaccess" and "robots.txt". You must remove these here, from the new core, so that when the new core replaces the old core, it does not overwrite highly important existing information.
Under some circumstances it is possible that the ".htaccess" file (and all other .files) can't be seen. In this case log out of cpanel and back in. If this does not help, use a search engine with "can't find .htaccess" for a number of solutions. Last but not least there's FTP/SFTP to see and delete the new core ".htaccess" file. Ok, so that's done.
Deleting Files form Active Core
When deleting files from your original, existing Drupal installation, the basic point is to remove all directories and files that have the same filenames as what is now left in the new Drupal update version, that is the DrupalX.X directory from which you have already removed the three items "sites", ".htaccess", "robots.txt".
Be clear that the active, currently existing "sites" directory, ".htaccess" and "robots.txt" files must not be deleted from the active, currently existing Drupal installation. Also any system files that do not belong to Drupal must not be deleted.
Files in your active, existing Drupal installation that must be kept:
a) your existing "sites" directory contains your active, optional contributed modules, uploaded user files and settings, your specific site settings and your contributed /custom themes
b) your existing ".htaccess" file is likely to have been automatically customised, while you may or may not have made changes to it
c) your existing "robots.txt" file, which may o rmay nothave been automatically adjusted or may contain custom settings
These files are part of your site's content and must continue on into the next version. They must not be deleted.
If your core drupal files are, as is usual, in public_html, we likely also have system files here that do not relate to Drupal. These must also not be deleted. These can be hosting files or cPanel system files. Examples are the "cgi-bin" right at the top of the file list, any sub- or addon domain directories, 400.shtml up to 500.shtml customizable error template files, error_log, php.ini, fantastico and any symlinks. You will still be needing these after the update!
Do not delete, be certain to keep Drupal's "sites" directory, the ".htaccess" file, the "robots.txt" file and all general site system items.
Double-check before deletion: You have made backups of complete public_thml and the database, you are logged in as user1, you have put the site in maintenance mode, you have switched to Garland (D6) or Bartik (D7). You may or may not have turned off contributed modules.
Delete Files: Go to your original Drupal installation and delete all Drupal related directories and files except, do not remove and keep: the "sites" directory, the ".htaccess" and "robots.txt" files and also keep all general hosting and cPanel system files.
A mistake here consumes time. When I mark items for deletion, I always double check both sides: Check the files marked for deletion, are these correct? Check the files marked to be kept, are these correct?
Move Files
After deleting the files as mentioned above, move everything inside the DrupalX.X directory to the directory where you just deleted the active core. That's public_html unless your Drupal installaton is elsewhere. Then delete the empty DrupalX.X directory. You now have a new Drupal core together with your existing important files.
Update
Run update.php. Almost done.
Modules
Check Administer > Reports > Status report for needed module updates. Download the needed modules to your computer through links here. Upload the module tar.gz files to where these contributed modules are located either at sites/all/modules or sites/default/modules. Do not extract them yet.
Delete the outdated installed modules fully from the site. Then extract the replacement module versions.
Run update.php. Almost done.
Consideration 1
The "settings.php" file at sites/defaut/settings.php, ".htaccess" in root and "robots.txt" in root, are using their previous versions. While the likelihood is relatively small, from time to time Drupal also updates the code for these. In that case you may wish to do a manual synchronisation between your custom content and new code. I check on this every so-and-so-many updates.
Consideration 2
Consider to remove unneeded Drupal files - these are all capitalised text (.txt) files. This is not required.
Finalise
Re-enable the original theme and take the site out of maintenance mode. Enjoy all those check marks in the Status Report!
New Backup
While you're at it, this is the perfect time to make an after update backup of the code and the database.
Footnote
Flushing cache ----------------- * In my case, flushing the cache from from Drupal's admin does not always sufficiently clear the cache tables and some will remain over 1.5 MiB.
My cpanel will refuse to re-upload a backup database (set of database tables), if any particular table has content of 1 MiB or more - that's the mysql error 1153. This can happen with Drupal 6, while for Drupal 7 it appears to be a standard occurrence. There are two solutions:
Note that this operation is a bit hazardous if not done right. In all cases, make a full backup first.
Option 1) Make copies right on the server and use those as a server based backup: "Copy database to". On most hosts this will copy the database with its tables - this is your original copy. Make another copy marked as "empty cache". From this copy "Emtpy" (="Truncate") the cache tables that are larger than 1 MiB. This is perfectly ok to do. These caches will rebuild themselves. Do not "Drop" any table! And don't do this with any other tables, you are very likely to lose important web site data. If other tables are 1 MiB or over and this gives a problem for re-uploading a backup, do research if it is ok to empty such a table, or use option 2.
Option 2) If the full backup with tables of 1 MiB content and more is already done ans saved on the pc, and there is no other backup anywhere eles, upload the backup database file to somewhere on your site, inform your hosting service of the issue (error 1153 database table too large), and request a way to solve it. Most likely, at least in my case, they will offer to re-insert the database for you, as long as they can access the database/tables file.