Last updated May 30, 2013. Created by webchick on September 26, 2007.
Edited by ehowland, mlhess, Gaelan, rethinkwebdesign. Log in to edit this page.

The Update manager (Drupal 7) and Update status (Drupal 6) modules periodically check for new versions of your site's software (including contributed modules and themes), and alert you to available updates.

The log of available updates will indicate when new releases are ready for download, and you may configure various options, including frequency of update checking and notification options (which are performed during cron runs), at the respective module settings page if you have administration permissions.

Please note that in order to provide this information, anonymous usage statistics (consisting of a unique key and a list of versions of the software your site is runnning) are sent to Drupal.org. If desired, you may disable the Update status module from the module administration page.

If you have checked out Drupal code via Git instead of installing a release tar.gz archive you downloaded from drupal.org, you will need to install and enable the Git Deploy module.

Update manager (Drupal 7)

Performing updates through the user interface

The Update manager also allows users with the administer software updates permission to perform updates directly through the administration interface. At the top of the modules and themes pages you will see a link to update to new releases. This will direct you to the update page where you see a listing of all the missing updates and confirm which ones you want to upgrade. From there, you are prompted for your FTP/SSH password, which then transfers the files into your Drupal installation, overwriting your old files.

Installing new modules and themes through the user interface

You can also install new modules and themes in the same fashion, through the install page, or by clicking the Install new module/theme link at the top of the modules and themes pages. In this case, you are prompted to provide either the URL to the download, or to upload a packaged release file from your local computer. Click Install, and the files are copied into your sites/all/modules folder. See Installing contributed modules for more details.

Using Update Manager Without FTP

FTP is not required to install new modules or themes. If you have access to ssh for your web host you can enable Update Manager by ensuring that file ownership for your Drupal site (or at least sites/default) is set to the same user that runs the web server. This is often apache or www-data. An example of a command to accomplish this would be...

sudo chown -R www-data:www-data /var/www/drupal
or
sudo chown -R apache:apache /var/www/drupal
depending on your distribution.

There are security issues with doing the above. Please check with your system administrator first.

Disabling user interface code updates

If your site is relying on an external deployment system (perhaps with a staging and production workflow), you can disable all of the functionality that allows site administrators to install code through the administrative user interface by placing the following line in your site's settings.php file:

$conf['allow_authorize_operations'] = FALSE;

You will still be able to run the Update manager to check the status of available updates, but you will not be able to install those updates or new modules and themes directly via the web interface.

Update status (Drupal 6)

Additional functionality is provided by the Update status advanced settings module.

Note: In Drupal 5, this functionality is provided outside of Drupal core by the contributed Update status module.

Technical details for Drupal 7

Core module: Yes.
Dependencies: None.
Related Modules: None.
Permissions: None.
API Documentation: update.api.php, update.authorize.inc, update.compare.inc, update.fetch.inc, update.install, update.manager.inc, update.module, update.report.inc, update.settings.inc, update_test.module,
Template files: None
Other files: update.css, update.info, update-rtl.css
Database tables (1):
cache_update. Also see the API docs at update schema.

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

Comments

I've been attempting to use the Update Manager in the last couple D7 versions. I'm now using RC1. I've never been prompted for a password. I've been experiencing some problems and very mixed success with the Update Manager, but this is probably not the place to mention those issues. But this documentation about the password seems incorrect.

Seems that D7 Update Manager require VALID LOCAL USER - on YOUR WEB server
In other words you should use VALID User/Password when Update Manager ask you.
I try installing new module "Variable" using upload from my PC, via SSH (drop-down box) - NOT Ftp. And it Says That module was installed - BUT IT IS NOT Available under installed modules.
Not sure what happens !

I try with user that have NO root privileges.

btw. to have SSH as option in drop-down box, you need libssh2 for PHP installed.

....

I just try it again - using user with Root privileges. And installation was Successful.

