Tying together different select elements in a form is done with very little effort thanks to the ajax and states system built into Drupal 9. This means that any Drupal form can have a select element that shows and updates options into another select element within the same form. Using this system you can create a hierarchical system where one select will show and populate another select element with items dependent on the first. This is great for giving the user the ability to drill down into options that are dependent on each other. As the user selects the first select element the second select element will populate with data and be shown on the screen.
Drupal's login forms are protected by a protection mechanism that prevents brute force attacks. This means that if an attacker attempts to repeatedly guess a user's password to gain entry to their account they will be blocked before being successful. This system has been a part of Drupal for many years and so is battle tested.
Like all systems in Drupal, the flood system can be adapted to be used on your own forms. Which means you can protect any form that you don't want to be used too much. This will help with authentication forms or any form that might need to process lots of information where you don't want users to submit the form too much.
Before using the flood system on a form you first need to inject it into the form. Here is a basic form setup with the flood service injected into it.
I spent what seemed like an eternity today trying to figure out something in a form I was creating on a Drupal site. I was building a multi step form with previous and next buttons, both of which were submit elements like this.
I am currently using SimpleTest to test a complex multi-step form implementation in Drupal 7. It made sense to do it this way as there are a lot of factors involved that all need to be accounted for and automating what form elements appeared on what page was the most robust solution. In order to test how the form worked I needed to submit to the form once (using a $this->drupalPost() method) and then submit the form again using the same method. The tricky bit here was that when calling the drupalPost() method with a URL it first called drupalGet() on the URL before posting to the form. This basically meant that the form was initiated twice and never got past the second page.
There are various different forms and modules in Drupal that allow for PHP code to be embedded into them. I have even talked about adding PHP code to forms in a previous post. These form elements can have their uses, modules like Views allow for PHP code to be run when collecting arguments which can allow for some advanced funcationality.
However, it can lead to problems. The code in the form is essentially outside of source control which means that anyone can mess about with the code and there is no way to revert changes or get back the code if the form save action failed for whatever reason.
I recently noticed a strange little issue with Drupal 7 that seemed like either an oversight or a decision I don't agree with. Essentially, when a node is created with a menu item in place the extended flag on the menu will not be set, but the control is also not available on the menu admin page. This means that when you are trying to print out a hierarchical menu structure you need to create the page, go into the menu admin area, access the menu, click on edit to access the menu item and change the setting there.
To get around this I set about creating a little module that would add a form control to the menu options section on the node edit form. This single checkbox is used to override any settings that the menu module creates with regards to the extended menu parameter.
The first thing to do is create a simple info file for the module. I include this here for completeness.
During my work developing Drupal sites I am quite often asked if I can provide a example of form elements for designers. This is so that they can test their designs with all possible form elements that might appear in a Drupal install and make sure that the theme we create will be robust and future proof. I often find myself forgetting how to create, say, a multi select element and needed a sort of cheat sheet that I could look form elements up on.
To this end I sat down and created a list of all of the Drupal form elements and packaged them into a module so that when the path 'form_elements' is loaded a very large form with lots of elements will be rendered. There is even a tabledrag form component in there, which is used quite a bit within the Drupal administration pages.
If you have a web site then the chances are that there will be a form of some kind on there somewhere. This might be a search box, or a contact form or even a tool. There is one thing that should be followed no matter what sort of form you create and this is the rule of Simple Input Detailed Output, or SIDO for short.
The idea behind SIDO is that you get the user to enter the absolute minimum amount of information when filling out a form, but once complete give them as much information as you can in return. The perfect form should have a single input box, and return at least a page of information from this single starting point.
This is one of the most important things to remember when designing your website, so here are some basic ideas that you should keep in mind when creating a web form using SIDO.
When adding a search form to your Wordpress blog you will want to have control over what sort of form is displayed. It is possible to override the search form created by the widget function without having to go into the /wp-includes/widget.php file and editing the wp_widget_search function. Here is the function that is present in Wordpress 2.6.