Last updated 3 August 2015. Created on 12 September 2012.
Edited by pingwin4eg, lolandese, er.pushpinderrana, kevinchampion. Log in to edit this page.


  1. Visit for a list of security announcements and instructions on how to subscribe to the security announcements mailing list.
  2. Updates should be run on a development site and tested prior to deploying to production.
  3. Some module updates should be treated with more caution than others. For example, permissions related modules that protect entire portions of your site may warrant more thought and testing than other modules on your site.
  4. Consider deploying Drush for your site in order to expedite the module update process.

Before updating anything

  1. Before running updates, navigate to admin/reports/updates/update to see which modules are out of date.
  2. If your site has any custom documentation specific to it, check this documentation to ensure that any modules that need to be updated don't have special conditions or constraints.
    • One such scenario that can happen is if the module has been modified from its original state to tailor it to needs specific to your site. When this is the case, the module either needs to remain outdated, or the update needs to be handled with care to ensure that your site specific modifications are ported to the new module version. Ideally modules should not be modified in this manner, but on occasion this situation does happen (for both sound and unsound reasons).
  3. Navigate to the module update's release notes to evaluate the nature of the changes to the module.
    • For newly released updates, check to see if the update contains features or bug fixes not critical to your website. Consider the value of postponing deployment of the update for non-critical features and bugs if it has not been tested exhaustively yet.
    • If the update is a security fix, evaluate the criticality of the security flaw.
      • Is the affected (sub)module enabled on your site?
      • Does your permissions configuration or module use alleviate security concerns?
      • If these factors combine to alleviate concerns regarding the security flaw, consider delaying deployment of the update until it’s been tested in the wild.
    • Take note if the release notes indicate that the update contains database schema changes that will require running update.php after applying the update.
    • Heed the module author's warnings if the module has undergone dramatic revision or restructuring, which happens occasionally with major point release updates.
    • When ready to update, copy the link to the module package ([module version].tar.gz).
  4. If an update must occur immediately, look for and consider deploying a security-fix-only version of the module. This will exclude bug fixes and new features - and therefore code that is lightly tested - and will decrease the likelihood of problems.
  5. Once you select the version of the module you will deploy, go to the module issue queue and look for new issues created for that version of the module. You may also check for new issues against the development version of the module as new fixes are generally applied to development versions first, before being pushed to a new stable version.
  6. Take note of what the module does so that you will have things to check once it is updated. This is so that you can verify that it has not caused any immediately observable errors or problems.
  7. Take note of the existing module's version number. In the event that you need to revert the update, knowing the correct version to revert the changes back to will be helpful.

How to update a contributed module

Manually (via command line using the tar.gz package)

  1. Place site in maintenance mode (admin/config/development/maintenance)
  2. Backup the site's database
  3. Place the compressed package containing updated module into the modules directory of the site in your Drupal installation that you are updating (often sites/all/modules)

    cd sites/all/modules
    sudo wget[module version].tar.gz

  4. Remove the existing module by deleting the module directory, unpack the new module update, and delete the new module update package

    sudo rm -r [module]
    sudo tar -xzvpf [module version].tar.gz
    sudo rm [module version].tar.gz

  5. Check admin/modules or admin/reports/updates/update to verify that the site recognizes the new module version.
  6. When needed, run any pending database updates by visiting In most of cases, it is recommended to run update.php, so don't forget to run it if db changes are there otherwise codebase is updated and db changes are not updated that cause uncertain issues.
  7. Test functionality
  8. Take site out of maintenance mode

Using Drush

  1. Place site in maintenance mode (admin/config/development/maintenance)
  2. Backup the site's database

    drush sql-dump --result-file=/BACKUPS_path/relative/to/site/root/site-name_$(date +%Y-%m-%d_%H%M).sql.gz --gzip

  3. Download and update a specific module version

    drush dl [module version]
    drush pm-update [module]


    If updating module to the latest recommended release, you only need

    drush pm-update [module]

  4. Check admin/modules or admin/reports/updates/update to verify that the site recognizes the new module version
  5. Test functionality
  6. Take site out of maintenance mode

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


pingwin4eg’s picture

There is also an old page about Updating modules which may be merged into this.