I posted here initially because this documentation seems wrong to me. I've never been prompted for a password by the Update Manager in D7. The update manager has been working fine for me for the last 10 or 11 months, and I really appreciated it, by why does this documentation page talk about passwords in the Performing updates through the user interface paragraph?

I have been experiencing the same problem. I have searched for documentation on the Update Manager and everything I find says that D7 will prompt me for an FTP or SSH login in the in-site module update process. It never has. I select a module to update, it says it is downloading it, then it says it is ready to install, I tell it to use maintenance mode, it fails. Same thing, every time. Never has it prompted me for a password, and I don't know why. I've resigned myself to having to update the modules manually or using drush. If anyone knows the fix for this, please let us know. I've searched around and this is the first place I have found someone with the same issue.

Same Problem TheLioness22 and David D. Any solution?

Just be aware that if your site uses suphp, you need to change the umask in suphp.conf from 077 (the default) to 022. If not, Apache won't be able to serve your static files (they need to be readable by www-data, since suphp don't serve them).

--
Håvard Pedersen
Web developer at Norwegian Centre for Integrated Care and Telemedicine, working with eLearning for the health sector.

How do I update from Drupal 7.2 to 7.4?

1) Download the new version (7.4 in this case) from here http://drupal.org/download
2) Extract it's content
3) Copy and paste the newly extracted 7.4 folder to wherever your 7.2 folder currently is.
4) Delete the sites folder from your NEW 7.4 version NOT from your current 7.2 version (as your going to copy all your existing content from your current 7.2 version in here)
5) Copy the sites folder from your 7.2 version into the 7.4 version folder
6) Delete 7.2 folder completely - you will have this named after the website your working on. (again just make sure you've copied out your sites folder)
7) Rename the 7.4 folder to whatever you previously had named for your website
8) Add /update.php when you first login to your new 7.4 site just to check to see if any module updates are available.
That's it.

All changes made to drupal are outside the sites folder. This sites folder is effectively your old 7.2 site from a perspective of content to keep.

Hope this helps

Phil

Copy back and forth?? Makes no sense

OK - I must be STUPID as I can't get even a minor update to work without crashing my sites. According to the directions, I put my in maintenance mode, then copy off the SITES directory. Next, I delete all of the files EXCEPT the SITES directory and upload the new stuff (except for the SITES directory). Next, I try to run the UPDATE.PHP - and yes, I have a site that no longer works!!!

If someone could break this down a little better, I would be happy. What is the definition of CORE DRUPAL Files?? EXACTLY what files are considered CORE?

I followed Kingfisher64's instructions updating from 7.2 to 7.7 and have no problems. Put shortly: unpack or upload a complete new Drupal installation next to the existing one, then replace the new installation's sites folder with the old sites folder, then delete the old folder (I just renamed it, so that I might have used it for backup. Will delete after further testing) and rename the new folder from e.g. 'Drupal-7.7' to the folder name of your old, now renamed or deleted drupal site folder.

http://geradezu.dk - Beratung und Gestaltung im Bereich online Präsenz

When you download a fresh copy of Drupal -- everything you that ISN'T inside the /sites folder is considers core. If you are changing anything other than what's in the /sites folder (and sub-folders) you are hacking core and therefore in for it when you need to update.

What FTP login? The one I use to log into the FTP server on which Drupal is running? I don't get it... why would I need to provide that if it's already downloaded the update file locally to the server?

Doesn't work anyway.

I've tried 127.0.0.1, localhost, the hostname of the machine... nothing.

Hi there,

I updated my modules in D7, and everything is ok for most of them. But two of them are saying that un update is available, even if the date corresponds to the last available version.

Have you seen that before?

I tried to do it again, delete the modules, run update.php, and reupload the latest version, but nothing changes for those modules (i18n and variable).

Thanks for your ideas!
U.

