Exploring best practices with variable persistence
Video: Exploring best practices with variable persistenceIn 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.
- Creating a custom permission
Viewers: in countries Watching now:
Extend your Drupal 7 sites with custom modules, which allow you to create everything from admin interfaces to forms. Author Jon Peck describes how modules extend your base Drupal installation, then walks through how to write your own module with a practical example featuring geo-positioned alternative energy centers. The course also describes how to control access to site features, create new content types, build forms, understand data persistence, embrace coding standards, and much more.
- 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
Exploring best practices with variable persistence
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.
Find answers to the most frequently asked questions about Drupal 7 Custom Module Development .
Here are the FAQs that matched your search "" :
- Q: gmap3_tools is not working the way I expected it to. What version of gmap3_tools should I be using?
- A: Use the free exercise file containing the version of gmap3_tools used for recording; the published version of the module on drupal.org has changed since recording and is not backwards compatible.
- Q: I attempted to run the Drupal site root from the project files, but the site isn't loading. Why not?
- A: The Drupal configuration file in sites/default/settings.php contains database configuration specific to the environment used to record the movie. This may be different than your environment. Edit the file and search for "windfarms" - you may need to change the database host, username, password, db name and port to match your specific environment.
Sorry, there are no matches for your search "" —to search again, type in another word or phrase and click search.