Drush is a very handy tool for upgrading all modules and themes on a site with one command: drush up (or drush upc). It can be used to update only selected projects, by defining the project names, for example drush up zen views cck.

This is however not always handy if you want to automatically exclude some projects, while keeping the rest up to date. Modules and themes might be patched, have new extra files or just have to stay in a certain version, and thus should not be overridden.

Luckily drush automatically respects the settings of the update_advanced-module.

If you have set the "views"-project to update "never" at http://example.com/admin/reports/updates/settings, "drush up views" will show views as "Unable to check status " and respond "No code updates available." (even if there are updates). After setting the update information correctly for each module, you can safely run "drush up -y" to keep all modules up to date.

Additional notes

  • The settings of update_advanced can also be converted to a feature with features and strongarm. This way you can transfer your module-excludes with version control between dev->staging->production -sites.
    • The only variable that needs to be included with strongarm is named update_advanced_project_settings.
  • If there is a recommended release of a module, but you use the dev-version instead and want to keep it that way , it's usually a good idea to set the module to update "never". Otherwise drush may "update" the dev version to the recommended release, even if it's older.
  • Drush will also soon have internal support for locking projects from alteration, with the new "--lock"-parameter. See #446736: Have drush update be told to ignore a module/theme -- simple solution. This means the same effect can be configured directly from drush.
  • update_advanced was part of the update_status module in D5, but was moved to an external module when the rest of update_status became the "update" module of D6 core. Drush uses the core update-module when checking for module updates, which explains why this compatibility exists.
  • This information is currently not in the Readme of either project, but there are issues to get it documented.

Comments

donquixote’s picture

Could someone explain the "--lock" feature further?

donquixote’s picture

greg.1.anderson says:

This patch allows projects to be locked by creating a ".drush-lock-update" file in the project directory. Using a lock file means that if you lock a project in one Drupal instance, that project is also locked for all other Drupal instances on the same codebase (multi-site installs). Lock files may also be manipulated by other modules (e.g. hacked) in the pre-pm-updatecode hook, if desired.

[...]

This is the proposed behavior. I don't know if this was implemented 1:1. Something like this should definitely go into the documentation.

The part that is relevant for me:
Hack contrib project x, and create a file ".drush-lock-update" in the project dir.

firfin’s picture

drush up --lock=module1,module2
would update all modules (except module1 and module2) and run update.php