Ready to watch this entire course?
Become a member and get unlimited access to the entire skills library of over 4,987 courses, including more Developer and personalized recommendations.Start Your Free Trial Now
- View Offline
The Drupal form API provides a mechanism for a number of common validations. These include required fields, which I've demonstrated, and also includes ensuring that the value given to a select form element is actually in the domain of available options. It even provides cross-site request forgery protection without any additional form elements. With that said, the complexity of the checks don't go much beyond these options and the error messages are minimal at best. Fortunately Drupal provides a mechanism for customizing the form validation.
Before I continue, I will recommend that you would enable the devel module. Devel is a contributed module that consists of a suite of modules for assisting module developers with the helper functions and the other debugging information. I utilize it on a regular basis in my development environment, with a caveat of it should never be installed in production and care should be taken not to deploy code to production, with debugging output. Enable the devel module by going to Modules, scrolling down to DEVELOPMENT, clicking ENABLED next to Devel.
Then Save configuration. If the devel module is not listed, please download it and install it from drupal.org. Drupal form validators are standardized callback functions. The function name is the same as the form creation with the addition of underscore validate. Drupal will automatically look for a function that matches this naming pattern and use it if it exists. If a function doesn't exist, there are no consequences other than the lack of custom validation. Return to the IDE and create a new docblock for the form validator.
There is no actual hook form validate, but the Drupal form API allows forms to be validated as if there were; validates Wind Farm admin settings. Next create a new function beneath the docblock called function windfarms_admin_settings_form_validate, which takes two parameters; the form and the form_state passed by reference. Let's get some introspection into the form state itself.
It's a large array containing over a dozen keys. To quickly display the contents of the form state upon form validation, I will leverage one of the helper functions from the develop module called DPM which stands for Drupal Print Message. DPM displays a variable to the message area of the page, dpm form_state, save and return to the browser. Go to configuration, scroll to Wind Farms Settings, let's create a bad value here and submit the form.
The sanitize values are stored in the values array; the debugging information shows the contents of form state. Click Array and you can see the contents. The sanitize values are stored in values. DPM is very useful for determining array structures and values, return to the IDE. I'm going to be a little bit more specific about what DPM is displaying to make it easier to see what's going on. So DPM form state values; in particular the sanitize response from the user is contained in key values in the form state arrays, so I'll be using values for both validation and submission handling.
To add a validation to a form, perform whatever logic that is needed. If the logic fails then, call function form_set_error. Form set error takes two parameters; the first is the name of the element that has a problem, and the second is a translated string that contains the error message. I will demonstrate validation using the text field for latitude and longitude which has a specific format maximum and minimum values. First, I'll do some setup to improve readability. I will use a regular expression to check the format of the sign degrees.
Optionally, there can be a period. If so then it must be followed by at least one digit. Regular expression for validating signed degrees, signed_degree_regex = the start of the regular expression and optionally plus or minus followed by at least one digit.
Then optionally a period followed by one or more digits, make that optional, and then the end of the expression. Next, since the submitted values have rather long names and are located in the nested array I'm going to assign a shorter variable name to their values. Shorthand for long array names; lat = form_ state values windfarms_default_center_lat.
And long is set to form_state values windfarms_default_center_long. The first checks I will perform are on the format of the latitude and longitude using regular expressions I just wrote. I'll start with a comment. Validate latitude and longitude format. Then a simple if statement, if a regular expression does not match if not, preg_match signed_degree_regex and latitude call form _set_error.
The first parameter is the name of the form element that is failed and the second is a string passed through the t function; form_set_ error windfarms_default_center_lat and the t function, Invalid latitude must be a signed degree. Create a second variation for longitude.
The logic stays the same but the names and message are slightly different. Next, validate the latitude and longitude values. Each value must be between negative -180 and positive +180. Validate latitude and longitude values. If not -180 <= lat && lat <= 180.
form_set_error windfarms_default_center_lat, and the message Latitude must be between -180 and 180. And we'll do the same for the longitude. Long, long, long and Longitude, save the file and return to the browser.
Ensure that the form validation fails by putting invalid values into latitude and leave longitude empty. Note the contextual accurate messages. Longitude field is required and the invalid latitude message. Change the latitude and longitude to valid values that are different than the default. So I'm going to set to 1 and 2 then click Save. The DPM output is on top from the validation but the latitude and longitude have mysteriously gone back to their defaults.
Why is that? By default on a failed form validation, the form rebuilds and is displayed to the user with their input. If the form passes validation then the form is not rebuilt. In the next segment, I will describe how to handle a successful form submission.
- 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