CHAPTER 6 ■ WORKING WITH USERS

Using profile.module to Collect User Information

If you plan to extend the user registration form to collect information about users, you would do well to try out profile.module before writing your own module. It allows you to create arbitrary forms to collect data, define whether the information is required and/or collected on the user registration form, and designate whether the information is public or private. Additionally, it allows the administrator to define pages so that users can be viewed by their profile choices using a URL constructed from site URL plus profile/ plus name of profile field plus value.

For example, if you define a textual profile field named profile_color, you could view all the users who chose black for their favorite color at http://example.com/?q=profile/profile_color/black. Or suppose you are creating a conference web site and are responsible for planning dinner for attendees. You could define a check box profile field named profile_vegetarian and view all users who are vegetarians at http://example.com/?q=profile/profile_vegetarian (note that for check box fields, the value is implicit and thus ignored; that is, there is no value appended to the URL like the value black was for the profile_color field).

As a real-world example, the list of users at http://drupal.org who attended the 2010 Drupal conference in San Francisco, California, can be viewed at profile/conference-sf-2010 (in this case, the name of the field is not prefixed with profile_).

■ Tip Automatic creation of profile summary pages works only if the field Page title is filled out in the profile field settings and is not available for textarea, URL, or date fields.

The Login Process

The login process begins when a user fills out the login form (typically at http://example.com/?q=user or displayed in a block) and clicks the “Log in” button.

The validation routines of the login form check whether the username has been blocked, whether an access rule has denied access, and whether the user has entered an incorrect username or password. The user is duly notified of any of these conditions.

■ Note Drupal has both local and external authentication. Examples of external authentication systems include OpenID, LDAP, Pubcookie, and others.

Drupal attempts to log in a user locally by searching for a row in the users table with the matching username and password hash. A successful login results in the firing of two user hooks (load and login), which your modules can implement, as shown in Figure 6-3.

125

CHAPTER 6 ■ WORKING WITH USERS

Figure 6-3. Path of execution for a local user login

126

CHAPTER 6 ■ WORKING WITH USERS

Adding Data to the $user Object at Load Time

The load operation of the user hook is fired when a $user object is successfully loaded from the database in response to a call to user_load(). This happens when a user logs in, when authorship information is being retrieved for a node, and at several other points.

■ Note Because invoking the user hook is expensive, user_load() is not called when the current $user object is instantiated for a request (see the earlier “The $user Object” section). If you are writing your own module, always call user_load() before calling a function that expects a fully loaded $user object, unless you are sure this has already happened.

Let’s write a module named loginhistory that keeps a history of when the user logged in. We’ll display the number of times the user has logged in on the user’s “My account” page. Create a folder named loginhistory in sites/all/modules/custom/, and add the files in Listings 6-4 through 6-6. First up is sites/all/modules/custom/loginhistory/loginhistory.info.

Listing 6-4. loginhistory.info

name = Login History

description = Keeps track of user logins. package = Pro Drupal Development

core = 7.x

files[] = loginhistory.install files[] = loginhistory.module

We need an .install file to create the database table to store the login information, so we create sites/all/modules/custom/loginhistory/loginhistory.install.

Listing 6-5. loginhistory.install

<?php

/**

* Implements hook_schema(). */

function loginhistory_schema() { $schema['login_history'] = array(

'description' => 'Stores information about user logins.', 'fields' => array(

'uid' => array( 'type' => 'int', 'unsigned' => TRUE, 'not null' => TRUE,

127

CHAPTER 6 ■ WORKING WITH USERS

'description' => 'The {user}.uid of the user logging in.',

),

'login' => array( 'type' => 'int', 'unsigned' => TRUE, 'not null' => TRUE,

'description' => 'Unix timestamp denoting time of login.',

),

),

'indexes' => array( 'uid' => array('uid), ), );

return $schema;

}

Listing 6-6. loginhistory.module

<?php

/**

*@file

*Keeps track of user logins.

*/

/**

* Implements hook_user_login */

function loginhistory_user_login(&$edit, $account) {

// insert a new record each time the user logs in $nid = db_insert('login_history')->fields(array(

'uid' => $account->uid, 'login' => $account->login

))->execute();

}

/**

* Implements hook_user_view_alter */

function loginhistory_user_view_alter(&$build){

global $user;

// count the number of logins for the user

$login_count = db_query("SELECT count(*) FROM {login_history} where uid = :uid", array(':uid' => $user->uid))->fetchField();

128