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
Once validation is passed, the Drupal form API looks for submit callback. Return to the IDE, then create a new docblock for the submission callback. Process a validated Wind Farm admin setting submission. Similar to the way the validate function was named, a submit callback name starts with the form name followed by underscore submit. Same as a validate function, it takes two parameters; the form then the form state passed by reference; windfarms_admin_settings_form_submit, form then form_state, passed by reference.
The first thing I want to do is tell the form to rebuild so the submitted values will be displayed even on success, instead of showing the default values. To do that I will manually set a flag in the form state. As form state was passed by reference, changes within this function will affect other form processors. The flag name is rebuild and accept Boolean values true or false. I'll start with a comment to describe what I'm about to do; Rebuild the form, form_state key rebuild = TRUE, save the module then return to the browser.
Change the input to something valid, but different. This time the form elements contain the submitted input. Next load the page without a form submission and the default values are shown. To complete this interface I need to be able to save the settings. Drupal provides a mechanism for persistent variables that allows for practically any datatype to be stored in the database. There are three functions: variable_get which gets a value by name and optionally provides default value if the variable has never been set, variable_set which saves a value to the database by name, and variable_del which deletes a value from the database by name.
Variables are useful for settings but in general should not be used for content. Variable names are, by best practice, lowercase and separated by underscores and start with a module name. Go back to the IDE and navigate the form creation of windfarms_gmap, and in particularl the default_value. Instead of just defaulting to 1, I will change it to use variable_get and use 1 as the default value, variable_get windfarms_ gmap and set the default value.
The name is passed as a string and I will use the same name as the form element. Now if the windfarms_gmap has never been set it will default to 1. I will do the same for the latitude, variable_get, windfarms_default_center_lat, and for the longitude, variable_get windfarms_default_center_long.
And finally the zoom; variable_get, windfarms_default_gmap_zoom. Now that the form can get the default for the variables let's set the variables upon a successful form submission. Return to the form submit callback then, beneath the form state add a comment describing what is about to happen; Save Wind Farm setting variables.
Use variable set in the form state values. No additional manipulation of the input is needed as the form API handles the input sanitization and variable_get handles the database interactions. Variable_set, windfarms_gmap which is from form _state values, windfarms_gmap; variables_set, windfarms _default_center_lat which is from the form_state once again with the same name.
Do the same for the longitude and finally the zoom, windfarms_default_gmap_zoom, save then return to the browser. Change the form values to something valid and click Save. 35 and 40.
The page looks like it did before when it passed validation complete with a new input. Reload the page without a form submission to verify the persistence of the variables. As it stands, the admin interface is functional but lacks a usability touch. There is no feedback to the user when the settings are saved. Drupal core has a mechanism to store user messages within the session and display them. To set one of these messages use drupal_set_message.
Return to the IDE and the form submit callback. At the end, provide an appropriate message to the user stating that the variables have been saved. Drupal set message takes two parameters. The first which is required is the message itself wrapped in the t function. The second is an optional message type, the default is status. Developers can also set warning and error messages, start with a comment for context. Notify user, then set the message, Drupal_ set_message t Wind farm settings saved.
Finally, as development in this admin section is complete remove the TPM debugging call within the validator. Save the module and then return to the browser. Save new settings and this time the message is displayed to the user and no debugging information is shown. In the next, segment I will demonstrate best practices with variable persistence using module install and uninstall hooks.