Ready to watch this entire course?
Become a member and get unlimited access to the entire skills library of over 4,900 courses, including more Developer and personalized recommendations.Start Your Free Trial Now
- View Offline
- Creating your first module
- Interacting with hooks
- Working with permissions and roles
- Controlling access
- Adding a menu item to an admin interface
- Using the Form API (FAPI) to quickly create a form
- Creating custom form validation
- Manually creating a custom content type
- Validating user input
- Importing content using feeds
- Creating a block
- Understanding best practices and coding standards
Skill Level Advanced
In the previous video, I used variable_get with a default value to populate the form with sensible defaults. This works quite well when the form is submitted, but what happens if functionality that requires those variables is triggered? They just won't be there unless I use a variable_get that also has default values. That doesn't scale well however. What if I want to use that variable in a dozen places? Then I have to define a default value a dozen times. Then if I ever change the default then I have to re-factor all those places, and so forth.
That approach doesn't scale well. Instead, I will leverage a one-time triggered event when a module is installed to set the defaults in one place using hook_install. Return to the IDE. By convention, hook_install is always placed in its own file named module name.install. Therefore for the windfarms module I will create a New > Empty File called windfarms.install, windfarms.install. Install files are just PHP scripts, so I will start the file with an open PHP tag and a file level doc block, Wind Farms installation.
Then create a new doc block for the hook_ install implementation, Implements hook_install. Create a new function called windfarms.install. Hook_install takes no parameters. Then add an in-line comment. I'm initializing the variables in hook_install, so I'll just say that, Set default variables.
Using variable_set, set the four variables with the appropriate defaults; windfarms_gmap set to 1, variable_set ('windfarms_default_center_lat') set to 42.91455, variable_set ('windfarms_default_center_long') is set to -75.569851, variable_set ('windfarms_default_gmap_zoom') is set to 8.
Include a message to the user to describe what happened. Now before I do that there is a gotcha that can be slightly confusing. While the t localization function is used extensively throughout module development, there are times when the t function is not directly available. Drupal doesn't have access to the database in the early parts of the installation process, and as such there are actually multiple mechanisms available for translation. Depending on when it's invoked, Drupal requires the use of one of two translation functions.
This can be bit unwieldy but there is a compromise. By using the get_t function in an ambiguous circumstance such as a module installation the contextually appropriate translation function can be used. Start with a comment, Get localization function for installation as t() may be unavailable. Assign the t variable to get_t. Using the t variable give the user feedback, drupal_ set_message ($t ('Wind Farms variables created.')).
When removing a program it's common to find bits and pieces left around. This is at best annoying. Therefore it's best practice to clean up when removing a module. There is a companion hook to hook_ install called hook_uninstall. Similar to hook_install, hook_uninstall is only called once, but unlike hook_install it must be explicitly executed after the module is disabled. Start with the doc block stating that this function implements hook_uninstall, Implements hook_uninstall().
Like hook_install, hook_uninstall takes no parameters; function windfarms_uninstall using the variable_del function delete the variables that were created, variable_del ('windfarms_gmap'), variable_del. I'll copy and paste from above to save time, variable_del for longitude, variable_del and the zoom.
Next inform the user of the removal using drupal_set_message and using the t variable to provide access to the translation function. Inform the user of the removal, $t = get_t(), then drupal _set_message ($t('Wind Farms variables removed.')). Save, then return to windfarms.module and remove the default values, so there is a single point of entry for the defaults.
First the Google Maps toggle, the latitude and longitude and the zoom. Save the module and return to the browser. Reload the page without the form submission to verify that the persistence is working. Next, go to the Modules Interface, scroll to Other, unchecked the box next to Wind Farms to disable it and click Save configuration.
Now that the module is disabled you can go to the Uninstall tab. The Wind Farms module will be listed, check the Uninstall box next to Wind Farms, then click Uninstall. You'll be given a confirmation screen confirmed by clicking Uninstall. Two messages are displayed. The first is the custom message that I set about Wind Farms variable being removed, and the second is a generic message. Return to the module list, let's scroll to the bottom and enable Wind Farms.
This time an additional message is shown, Wind Farms variables created. This act of customizing settings for a module from an administrative interface is a common and sometimes repetitive task. Drupal has some mechanism that will simplify this process by performing the repetitive aspects. In particular, the Submit button, saving the variables and giving a message to the user. For the purposes of this course, it's useful to show how the Drupal form API interacts which is why I'd walk you through that process. Now that the demonstration is complete, I'll simplify the form leveraging an additional function and reduce the overall amount of code.
Return to the IDE and open windfarms.module, completely remove the submit handler. Next, go to the bottom of the form creation and remove the Submit button. Replace the return form with a call to another function, system_settings_form, which takes one parameter the form. This will allow Drupal to add additional form elements, save the variables and give a generic message to the user, Save, then return to the browser.
Go to Configuration, then Wind Farms Settings. Notice that the Submit button now says Save configuration. This is the default. Change the zoom and some other elements and click Save configuration, you'll now see a more generic message, The configuration options have been saved. Leveraging built-in Drupal functionality the system still performs in the same manner, but with a lot less repetitive code.
I'll reload the page and verify that the persistence works. There is one final touch that I will add to the admin interface, an easy link to the configuration page from the module list. Go to the IDE and open windfarms.info. Add line at the end of the file with a key configure, and the value as the path to the administrative interface that was just created, admin/config/windfarms/manage.
Save then return to the Drupal site and go to the Modules list. Scroll to the bottom and a new link to the configuration page is now shown next to Wind Farms, click on it to see how it works. Throughout this chapter, the administrative interface has been created. I demonstrated the Menu and Form API, variable persistence, how to install and uninstall a module, then how to simplify the creation of an administrative interface. In the next chapter I will create and populate the new content type for storing instances of a Wind Farm.