Hello all,

I'm trying to implement a detailed search form (on top of the apachesolr project). I decided to build the form using the Forms API, as it seems the way to "do it" in Drupal.

I get the values from the form in the submit handler just fine, I can fire my search request and get the results.

But when I display the page (and the form with it) again, the search form is empty. This is not entirely what I want, as I would like the user to refine their search.

I tried multiple ways to keep the values in the form, and after quite some googling, form_state['storage'] seem the way to go - to fill it with the value there, and use those in form method to fill in the default values. The problem is, that storage always is empty when I get the second time in the form function, and I have no real clue what I'm missing here.

The relevant code here is:

function mymodule_searchform(&$form_state)
  $items = array();
  $items["name"] = array(
    "#type" => "textfield",
    "#title" => t("Name"),
    "#default_value" => isset($form_state["storage"]["name"]) ? $form_state["storage"]["name"] : "",
  $items["submit"] = array(
    "#type" => "submit",
    "#value" => t("Search"),

  return $items;

function mymodule_searchform_submit(&$form_state)
  $name = $form_state["name"]["#value"];
  $form_state["storage"]["name"] = $name;
  $form_state["rebuild"] = true;
  // Do search here
function mymodule_search()
  return drupal_get_form("mymodule_searchform");

I hope someone can help me here :)



gpk’s picture

> that storage always is empty when I get the second time in the form function
perhaps the storage doesn't persist from one page view to the next (when the form is probably rebuild in its entirety).

A couple of ways that Drupal core handles filling-in default values:
- the URL (http://api.drupal.org/api/function/search_get_keys/6, http://api.drupal.org/api/function/search_view/6, http://api.drupal.org/api/function/search_form/6 - this is for the default search form in search.module)
- $_SESSION (e.g. the filter settings on the watchdog "recent log entries" page or on the main content admin page that lets you select node type/taxonomy term etc)
- storing info in a cookie (e.g. the comment form on nodes, for anon users). I think this one perhaps uses JS to fill in the defaults - can't remember offhand

Maybe one of these approaches will work for you.

jenshoffrichter’s picture

No, that isn't the problem.

It is during one request - I post the search form to Drupal, get the results and then want to display the search form with the content again - but the values don't persist during that one request.

But I will take a look how standard Drupal handles the search form, that is definitely a useful hint.


gpk’s picture

>It is during one request
I don't know how Drupal apachesolr search works but with vanilla Drupal search the browser first posts the search terms and then Drupal grabs the search terms and does a redirect to a URL that includes the search terms from where they are retrieved again (confused yet?) and the search executed .. so in other words any form state stuff will have been lost.

jenshoffrichter’s picture

Ah, okay, I see where the misunderstanding comes from.

I'm implementing this search form myself, so I'm still at the basics, and I just use apachesolr as a backend. Basically, not much code from apachesolr is currently involved in the form.

The reason for that is that apachesolr uses a request handler to solr which disallows the searching for individual fields (which I need here), so I have to implement a lot of it myself.


duckzland’s picture

Can you try using the drupal_rebuild_form() api? it should retain the form['storage'] value

if you can use drupal why use others?

jenshoffrichter’s picture

Okay, I figured out what the problem here was - something really stupid....

The signature for the submit handler shouldn't be



mymodule_searchform_submit($form, $&form_state)

That way, the storage persists, and I can use it to fill in default values for the search form.

Now to the more interesting stuff: rendering the results, having a pager, and so on ;)


gpk’s picture

Ah yes, that would figure. Glad you fixed it!

cbearhoney’s picture

Your syntax should be &$form_state not $&form_state.