Simplified maintenance of contributed modules on a Drupal installation
One of the chores which comes with running a Drupal website is keeping the drupal install and contributed modules up to date. Prior to the Available Updates feature (itself a contributed module in Drupal 5 and core drupal in Drupal 6) this was a manual process. You'd occasionally browse the contributed modules list on drupal.org and hopefully you remember all the installed modules. With the Available Updates feature the system notifies you when your modules are out of date, and it tells you which one. But you still need to do a few things.
The first thing to do is ensure the Update Status module is enabled. Once enabled view the report at http://example.com/admin/reports/updates. Also make sure to visit the settings page and make sure the settings are right for you.
The Available Updates report shows a list of your enabled modules, their version number, and whether they're up to date. It gives extra warning if there is a security update for a given module. It does not show data for modules that aren't enabled. If there are updates it includes links to download the module and to view any README or changelog.
What it does not include is any button which autoinstalls the update. You're left on your own as to how to accomplish this.
F. Adding Modules and Themes is the officially documented methodology for installing contributed modules (and themes). I have been using the SSH method described at the bottom of the page, and a typical session looks like this. It begins by finding the URL for the module to update (or install) either from the module page or the available updates report.
laptop$ ssh server
server$ cd path/to/sites/all/modules
server$ wget -O- http://drupal.org/path/to/modulename-n.n.n.n.tar.gz | tar xvfz -
If you are updating an existing module you MUST, as in ABSOLUTELY MUST, run update.php afterward. You do this by entering http://example.com/update.php in your browser and follow the prompts. It should be a simple matter of clicking confirm three times or so. This script, update.php, causes the newly updated module update things like database tables. In most cases it is an absolute requirement that the module's tables be updated as the module is updated. If you do not run update.php it's likely ugly error messages will print on the page as users browse the site.
There is another way using drush. Drush, or Drupal Shell, is a command line tool useful for Drupal installations. It allows an administrator to log into a server, and at the command line do some of the actions performed through the drupal administration interface.
Usage: drush.php [options] <command> <command> ...
Unfortunately it is not quite that simple. First if your site is configured as a "multi-site" site/example.com/settings.php rather than site/default/settings.php there is a bit of configuration to perform. It also helps to create a shell script or batch file that makes it a bit simpler to run drush.
Drush requires knowing what site it is to run commands against, that way it uses the correct database and other site-specific settings. In multi-site configurations there are several sites/example.com/settings.php files from which drush can get the database URL and other configuration information.
The first thing is in the drush module directory create drushrc.php
$ cp example.drushrc.php drushrc.php
The file is extensively commented so just follow the instructions. For my site I changed $options['l'] to inform drush of the URL for the site and $options['r'] to inform drush the path to the sites files.
On my webserver the "php" command was PHP v4 while the webserver uses PHP v5, and this version mismatch made drush run incorrectly. I had to find the PHP v5 installation and use that "php" command like so:
$ /usr/local/php5/bin/php drush.php
Usage: drush.php [options] <command> <command> ...
-r <path>, --root=<path> Drupal root directory to use (default: current directory)
-l <uri> , --uri=<uri> URI of the drupal site to use (only needed in multisite environments)
-v, --verbose Display all available output
-y, --yes Assume 'yes' as answer to all prompts
-s, --simulate Simulate all relevant actions (don't actually change the system)
-c, --config Specify a config file to use. See example.drushrc.php
coder Run code reviews
help View help. Run "drush help [command]" to view command-specific help.
pm install Install one or more modules
pm refresh Refresh update status information
pm update Update your modules
pm info Release information for a module
sql url Print database connection details.
sql version server Print database server version number.
sql version client Print database client library version number.
sql dump Exports the Drupal DB as SQL using mysqldump or pg_dump.
sql query Execute a query against the site database.
sql load Copy source database to target database.
cache clear Clear all caches
cron Run cron
watchdog show Show the most recent watchdog log messages
watchdog delete Delete all messages of a certain type
sync Rsync the Drupal tree to/from another server using ssh
eval Evaluate a command
$ drush pm info cck
Project Release Date
------- ------- ----
cck 6.x-2.1 2008-Nov-11
cck 6.x-2.0 2008-Nov-05
cck 6.x-2.0-rc10 2008-Oct-08
cck 6.x-2.0-rc9 2008-Oct-06
cck 6.x-2.0-rc8 2008-Oct-02
cck 6.x-2.0-rc7 2008-Sep-09
cck 6.x-2.0-rc6 2008-Aug-15
cck 6.x-2.0-rc5 2008-Aug-14
cck 6.x-2.0-rc4 2008-Jul-10
cck 6.x-2.0-rc3 2008-Jul-03
cck 6.x-2.0-rc2 2008-Jul-02
cck 6.x-2.0-rc1 2008-Jul-02
cck 6.x-2.0-beta 2008-Jun-03
cck 6.x-2.x-dev 2009-Jan-14
cck 6.x-1.0-alpha 2008-Apr-24
cck 6.x-1.x-dev 2008-Aug-01
$ drush pm refresh
Refreshing update status information ...
$ drush pm install itunes
Project itunes successfully installed (version 6.x-1.0).