Last updated 16 August 2017. Created on 3 May 2006.
Edited by thomasmurphy, rooby, jhodgdon, krupali mehta. Log in to edit this page.

Update.php matches the database schema to that expected by Drupal's core and modules. See also

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:

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 TRUE to 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:
or  (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).

Looking for support? Visit the forums, or join #drupal-support in IRC.


timothyf’s picture

Since MySQL is still pretty much the preferred database platform for Drupal (though PostgreSQL support is getting much better!), you may be faced with some additional steps in upgrading. I don't know if this is the case in Drupal 5, but the PostgreSQL database schema includes a number of functions, presumably to add a basic level of MySQL compatibility. Your site may be able to run okay without them, but some modules (like forum) won't be able to work without them. These functions don't seem to be upgraded with the update.php script, so when you upgrade, you may have to grab them from the database schema file (under the database directory of the installation). They're near the end of the file, starting with a section named "Functions". Copy these to a separate file and then you can load them with the command

psql [database_name] < [name of file you created]

For reference, here is the contents of the file that I created, based on the 4.7 distribution. You'll want to use whatever's in your Drupal distribution, though.

--- Functions

--- Always installed in 'public' as prefix isn't appended to function names
SET search_path TO public;

CREATE OR REPLACE FUNCTION "greatest"(numeric, numeric) RETURNS numeric AS '
  SELECT CASE WHEN (($1 > $2) OR ($2 IS NULL)) THEN $1 ELSE $2 END;
' LANGUAGE 'sql';

CREATE OR REPLACE FUNCTION "greatest"(numeric, numeric, numeric) RETURNS numeric AS '
  SELECT greatest($1, greatest($2, $3));
' LANGUAGE 'sql';

  SELECT random();
' LANGUAGE 'sql';

CREATE OR REPLACE FUNCTION "concat"(text, text) RETURNS text AS '
  SELECT $1 || $2;
' LANGUAGE 'sql';

CREATE OR REPLACE FUNCTION "if"(boolean, text, text) RETURNS text AS '
' LANGUAGE 'sql';

CREATE OR REPLACE FUNCTION "if"(boolean, integer, integer) RETURNS integer AS '
' LANGUAGE 'sql';
bramface’s picture

Perhaps this is all explained somewhere other than a book.....

Lets say I inherit a database which has not been cared for, and there are many update versions for contrib modules to choose from, starting with 2, 3 and then jumping, say, to 4005, 4006, 4007.

Would the prudent course be to choose the first available (2), and then continue running update, moving up through those? That goes against the dictum "run update.php only once".

On the other hand, say I've leaped ahead (I chose 4005 instead of 3) and run an update that fails, because it is editing a table that looks different than it should, because previous updates had not been run. I assume my only recourse is to go and manually edit the table design based on what the update was trying to accomplish, given its error message. (I can't "un-do" the status of the update, can I?)

So...say I do that. Should I expect my next update.php to indicate that it is time to run update 4006?

Bram Moreinis
Greenfield Digital

TheoRichel’s picture

Have the same problem and cannot find anything on the subject here for three days.

jpl’s picture

If you choose version X in the update select combo, then all updates numbered >= X are automatically executed for this module in their ascending order (not just your selected version X). It's a bad idea to skip individual updates unless you really know what you are doing; as you already noticed, later updates may depend on earlier ones having been executed. You cannot easily undo an update, other than reverting to the database snapshot that you should have created beforehand. If you want to mess around (not really recommended unless you encounter errors), you can see what each update does by inspecting the module.install script.

mirjam’s picture

After I've copied all Drupal 6 files to the right directory, and I'm navigating to my website to login (/?q=user), it's starting a whole new installation of Drupal (/install.php?profile=default), instead of an upgrade. Also when I'm navigating to /upgrade.php, the new installation starts.

Can somebody help me how to fix this? To be sure I didn't loose everything, I've just put everything back to version 5.20, but of course eventually I want to upgrade to 6 :-p.


sohail_arif’s picture

You have to overwrite all files of drupal 6 to drupal 5 directory other than the sites folder of drupal 6 directory. Before running update.php you have to disable all the custom as well as contributed modules.

The same problem i have also faced but the solution is to keep intact the old settings.php file. Then you will be navigated to update page rather than install page.

I hope this will help you.

my.wahyu’s picture

became blank screen with address

My Status Report

Everything is Oke ,.... this happen about 3 -6 days ago!
I do not know/forgot about what I'm doin last days.


Database updates Out of date
Some modules have database schema updates to install. You should run the database update script immediately.

jeffreyblove’s picture

Hi All
I'm updating from 5.16 to 5.21. Update throws many warnings and failures, and the process loses data, renames nodes, disappears the menus ... I know that this is 5x and boring, but I can't get to 6x until I solve this.

I'm sure I am following best practice by disabling all non-core modules before running update.php, but the errors are so numerous and the symptoms are so consistent (two separate site do the same thing on update) that I can't help but think I'm missing a step.
The main symptoms after the upgrade are content paths are moved around, and newer content pieces are missing. The titles of the newer pieces are somehow assigned to older nodes. And, the main menu does not display.

If this sounds familiar to anyone, let me know. I'd love to move to 6x soonest.

Many thanks in advance.

whiteae’s picture

I know this is what the above tutorial reads... but
One way is to change the line in sites/default/settings.php that reads ...

$update_free_access = FALSE;

make it read:
$update_free_access = TRUE;

save the file, then go to:
(change the '' to your actual domain of-course.)
-I usually go to the update url in a browser other than the one I was having trouble with.
After the update runs it is very important to change the TRUE back to FALSE and !! Don't forget to reset the settings.php permissions back to secure if you didn't use a $ sudo command!...

joris.verschueren’s picture

I hope Jeffrey's problems are solved by now, but I don't think you should tinker with the update_free_access settings. It doesn't affect this kind of problem, it only allows you to update or upgrade when you weren't logged in before you started the update/upgrade process. but, by setting the value to 'TRUE' allows anyone to call the update script without logging in.
so, if you have to alter the value, make sure to set it back to false after the update.