I am experiencing the same issue as ulysse68, but on Drupal 6. I have three modules that are not registering as being updated even after I have updated them. These are Comment notify (status currently reporting it as 6.x-1.5 and recommending 6.x.1.6), Quick Tabs (reporting 6.x.2.0-rc5 and recommending 6.x.2.0), and the Fusion theme (reporting 6.x-1.1, recommending 6.x-1.12). I have, ftp'd and extracted all of these modules (as I usually do on crappy hosts that I can't run Drush on...), run cron, update status check, and it always reports these modules as not updating. I noticed this the other day with just the two modules, and now there are three, so I'm pretty sure it isn't the fault of the modules. Another point, the host, netfirms, recently made some hosting upgrades and changes, and now 'register_globals' is enabled (I have requested that it be disabled...) and the cron has stopped running on the hour and I need to manually kick it off... so there is certainly some issues with this shared hosting... but I didn't think any of that would impact the core update status module...

I found an (ugly) workaround: I set the 'datestamp' manually to a recent date (copied from another module)... and it now appears in green ;)

For the record, the updated files are [module_name].info, in each module folder.

U.

I get the error:

* Error installing / updating
* File Transfer failed, reason: Cannot create directory /is/htdocs/wp1174125_Y2HN1MV9U4/frankspade/drupal7/sites/all/themes

even though I changed the temp file location to "temp".

Where does the update-manager get the temp folder location from?

Frank Spade
Berlin, Germany

Hello, I am user 1 on a D7 site I'm building for a client. I get the emails sent by Update Manager about security and module updates available. The client has admin role and naturally see the security / update notices when they appear on top of pages.

Is there a way the admins from seeing these notices so he/she doesn't panic ?

Disabling permissions for "administer software updates" and "view site reports" didn't do the job. Admin still sees "There is security update available for you version of Drupal .... "

