Remarkably, Drupal 7’s FAPI treats form submissions using the GET method as something of an afterthought. “Just register a URL with wildcards for that!” is the usual refrain from the Drupal devout when the less indoctrinated express their shock over this state of affairs. That approach, however, has several limitations over the W3C standard Way To Do It, such as if your form /has/twenty/optional/fields/that/all/need/a/position/in/the/url, or if your goal is to have Drupal serve response pages for requests formed by standards-complaint tools.
Fortunately though, it is possible. Getting it to work at all requires a multi-line recipe; things become even trickier if you want Drupal to handle submissions coming from another web framework or a static html file. I was faced with this prospect when I needed to reimplement a single form in a more complex legacy application. The frontend form needed to stay as-is because that’s where users look for it, but Drupal had all the backend pieces to make the magic happen in < 100 lines, so I figured I would just point the existing form’s method to a custom module in Drupal. Here’s a generalized sample of what all is needed in such cases, derived from combined googling and interactive debugging through core:
- Build the form
$form_state = array( 'method' => 'get', 'always_process' => true, // if support for submissions originating outside drupal is needed ); $form = drupal_build_form('name_of_my_form', $form_state);Returning
$format this point would suffice as the entirety of a page callback. (Note that because of the needed$form_state, you have todrupal_build_forminstead ofdrupal_get_form, and the standard trick of just registeringdrupal_get_formas your page callback inhook_menuisn’t an option.) - Write the form callback
Despite the fact that you already told Drupal you want a GET form in the$form_state, you’ve gotta do so in$formin your form callback as well:function name_of_my_form($form, &$form_state) { $form['#method'] = 'get'; $form['#token'] = 'false'; ... // describe your form as usual return $form; } - Break the redirect loop and otherwise handle the submission in the form submission callback
So, you’ve made a form that trips the submission callback when you access it and loads up the values specified via GET into Drupal’s usual form_state structures. But wait! Drupal’s standard thing is to redirect somewhere following a form submission, and your GET url looks like a form submission to it now, so endless redirect loop ahoy. This can be killed off in a variety of ways, but I’ll mention two that I think should cover most cases.If you examine the submitted values and find the submission to be incomplete, such as if the user visited the registered path without providing any GET parameters, you can simply set
$form_state['no_redirect'] = truein your submit handler.If you wish to actually process a submission and display results on the page, here’s how I did it: instead of setting no_redirect, set
$form_state['rebuild'] = true. This implicitly stops a redirect from occurring, and also results in two calls to your form callback during the request – one to provide Drupal with your form information for validation/submission processing, and a second after the submission handler has been run. The results of the second invocation are what is rendered to the page. So, it’s easy enough to stick some results data in your$form_statein the submit callback, then look for it in the form callback and add some additional elements to the form’s render array to show them.
Of course, 'always_process' => true explicitly lowers Drupal’s CSRF shields, so be sure to confirm for yourself that your GET form really isn’t modifying the state of your application.
Also, beware the magic q: Drupal uses the URL param ‘q’ when pretty URLs are disabled, and treats it as the string to be routed whenever it is present as a parameter, whether pretty URLs are on or off. So, it’s unavailable for use as the name of an input on your form.