We have successfully created a configuration settings form for our Example module. In our previous article we have instructed Drupal to create a form for us. Most of the form functionality is prepared for us by Drupal.
Now when we submit our form, Drupal will call “example_admin_settings_submit” function. In this article, we are going to implement this function. Perfect! Now, what things do we need to put inside “example_admin_settings_submit” function.?
Do you remember we have used the “variable_get” function, to get the field value from the database? Drupal provides “variable_get” and “variable_set” functions to retrieve/store field values from/to the database. But why do we need these functions to use? The purpose is, our module will display an “Example!” message when the user login to the website. We are restricting this to particular user role(s) only in the Example module’s configuration settings form. When the site administrator saves the changes made in the configuration settings screen, we need to save those changes into the database. We have to implement this functionality in “example_admin_settings_submit” function.
Saved data will be retrieved from the database using the “variable_get” function and it will display on the form. This functionality we have already implemented while creating the form structure. So, no need to worry about this part now.
What information do we need to store in the database? Our form is displaying user role(s). Each user role is associated with a checkbox. The site administrator can select these checkboxes (single or multiple checkboxes) and submit the form. We need to store information about what user role(s) are selected into the database. Based on this data, we will display the “Welcome!” message to the users who have into the particular user role(s). For example: if the site administrator selects the “authenticated users” checkbox and unselects the “administrator” checkbox; the “Welcome!” message should be displayed to every logged-in user except administrators.
The code for “example_admin_settings_submit” function looks like below: We have to add this function in “example.admin.inc” file.
/**
* Implementation of example_admin_settings_submit()
*/
function example_admin_settings_submit($form, $form_state)
{
// Do nothing
}Why no code was added to the above function? Is it by mistake? Fortunately, the functionality of storing data to the database is handled by Drupal API system_. So, we do not need to explicitly store the data in the database. Our job became much easier.
What things are left for us? Everything Drupal has done for us! But, we also have to do something.
While displaying the “Welcome!” message to logged-in users, we have to check whether the user is part of the selected user role(s) or not. If the logged-in user is part of selected user role(s), then show the “Welcome!” message otherwise Keep quiet.
For this, we need to change our “hook_user_login” function. We have already implemented this function in our previous article; we have to modify this.
Our function will look like below: Remember that we have added this function in the “example.module” file.
/**
* Implementation of hook_user_login()
*/
function example_user_login(&$edit, $account)
{
$roles = variable_get('example_user_roles');
$user_roles = array();
foreach ( $account->roles as $key => $value )
$user_roles[$key] = $key;
$roles_intersect = array_intersect($roles, $user_roles);
if ( isset($roles_intersect) && count($roles_intersect) != 0 )
drupal_set_message(t('Welcome, ' . $account->name . '!.'), 'status');
}
From the above code, we are checking the logged-in user’s roles with the roles selected for the Example module through configuration settings. When the administrator saves the configuration settings for the Example module; the role ids will be stored as an array of key, value pairs (“role id = > role id”). For example: if role id “2” is selected and role id “3” is not selected, in database Drupal will store them as an array “2 => 2, 3 => 0”. That is the reason, we have generated $user_roles array as “Key => Key” pairs from logged-in user roles. So that we can compare this with the roles stored in the database for the Example module.
Save these changes into the file and modify the configuration settings for the “Example” module and test whether the “Welcome!” message is appearing for only the users who are have selected role(s).
Now we have extended our “Example” module by adding a configuration settings form. I know, now you are feeling developing a Drupal module is not easy!
Are we done with module development? Yes. We are. Now we need to do a few more additional things.
For example, if we don’t want to use the module and we disable it; what would be the values it stores inside the database? They are still in the database. So, we need to remove them. When? We need to remove them when the module is disabled.
Usually, we have to provide the functionality to the modules to do some activities when the module is enabled and the module is disabled.
If time permits, we will discuss these in our next article.
Keep reading…
**