Included in the project/release directory of the Project module are a pair of scripts that can be used to export XML files that describe all the releases for each project on your site. If the releases on your site are used to represent Drupal modules, these XML files are used by the Update status module (which is included in core as of Drupal version 6). You can also configure these scripts to setup a site for testing the update status module.

Please note: the vast majority of users of the project* suite of modules would never need to do this, since very few sites beyond drupal.org are using project* to keep track of Drupal modules and themes.

project-release-serve-history.php

This script is an ultra-thin PHP wrapper that just serves the .xml files at the URLs expected by the Update status module. To configure it, you need to do the following:

  1. mkdir release-history in your webroot.
  2. Put a copy of project-release-serve-history.php or a symlink to it into the release-history directory.
  3. Create a .htaccess file into the release-history directory with the configuration explained in the comment at the top of the script:
    DirectoryIndex project-release-serve-history.php
    <IfModule mod_rewrite.c>
      RewriteEngine on
      RewriteRule ^(.*)$ project-release-serve-history.php?q=$1 [L,QSA]
    </IfModule>
    
  4. Edit the project-release-serve-history.php script to define the required configuration setting: HISTORY_ROOT. This variable should point to the full path to the directory tree where your release history XML files will live. This does not have to be inside the webroot.
  5. (Optionally): Setup the DRUPAL_ROOT configuration setting if you want to have the script bootstrap Drupal and attempt to update some database tables managed by the project_release module for recording usage statistics when queries come in for available updates for each project.
  6. Populate the XML release history files themselves. There are 2 options:
    • Do it manually
    • Use project-release-create-history.php

    Each approach is described below in more detail.

Manually populating XML release history files

One you have your "release-history" directory setup under your webroot, you need to populate a directory tree of the release history XML files themselves. The directory you defined as HISTORY_ROOT above is the root of your history file tree. Under that, you need a sub-directory for each project you wish to support. Then, each project directory includes files for each Drupal core compatibility (e.g. "5.x" or "6.x") that the project supports. For example, the tree might look something like:

history_root/
            /devel/
                  /devel-5.x.xml
                  /devel-6.x.xml
            /project/
                    /project-5.x.xml
                    /project-6.x.xml
            /signup/
                   /signup-5.x.xml
            /...

Each of these history files is just an XML representation of important attributes about each release compatible with the corresponding version of core. You can find some examples by looking at the live files on http://updates.drupal.org. For example:

http://updates.drupal.org/release-history/signup/5.x

project-release-create-history.php

// TODO

Telling update_status about your site

Once you have everything up and running, the way to tell update_status to use your site for fetching information about available updates is via a special line in the .info file(s) you include with your module(s) and/or theme(s). The name of the variable to set is project status url. So, for example, if you setup everything above at http://example.com/drupal-updates/release-history the .info file for your modules should all include:

project status url = http://example.com/drupal-updates/release-history

Furthermore, your .info files should define the project keyword to tell update status what project they belong to (used to construct the URL and used in the UI within update_status itself). If each module is distributed individually, you should just use the module name as the project name. However, if multiple modules are distributed within a single package, you should use the name of that package for the project.

While you're at it, you should include the correct version string in the .info file for your modules. Keep in mind that update_status expects the version strings to look like the Drupal version strings we use here on drupal.org. See http://drupal.org/handbook/version-info#contrib for more about the format of version strings for contributed Drupal modules and themes.

Note that the project and version keywords are automatically defined in the .info files by the drupal.org packaging script. However, since in your case, your module is being packaged elsewhere, you get to handle this yourself. ;)

So, an example of the extra lines to add to the .info file for a mythical "example_custom" module might look something like this:

project = example_custom
version = 6.x-1.3
project status url = http://example.com/drupal-updates/release-history