I can't test this myself as the D7 site I'm working on is up to date, but you might see if setting Error messages to display to None at admin/config/development/logging does the trick (if you aren't set up that way already).

Or you might consider creating a custom role other than admin for the client?

http://geradezu.dk - Beratung und Gestaltung im Bereich online Präsenz

I tried installing Drupal 7 using symbolic links to keep the custom stuff out of the version specific Drupal tree with the intent of making core updates easier.

The directory structure I have is

/var/www/drupal - all Drupal stuff is in here
/var/drupal-7.x/...  - Drupal core
/var/www/drupal/SITES - all local content normally in drupal-7.x/sites
/var/www/drupal/MODULES - all local content normally in drupal-7.x/sites/all/modules
/var/www/drupal/THEMES - all local content normally in drupal-7.x/sites/all/themes

the relevant directories are then replaced by symlinks (so drupal-7.x/sites -> /var/www/drupal/SITES).

I also have a symlink /var/www/drupal/current -> /var/www/drupal/drupal 7.x, so my Apache conf has that as Document Root

This seems to work (almost) perfectly and it makes installing a new version of core very simple - I only need to install the new version, change two symbolic links & run the update script.

However, the only thing it seems to break is the update manager. Updates done through the Drupal Update Manager give errors such as

Error installing / updating
File Transfer failed, reason: /var/www/drupal/MODULES/imce_mkdir/LICENSE.txt is outside of the /var/www/drupal/drupal-7.8

Is there anything I can do to make Update Manager work using my configuration?
Is there any reason I'm not aware of as to why my configuration is a Bad Idea?
Is this something that could/should be added as a feature request?

[If it's any help the errors are generated by authorize.php. I did take a look at the code, but it's way beyond my knowledge of php.]

I'm using drupal 7 with a multi-site setup and set up update manager to send a notification, when new updates are available.

But unfortunately I do not get any e-mail. Is there a special trigger necessary?

With the way Drupal operates in the real world, with modules that are never in "release" versions, it is pretty useless to have a module that does one button updates to the latest module versions when in 95% of the cases, the modules you need are the dev versions. Is there a way to select the version you want? Can you hard code somewhere a new path to find the dev versions? Can we add this as a configuration option? I've been using Drupal for 7 months now and update modules every other day, very frustrating.

This would be a very handy feature.

That would be very handy indeed, especially when there are as many semi-core modules affected by this, like Views, Date, Calendar, etc.

I propose adding a new attribute to the update schema 'version_stream'

This could have values of 'dev', 'alpha','beta', 'test', release' etc.

If you have a given stream installed, by default you stay on that stream unless you choose to switch to another stream.

Also, adding something like 'version_build' as well would allow a formalisation of the current defacto versions I seem to see are common place.

7.x-1.2-alpha2

api_version + '-' + version_major + '.' + version_patch + '-' + version_stream + version_build

It would be really useful if you could choose to upgrade any module, including those already at the latest release version, and then get a form like the admin/modules/install form, where you could input a url or upload a module release. This would allow for flexible installation of dev releases, module development and debugging.

JZ

I would think this would be one of the most important features to add to this function. I am still struggling with trying to find out what version is what. I either have to look in the uprade page or in some cases look in the modules folder and find what dates are on the files. Part of the problem is that a release is numbered rev 4.1, 4.2 etc. But a dev release in most cases keeps the same name no matter how many releases it goes through. I personally believe that the standard naming structure is incorrect also. Dev releases should not be 7.x-1.x-dev. This is a very poor and confusing naming scheme. There MUST be a build number at the end at the very least. But frankly the "x" needs to go away too. What is wrong with 7.0-1.99-dev or 7.1-1.1-dev-99?

I wil sum up what I reported on http://drupal.org/node/842620

------------
I am using Drupal 7.10 on two environments: (1) Debian Linux test server using root for everything and (2) hosted sites on third-party companies all using Linux limited users.
Drupal 7 update manager works correctly on situation 1.
On situation 2, I got the message below:
•Error installing / updating
•File Transfer failed, reason: Unable to change to directory /sites/all/modules/pathauto.

Are limited users provided by host companies a problem to this update method?
MySQL user and Hosting/SSH/FTP user are different names/passwords. Does it matter?
www/sites/all/modules/ is drwxr-xr-x. Should it be 777?

------------
Is it possible these scripts provide username, password, source path, source file, source path permission, source file permission, destiny path, destiny file, destiny path permission, destiny file permission, error on reading or writing and any more information to help developers to identify and solve the problem when we report here?

If any one can provide this hack, I can test on the sites where I have the problem always happening.

Since 01/07/2010, it is more than 18 months. I insist on this feature because Drupal 7 release has a focus on user experience, accesibility and usability of the system to make it easier to use.
http://www.linuxforu.com/2011/12/dries-buytaert-interview-drupal-8-busin...
http://www.centernetworks.com/interview-drupal-founder-dries-buytaert
http://devworks.thinkdigit.com/Features/Interview-Dries-Buytaert--Creato...
------------
I volunteer myself to make tests on some environments where the problem happens to provide debug info or hints.
Can you provide hacks or scripts to make those tests?
------------
Maybe, it would also be good if the patch inform os (operacional system: Linux, Windows, MacOS, etc), total ram, free ram, free space on disk, etc.
------------
VeryCool78, I tried both users www-data and apache, but the hosting service uses a different username and does not inform which is... they said I have to work with my own regular user since it works perfectly on any ssh and ftp program (it really works!). They also said this a Drupal's update tool problem that does not happen on Wordpress update tool.
------------
Staratel, thanks for your help. I will check the modules you informed.

But I still believe that Update Module itself should provide more information to help administrators that are not php developers and cannot debug the sources to solve the problem or at least help those administrators to fill up bugreports with all needed information to identify and fix the problem.

I believe that important part of the problem is that I do not have control over apache, ftp, etc servers because my site is hosted on a third party hosting company.
------------

What information could I provide to help solving this out?

@valdir.marcos, you are not alone in this thread in doing this, but you are talking about a bug with the code, so you should really be posting this as a core issue here: http://drupal.org/project/issues/drupal
You should review the existing issues there to determine whether your issue has already been posted about, before creating a new issue.

I was the first to post a comment here, but I was raising an issue about Drupal documentation right here on this page, not a bug or some other issue with Drupal code. If you post in the Drupal core issue queue, there is a much better chance that core developers (who may be able to respond in a meaningful way) will actually see your post. This page is documentation only.

Thanks, David D.
After search, I have created a bugreport:
http://drupal.org/node/1409286

Not all server environments support FTP due to security issues with anonymous users, or sending passwords in the clear for registered accounts. So in order to bypass the FTP login for Update Manager, apache must own the default folder (but nothing more!).

chown apache sites/default/

Note: the settings.php file inside the default folder contains the database connection string in clear text. This needs to be locked down:

chown rob:nobody sites/default/settings.php
chmod 640 sites/default/settings.php

This way, I can still edit the file, apache's group can read it, and "other" is denied.

By the way, one way to determine the user and group apache is running under is to go to the appropriate apache conf file and look for this syntax:

User apache
Group nobody

And as you mentioned earlier, apache needs to be able to write to the themes and modules folders:

chown -R rob:nobody sites/all/themes/ && chmod -R 770 $_
chown -R rob:nobody sites/all/modules/ && chmod -R 770 $_

I've been banging my head against the wall for the past few days, and this is the best workaround I could come up with. If this violates any best practices, please let me know.

When inserting hook_install code in my install profile I can see in my database that the property is well set (in {system} database the 'status' field is being set to '0').

<?php
/**
* Implements hook_install().
*
* Perform actions to set up the site for this profile.
*/
function base_profile_install()
{
 
//disable update manager
 
module_disable(array('update'));
}
?>

Unfortunately this is reset somewhere so I can't seem to disable this module. Probably for good reasons, but in my case I want this disabled. Anything I'm doing wrong (or real stupid)?

Thanks in advance for the replies.

The specified file temporary://fileJobHBR could not be copied, because the destination directory is not properly configured. This may be caused by a problem with file or directory permissions. More information is available in the system log.
http://ftp.drupal.org/files/projects/rate-7.x-1.6.tar.gz could not be saved to temporary://update-cache-8f010407/rate-7.x-1.6.tar.gz.
    Downloading updates failed:
        Failed to download rate from http://ftp.drupal.org/files/projects/rate-7.x-1.6.tar.gz

That's the message... it started to appear after I changed the User on the server for this domain. Any clues?

Hi,

I have D7.21 on Centos 6.3 and Apache 2.2.15 and PHP 5.3.3
Installed Drupal Commons installation profile.

This webserver is behind a network proxy used to connect to the web.

I read on many sites about D7 now being able to handle http requests through proxy, and i setup my settings.php file according.
But I cannot get updates..

It keeps failing.. need some pointers. Do I need to setup Apache to be able to handle these requests from its own sites?
Any help would be great!

UPDATE:
Found the error!! It always bugs me that other get their error solved, but never post what solved it, so here's the solution to my problem:

The clean URL's was not working properly. Had to set the mod_rewrite corretly as shown in this post. Even if my clean URL's was set in Config->Search- Metadata->Clean URL's i set it again..

After this the HTTP request from the update manager worked!

Hope this might help anyone out there..

Hi all,

I'm pretty new to Drupal, so excuse any naivety.

I am getting the same issue as many are posting here. I do have my FTP log in information, however at no point in the update process am I being prompted for it. The update just begins and fails.

I have been unable to 'update script' lately and I don't know how to change that! Anyone??? I recently added an "Add-on Domain" and things were going just fine at first ... did I inadvertently change something? Perhaps it's that the "Add-on" is using 7.24 and my regular site is using 7.22? I really need help! Thanks!
I cannot install new modules the regular way either. When I select 'install' nothing happens on either site.