3

I have a form that works, essentially, as a search / filter:

 foreach($search_properties as $property) {
    $form['properties'][$property->idProperty] = array(
      '#title' => $property->Label,
      '#ajax' => array(
        'callback' => 'mymodule_filter_ajax',
        'wrapper' => 'category-filter-result',
        'method' => 'replace',
        'effect' => 'fade',
      )
    );
    switch ($property->PropertyType) {

Options are generated by taking only actually used values from possible ones:

  '#options' => array_intersect_key($possible_choices, $used_values),
  '#default_value' => array_keys($used_values),

Nothing interesting here, really, just set of fields that, on change, reloads a list of links using AJAX. Never submitted, never saved.

Problem is - when user clicks on a link, and then clicks browser's "back", all fields have their defaults selected again.

I'm under impression that it was not the case with Views exposed filters. I think I remember these filters was able to keep values when user went back to them. So it is possible.

What is the Drupal way to keep user-selected values in the simple scenario of a link click, and then browser's "back" button?

7
  • I'm fairly sure Views uses the session variable, which is overkill for the simple back-click situation you describe. Do the filters themselves change with each AJAX request, or just the results?
    – Andy
    Jul 25, 2014 at 9:42
  • @Andy just the results. <div> pointed in 'wrapper' => 'category-filter-result' is outside form. And thanks, I'm about to use session, I just believed there is another way, way I'm just missing. But confirmation there probably is none would be an acceptable answer, too.
    – Mołot
    Jul 25, 2014 at 10:13
  • Hmmn, that's interesting, I tend to find that the form elements remain selected when I use the browser's back button, I thought maybe you were AJAXing down the form itself.
    – Andy
    Jul 25, 2014 at 11:09
  • @Andy I tested with FF, Chrome, IE (on Windows 8.1), and I'm consistently getting defaults. Worse, my boss has the same issue ;)
    – Mołot
    Jul 25, 2014 at 11:10
  • 1
    Thanks for humouring me (: I get the distinct impression when I'm clicking back it's not actually refreshing the page from the server, maybe the page's cacheability by the browser matters here as well.
    – Andy
    Jul 25, 2014 at 11:23

1 Answer 1

1

I'm not aware of a specifically Drupal way to do it.

As I say, I find that if I fill out a form, don't submit, click a link, and then click back, the form elements are still populated, unless perhaps there's some AJAX/JS funkiness going on with them (the actual form elements). However a little digging suggests that's browser-dependent and won't work in certain situations (eg. over HTTPS). I'd love to know more about this behaviour.

I think ideally you'd use JS to put the data in the URL. If you don't need to support older browsers then you can use the History API (not that I ever have...) which would allow you to separate arguments in a more Drupally way: eg. path/arg1/arg2/arg3. Otherwise the traditional window.location.hash can be used instead.

You can use the session variable like Views, which is more flexible and simpler to implement, but can cause anonymous users to bypass caching.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.