Drupal 5: Automatically assign a role on user profile edit

Using Drupal 5, I recently had cause to create a system whereby when a user updates checkboxes in his or her profile, roles would automatically be assigned or unassigned. No problem, I thought, I would just use hook_user() to achieve this. According to the API, I would need the two $ops insert and update.

Writing the one for update was easy. The $account contained all the user's profile fields (the ones starting with profile_) and the roles could be assigned based on these (1 for add role, 0 for delete role).

I ran into a problem with insert. The $account contained the keys for the profile fields, but the values were all blank! I still don't really know why this is. The solution, as cumbersome as it might be, is to wait until the new user has a uid, then call user_load() on the user, at which point the profile fields will have their proper values. Then, exactly the same method can be used as in the update case.

As a footnote, we don't actively develop in Drupal 5 any more; all of our development occurs in Drupal 6, but we still support Drupal 5 sites. Here is the finished code in case anyone finds it useful:

/**
 * Implementation of hook_user().
 */
function mymodule_autorole_user($op, &$edit, &$account, $category = NULL) {
  if ($op == 'insert') {
    mymodule_autorole_apply_roles($account->uid);
  }
  else if ($op == 'update') {
    mymodule_autorole_apply_roles($account->uid);
  }
}

/**
 * Takes a user account object and uses it to update the user's roles.
 * 
 * @param $uid
 *    A fully populated user account object such as one returned by user_load().
 */
function mymodule_autorole_apply_roles($uid) {
  $account = user_load(array('uid' => $uid));
  
  // Filter out the profile fields from the account information.
  $profile_fields = array();
  
  foreach ($account as $fieldname => $field) {
    // Split up the field name by the underscore character. The field names we
    // are looking for are named like profile_something, but they could be
    // profile_something_something, so join back together after the split.
    $pieces = explode('_', $fieldname);
    
    if (array_shift($pieces) == 'profile') {
      $profile_fields[implode('_', $pieces) . ' club member'] = $field;
      
    }
  }
  
  $myaccount = user_load(array('uid' => $account->uid));
  $roles = user_roles();
  
  foreach ($profile_fields as $field => $value) {
    if ($value) {
      // The checkbox was checked, or the textfield had something in it. Add a
      // new role corresponding to this, if there is one.
      foreach ($roles as $key => $role) {
        if ($role == $field) {
          $myaccount->roles[$key] = $role;
        }
      }
    }
    else {
      // The checkbox was unchecked, or the textfield was empty. Unset the user
      // role corresponding to this, if there is one.
      foreach ($roles as $key => $role) {
        if ($role == $field) {
          unset($myaccount->roles[$key]);
        }
      }
    }
  }
  
  // Update the user with the new role assignments.
  db_query("DELETE FROM {users_roles} WHERE uid = %d", $myaccount->uid);
  
  foreach ($myaccount->roles as $rid => $role) {
    db_query("INSERT INTO {users_roles} (uid, rid) VALUES (%d, %d)", $myaccount->uid, $rid);
  }
}

Drupal 6: Core hacking for the simplest of things

I was recently faced with a problem concerning changing something in Drupal's core user module. This wasn't even a big change; it was as simple as changing the line of text that appears underneath the username field on the registration form. You know, the one that helps the user to choose an appropriate username.

The core has no option for changing this text, so the most obvious and worst thing possible is to open up user.module in the core and edit the string. This is bad because the first rule of Drupal club is do not hack the core. Actually, the second rule of Drupal club is... you get the idea. It would mean that when Drupal is upgraded, the change will disappear.

After ruling out the above method, I was faced with a number of opportunities to accomplish what I needed, but they all came with downsides.

Override the core

This involves making a copy of the core user module inside my site's modules folder. Drupal will then use the copy instead of the one in the core and changes can be made safely to this copy, because it is not going to be upgraded when a new version of Drupal is released, unlike the core itself.

My main concern here is that technically it's a core hack in disguise. In my case, I would be making a copy of Drupal 6.6's user module and then changing it. But, what happens when Drupal gets upgraded to 6.7? The core user module will be 6.7, but the site won't be using it. Any new or changed functionality in the user module will be missing from the site, and worse, this could introduce incompatibilities.

Suppose something has changed in 6.7's user module, and the other core modules expect this change to be in place? This would break Drupal, because it's not expecting to encounter the 6.6 user module here. How likely is this to happen? I'd say very unlikely in an upgrade from 6.6 to 6.7, but still possible. More than that, it's far more likely to happen once 6.7 becomes 6.8, 6.9 and so forth.

Locale

Drupal's translation system makes it possible to provide a translation string for the text underneath the username field, as though it were being translated into French or Italian, but this feels wrong. It's not a ‘real’ translation because we just want to change the string itself, not change it into another language.

String Overrides

There exists a module called string overrides. It provides a way of changing any text that is passed through the t() function, by saving these translations in the variables table. This seemed like an ideal solution at first, but on closer examination, there are a few drawbacks.

Firstly, since the overrides are stored in the database, we lose version control, which is never a good thing. Secondly, the more modules you add to a site, the more overhead there is, both in terms of memory and in terms of processing times.

Custom module

It would be possible to write a custom module specifically for the site in question. The module would mimic the functionality of the string overrides module, but store the overrides in a file instead of the database, thereby providing version control. The only slight downside to this is that it requires a lot more time than the other approaches. It seems like extreme overkill to have to write an entire module simply to change one string.

To conclude

In the end we decided to go with the core override method. I am not entirely happy with this, but I am sure I would not have been entirely happy with any of the solutions I've presented here. I can acknowledge and understand that there are many compromises to be made on the way to a completely custom Drupal site, but there is always room for improving Drupal to accommodate many of the more common requests. The questions are: is this one of the more common requests? and: what is the best way forward here?