My websites break as the html ID's increment on each ajax request in the exposed filters.
e.g.

<input type="text" id="edit-email" name="email" value=..........
<input type="text" id="edit-email--1" name="email" value=..........
<input type="text" id="edit-email--2" name="email" value=..........
<input type="text" id="edit-email--3" name="email" value=..........
<input type="text" id="edit-email--4" name="email" value=..........

The issue is here, this was removed:

      if (isset($_POST[$key])) {
        unset($_POST[$key]);
      }

and replaced with:

      if (isset($cleaned_post[$key])) {
        unset($cleaned_post[$key]);
      }

To fix this, $_POST['ajax_html_ids'] needs to be unset:

      if (isset($cleaned_post[$key])) {
        unset($cleaned_post[$key]);
      }
      unset($_POST['ajax_html_ids']); // this fixes it!
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

StephenRobinson created an issue. See original summary.

StephenRobinson’s picture

Issue summary: View changes
StephenRobinson’s picture

Issue summary: View changes
StephenRobinson’s picture

Issue summary: View changes
StephenRobinson’s picture

Based on this information, these I.D.'s need at least removing from $_POST['ajax_html_ids'] to ensure the orifinal I.D.'s are maintained....

"ajax_html_ids is an array of every HTML element's id attribute collected by ajax.js before making the HTTP request. These are used by drupal_html_id() to ensure that when the AJAX response is delivered it contains unique HTML ids and not ones that may conflict with existing ids in the DOM."

DamienMcKenna’s picture

Version: 7.x-3.24 » 7.x-3.x-dev
Status: Patch (to be ported) » Active

Thanks for reporting the bug, I'm sorry you've ran into this, and thank you for providing some details on what a possible solution should be.

FYI the correct status for an issue without a patch is "active"; the "Patch (to be ported)" status is only for when there's existing patch that was committed to one branch and needs to be ported to another branch, e.g. a patch committed to 8.x-1.x and then backported to 7.x-1.x.

rclemings’s picture

What triggers this bug? Is it the "Use AJAX" setting in the view edit page or something else? (In other words, if "Use AJAX" is "No," can I ignore this?)

StephenRobinson’s picture

This is just when you refresh the results using views filters with ajax enabled, when you look at:

Drupal.ajax.prototype.beforeSend = function(xmlhttprequest, options) {

if you set options['extraData'][' ajax_html_ids[]'] =[]; no change was observed...

DamienMcKenna’s picture

Status: Active » Needs review
FileSize
372 bytes

Just to see what happens, here is the suggested change in patch format, let's see what the testbot says.

StephenRobinson’s picture

I have found another solution that uses javascript to remove the I.D.'s from the exposed filter form so they are maintained:

    (function($) {
      if(Drupal.ajax){ // if is ajax enabled
        var beforeSerialize = Drupal.ajax.prototype.beforeSerialize;
        Drupal.ajax.prototype.beforeSerialize = function (element, options) {
          beforeSerialize.call(this, element, options);
          jQuery(document).trigger('beforeSerialize'); // run default Drupal.ajax.prototype.beforeSerialize
          var allformids = [];
          if( (options['data']['view_name']) && (options['data']['view_display_id']) ){ // if is a view
            var formid = 'views-exposed-form-' + options['data']['view_name'] + '-' + options['data']['view_display_id'];
            formid = formid.replace(/_/g, '-'); // kebab case...
            if(jQuery('#' + formid).length){
              jQuery('#' + formid + ' *').each(function() { 
                if (this.id) { 
                  allformids.push(this.id); // get all I.D.'s from the exposed filters
                } 
              }); 
              options['data']['ajax_html_ids[]'] = options['data']['ajax_html_ids[]'].filter((item) => !allformids.includes(item)); // remove exposed filters I.D.'s
            }
          }
      }
    })(jQuery);
sguglielmo’s picture

+1 RTBC for patch #9! It fixed the issue we had and our testing looks good! Thank you!

silverham’s picture

silverham’s picture

Priority: Normal » Major

Flagging as major.

Views used to never change the HTML IDs for long time, so lot of code in contrib may depend on this.

Example: CSS to to style the input / submit on buttons by ID breaks, JS to trigger certain functionality by HTML ID.

Workaround involves a rewrite of code to get the div around it and then target inputs. (assuming template has not been overridden to remove the divs)

Shrutidkadam’s picture

+1 for #9, it helped me, it is working fine.

vinmassaro’s picture

Status: Needs review » Reviewed & tested by the community

Patch in #9 is working for me as well.

strinh’s picture

We've just run into this issue as well with exposed date filters and the patches fixes this. I wanted to add these keywords to this issue and confirm that the patch works. Thanks!

DamienMcKenna’s picture

Title: Exposed filters broken, html ID's keep incrementing on every ajax request » Exposed filters broken, html ID's keep incrementing on every AJAX request
Status: Reviewed & tested by the community » Fixed
Parent issue: » #3118500: Plan for Views 7.x-3.25

Committed. Thank you all.

DamienMcKenna’s picture

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.