Drupal Association members fund grants that make connections all over the world.
If you have previously determined that you do not need to update your database, you may skip the following step. However, it does not hurt to run the update.php script just to verify whether or not a database update is necessary. Just make sure that you have made a backup of your database first.
If you set up a test site, you are going to be running update.php on it instead of your existing, live site.
Depending on your site, you may need to log in using the following URL: http://example.com/?q=user
I. Did you login as USER 1? (Drupal 6 and earlier)
Previously, you were asked to login as USER 1, the root user, the first user created on your Drupal site. If you are logged in as user 1, skip to part II. If you were not able to do so, you will need to edit the update script in a text editor. Otherwise, you will not be permitted to update the database. Change
FALSE for the $access_check statement like so:
When upgrading to Drupal 5.x, alter in /update.php:
$access_check = FALSE;
When upgrading to Drupal 6.x, alter in /sites/default/settings.php:
$update_free_access = TRUE;
After you complete the upgrade, be sure to CHANGE the update.php file BACK TO ITS ORIGINAL STATE if you have made this change. Otherwise, anyone would be able to run the update.php file on your site.
Note: To run update.php in Drupal 7, you need to log in with an account that has the "administer software updates" permission enabled.
II. Run update.php
In your web browser navigate to the directory where Drupal is installed:
http://www.example.com/update.php or http://www.example.com/test_site/update.php (if you are upgrading a test site)
The update script should only be run once. It will complete all the updates at once. If prompted for which version, choose the closest starting version that makes sense for you.
This will update the default Drupal and contributed module database tables automatically (versions prior to 4.7 will require manual upgrade of the contributed modules). Once the script has stopped loading, be sure to scroll to the bottom to look for errors.
If you are doing an upgrade from a previous major version, you should have disabled modules during the preparation step to avoid errors caused by a mismatch between the code and database schema version. Unfortunately, this might lead to problems while running update.php. As of Drupal 6.x, the update script does not distinguish between enabled and disabled modules; updates are attempted for all installed modules. However, a module may require to be already enabled during an update, or it may even require some other, prerequisite module to be enabled. Unfortunately, not all modules' authors make these assumptions explicit through sensible warning messages. If you encounter errors during update.php, especially ones referring to an undefined function, you may wish to retry after enabling modules (preferably after finding out which disabled module provides the missing function).