New Maintainer Newsletter

This is the first issue of the Maintainer Newsletter. All drupal.org CVS account holders, which means all users who may be maintaining a contributed module, theme, or distribution on drupal.org, are now automatically subscribed to this newsletter. Other users may optionally subscribe. This newsletter will be used for occasional announcements important for those using CVS and maintaining a contributed project. You can also subscribe to this newsletter via RSS at:
http://drupal.org/maintainer-news

CVS wisdom boiled down into a two page handout

In case you missed the talk at the Boston DrupalCon about how to maintain your contributions, be sure to check out the .pdf for the handout that accompanied the presentation:
http://drupal.org/files/maintain-release-handout.pdf
It's got some invaluable yet concise wisdom about The Right Way(tm) to use CVS for your contribution. Please read this handout now (even if you consider yourself a CVS expert) so that you do things right and don't generate additional support requests for the over-committed CVS administrators.

Drupal 6.2 minor menu system API Changes

The forthcoming point release of Drupal 6.x will feature two minor API changes.

* hook_menu access inheritance.
* one of the core-defined load functions, %user_current.

The primary change is to the handling of access callbacks and arguments in hook_menu. Modules updated to account for this part of the change WILL also work correctly with Drupal 6.1 and 6.0. Thus, we encourage you to make any necessary changes to your 6.x compatible modules as soon as possible, so that there will be no loss of functionality when people upgrade to 6.2.

The first, main part of the API change consists of requiring an explicit definition of the access parameters for each menu router item. Access callbacks and arguments will no longer be inherited by items that might be considered to be children based on their path. The only exception to this is for items of type MENU_DEFAULT_LOCAL_TASK. The function user_access() is still the default access callback, so you may continue to rely upon that being used as the default if you only define the access arguments. Note that modules that currently rely on access inheritance WILL NOT work correctly with 6.2.

This change is due to problems and confusion regarding the 5.x to 6.x menu system changes and inheritance of the access callback and arguments. In 6.x, access to each path is, in terms of access, totally independent of any other path, regardless of whether one path appears to be a "child" of another. For example, imagine a 6.x hook_menu definition where the path "mymodule/page" requires "administer mymodule" permission, and the hook_menu definition for path "mymodule/page/settings" is written to require only the permission "access administration pages". Some module authors have mistakenly assumed that the inheritance meant that a user would need BOTH permissions to access "mymodule/page/settings".

An additional minor change is being made is an alteration of one of the core-defined load functions, %user_current. In retrospect this choice of naming has led to confusion and the expectation that only the CURRENT user could be loaded by this function, and that this provides access control. This is not true. The "_current" part relates to the use of this in a menu link, where the value for the current user gets populated for the link. Thus, this is being renamed to %user_uid_optional, and you should understand that in terms of routing you to a page callback, %user_uid_optional will work the same as %user. Only about 3 contributed modules use this currently, so those authors will need to change their hook_menu definitions.

EXAMPLE - BEFORE API CHANGE:

    $items['admin/content/animals/cat'] = array(
      'title' => 'Cat',
      'page callback' => 'drupal_get_form',
      'page arguments' => array('animal_form', $type),
      'access arguments' => array('administer animals'),
      'file' => 'animal.admin.inc',
      'type' => MENU_CALLBACK,
    );
    $items['admin/content/animals/cat/edit'] = array(
      'title' => 'Edit',
      'type' => MENU_DEFAULT_LOCAL_TASK,
    );
    $items['admin/content/animals/cat/delete'] = array(
      'title' => 'Delete',
      'page arguments' => array('animal_delete_confirm', 'cat'),
      'file' => 'animal.admin.inc',
      'type' => MENU_CALLBACK,
    );
    $items['animals/%user_current'] = array(
      'title' => 'Animal list',
      'page callback' => 'animal_list',
      'page arguments' => array(1),
      'access arguments' => array('view animals')
    );

EXAMPLE - AFTER API CHANGE (note changes to 3rd item with added 'access arguments' and 4th item with switch to '%user_link'):

    $items['admin/content/animals/cat'] = array(
      'title' => 'Cat',
      'page callback' => 'drupal_get_form',
      'page arguments' => array('animal_form', $type),
      'access arguments' => array('administer animals'),
      'file' => 'animal.admin.inc',
      'type' => MENU_CALLBACK,
    );
    $items['admin/content/animals/cat/edit'] = array(
      'title' => 'Edit',
      'type' => MENU_DEFAULT_LOCAL_TASK,
    );
    $items['admin/content/animals/cat/delete'] = array(
      'title' => 'Delete',
      'page arguments' => array('animal_delete_confirm', 'cat'),
      'access arguments' => array('administer animals'),  // We must now define the access parameters here too.
      'file' => 'animal.admin.inc',
      'type' => MENU_CALLBACK,
    );
    $items['animals/%user_uid_optional'] = array(  // Switched to using %user_uid_optional.
      'title' => 'Animal list',
      'page callback' => 'animal_list',
      'page arguments' => array(1),
      'access arguments' => array('view animals')
    );