Hi,
I'm not sure if it concerns Search API code, but I see this ajax error first time with exposed views filter.

Two views filters full text search combined with content taxonomy are exposed in form of block on many site pages. When on page with form (like node form or comment) each attempt of submitting a form has no effect (beside showing throbber) and watchdog message is "Invalid form POST data". When javascript or filter block disabled then everything works OK.
The message is produced by ajax_get_form function in Drupal 7:

// Get the form from the cache.
  $form = form_get_cache($form_build_id, $form_state);
  if (!$form) {
    // If $form cannot be loaded from the cache, the form_build_id in $_POST
    // must be invalid, which means that someone performed a POST request onto
    // system/ajax without actually viewing the concerned form in the browser.
    // This is likely a hacking attempt as it never happens under normal
    // circumstances, so we just do nothing.
    watchdog('ajax', 'Invalid form POST data.', array(), WATCHDOG_WARNING);
    drupal_exit();
  }

Comments

pq’s picture

pq commented
Issue summary: View changes

I know this is an old issue but I've just run into something similar which might explain what's going on here.

On a search api view with a search_api_ranges facet, SearchApiIndex->dataAlter() is called from search_api_ranges_minmax, which in turn calls SearchApiAlterAddViewedEntity->alterItems() and that calls entity_view() passing in the found entities from the view.

If the entities display contains an attached form with ajax behaviours (in my case an ajaxified add to cart form using dc_ajax_add_to_cart) this gets built and the ajax information gets added to the Drupal.settings.ajax javascript. However, for some reason the form element id's don't appear to get passed through drupal_html_id() so the ajax id's remain the defaults (e.g. edit-submit).

If another form element is then rendered with a standard id that coincides with one of these then that form element will get "ajaxified" with the behaviour of the form on the entity being searched. In my case when clicking submit on a search form, an ajax request is performed to the add to cart callback.

A work around is to use hook_form_alter() in a custom module to customise the id of ajax element on the form attached to the searched entities:

/**
 * Implements hook_form_FORM_ID_alter().
 */
function MYMODULE_form_add_to_cart_form_alter(&$form, &$form_state) {
  $form['submit']['#id'] = drupal_html_id('add-to-cart-submit');
}

(to be modified for your use case).

Not sure if there's a solution that can be implemented in search_api... possibly it could recursively search through $render after $render = entity_view($type, array(entity_id($type, $item) => $item), $mode); in SearchApiAlterAddViewedEntity->alterItems() and unset any #ajax keys before running $text = render($render);.

drunken monkey’s picture

drunken monkey
he/him
Primary language German
Location Vienna, Austria
commented

It seems to me the Ranges code should just not call SearchApiIndex->dataAlter() during a search.
But then, this might be a problem in any case, we don't want to trigger any AJAX functionality when rendering entities that aren't then displayed. So if others have similar problems, we can think about implementing your suggested solution.
In any case, thanks for reporting it!

legolasbo’s picture

legolasbo
he/him
Primary language Dutch
Location Middelburg
commented
Status: Active » Closed (outdated)

This issue has not seen activity in over 2,5 years. I am therefore closing this issue to clean up the issue queue. Feel free to re-open and update this issue if you feel this issue is still relevant and of importance.