Have two instances of the same autocomplete search field on the same page.

Hm, I don't really know what could be the problem there, sorry. Doing anything with Panels always makes things complicated, and the Form API is known to have severe problems with more than one instance of the same form on a single page, so either could be at fault. Or Drupal's autocomplete.js file or this module's partial re-write just have some bug preventing them from working with two "identical" forms on the same page.

I fear you'll have to debug for yourself to find out.

We have this exact same issue, but a slightly different use case that I think might be more common for mobile-optimized sites. For our situation, the search autocomplete field needs to be displayed twice on the page due to the site design. It is displayed once in the site header, and a second time in a fixed mini-header as the user scrolls down the page. We're using the Context module to accomplish this.

Initially we modified the $form['#id'] as discussed in this post (https://www.drupal.org/node/1392366) using a hook_form_views_exposed_form_alter function. The ID was successfully changed, but it had no impact on how the autocomplete field functions.

I haven't had a chance to look at this more extensively, but from what I can tell it seems like the JavaScript to add the proper tags does not function because the form ID is the same. If I'm looking at the rendered HTML, I see this for the field that is working properly:

<div class="form-item form-type-textfield form-item-search-api-views-fulltext" role="application">
<input id="edit-search-api-views-fulltext" class="form-text form-autocomplete" type="text" maxlength="128" size="30" value="" name="search_api_views_fulltext" autocomplete="OFF" aria-autocomplete="list">
<input id="edit-search-api-views-fulltext-autocomplete" class="autocomplete autocomplete-processed" type="hidden" disabled="disabled" value="http://domain.com/search_api_autocomplete/search_api_views_search/-">
<span id="edit-search-api-views-fulltext-autocomplete-aria-live" class="element-invisible" aria-live="assertive"></span>
<span id="edit-search-api-views-fulltext-autocomplete-aria-live" class="element-invisible" aria-live="assertive"></span>
<span id="edit-search-api-views-fulltext-autocomplete-aria-live" class="element-invisible" aria-live="assertive"></span>
</div>

And this is what's rendered for the field that does not work:

<div class="form-item form-type-textfield form-item-search-api-views-fulltext">
<input id="edit-search-api-views-fulltext" class="form-text form-autocomplete" type="text" maxlength="128" size="30" value="" name="search_api_views_fulltext">
<input id="edit-search-api-views-fulltext-autocomplete" class="autocomplete autocomplete-processed" type="hidden" disabled="disabled" value="http://domain.com/search_api_autocomplete/search_api_views_search/-">
</div>

The second block of code is missing the span tags and extra attributes on the input tag (autocomplete and aria-autocomplete). Need to look into this more, but unfortunately don't have the time to do so right at this moment. Wanted to post in case anyone else might be trying to track down the issue.

I can confirm that this behavior occurs.

When you duplicate the form that has search autocomplete attached, only the first form will have the autocomplete behavior.

For us the reason for duplication was also to display it in a different region for mobile. We solved it by changing the layout of the theme and with this only had to use one search block.

If you duplicate an HTML form as-is, you will end up with invalid HTML as all the ID attributes are then duplicated, too (and the HTML standard specifies them to always be unique). It's possible we could still make this work, but I think the foremost solution should be to create valid HTML instead. If it then still doesn't work, we can look into it.

So, postponing until someone can tell me whether this also occurs with valid HTML.

It does work if the autocomplete fields have separate ids. Unfortunately rendering views exposed forms twice does not automatically generate unique IDs. Even if the forms are from separate displays. Here is a workaround for now.

<?php
/**
 * Implements hook_form_FORM_ID_alter().
 */
function MYMODULE_form_views_exposed_form_alter(&$form, &$form_state) {
  $i =& drupal_static(__FUNCTION__, 0);
  if (strpos($form['#id'], 'views-exposed-form-VIEW-NAME-DISPLAY') === 0) {
    $form['#id'] .= '-' + $i;
    $form['search_api_views_fulltext']['#attributes']['id'] = 'edit-search-api-views-fulltext-' . $i;
    $i++;
  }
}
?>

I tried calling drupal_html_id() but for some reason that was not giving me unique IDs.

Is this actually a views bug?

Related: #1922166: Make exposed form's ID configurable

Digging deeper ...

• drupal_process_form() is calling drupal_static_reset('drupal_html_id') which is causing the duplicated ids.
• this is called because views_plugin_exposed_form::render_exposed_form() sets $form_state['always_process'] = TRUE
• can set $form_state['always_process'] = FALSE to get working autocomplete and unique ids, but then submitting the form clears the filters

Is this actually a views bug?

Either that or a Drupal Form API bug, I'd say. Or possibly also in Search API Views.
And drupal_html_id() not giving a unique ID is suspicious in any case.

Ah, yes, this seems exactly like the muck-up I was afraid of – and half-expecting when dealing with problems with advanced Form API usage.
You can try getting input from a Views or FAPI maintainer/expert on how this could be resolved – I'm clueless –, but I wouldn't get my hopes up.

I have two different views on the same page. One view is being rendered in a block. I also have a search form on both views, but I'd like to be able to search one view at a time. Right now though, entering a search in one view causes the other view to searches for the same thing. How can I get both search forms to be independent from one another?

Thanks mstrelan, #7 with some tweaks to my forms works like a charm.

This also happens if the same views exposed block has been added to a panel multiple times via multiple panes. This would of course only create one ID though. A good use case is the following:

- Using Panels Everywhere to construct a site layout.
- In the header you have a generic views exposed filter as your search, which redirects to the view.
- On the redirected view, you also have the search bar, but right above the view (This will then show the same exposed filter twice)
- Only one FullText search will show suggestions on the page.

Edit: Just realized that my use case wasn't as unique as I thought, since others have the same setup within this thread.

@NWOM
Just use the workaround from #7. What you need is unique IDs for the form and autocompleted input.

FIY, I encountered a similar problem (duplicate IDs in a view) in another module, too: #2394427: Error Occurs when VBO and Views Save are used on the same View.
Still no clue how to properly resolve this with a patch to any of the involved modules.

This is how I hot-fixed it for a case where we had two displays of the same view rendering exposed forms on the same page (global search bar in header and the local search bar in the page body when on the /search route).

/**
 * Implements hook_form_FORM_ID_alter().
 */
function YOURMODULE_form_views_exposed_form_alter(&$form, &$form_state) {
  if ($form_state['view']->name === 'NAME-OF-VIEW') {
    $form['NAME-OF-INPUT-FIELD']['#id'] = "edit-NAME-OF-INPUT-FIELD-{$form_state['display']->id}";
  }
}

Hi,

The workaround in #18 works for me too.

Cheers

Tom

#18 was a great workaround. Thank you!

Thanks for all the info here.

On my side I'm rendering the same views exposed form twice on a page.
So I can't use $form_state['display']->id which is the same, I used $form['#build_id'] instead which is unique.

/**
 * Implements hook_form_FORM_ID_alter().
 */
function YOURMODULE_form_views_exposed_form_alter(&$form, &$form_state) {
  if ($form_state['view']->name === 'NAME-OF-VIEW') {
    $form['NAME-OF-INPUT-FIELD']['#id'] = "edit-NAME-OF-INPUT-FIELD-{$form['#build_id']}";
  }
}

Updated, see next comment.

This just happened to me in the latest release.

After I changed the "Filter identifier" to "q" under Filter criteria >> Search: Fulltext search (and ), there were two search fields, a new wide one at the top, and the regular one below.

Any other value and there is only one input field.

It could possibly be linked to experimenting (and failing) with https://www.drupal.org/project/search_api_spellcheck, just prior to this.

I misread this issue. What I experienced is something else, and a general Search API issue, so I created #3358877: Setting Filter Criteria >> Filter Identifier to q in a View adds extra input field.