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!
Comments
Comment #2
stephenrobinson commentedComment #3
stephenrobinson commentedComment #4
stephenrobinson commentedComment #5
stephenrobinson commentedBased 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."
Comment #6
damienmckennaThanks 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.
Comment #7
rclemings commentedWhat 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?)
Comment #8
stephenrobinson commentedThis 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...
Comment #9
damienmckennaJust to see what happens, here is the suggested change in patch format, let's see what the testbot says.
Comment #10
stephenrobinson commentedI have found another solution that uses javascript to remove the I.D.'s from the exposed filter form so they are maintained:
Comment #11
sguglielmo commented+1 RTBC for patch #9! It fixed the issue we had and our testing looks good! Thank you!
Comment #12
silverham commentedThis looks to be introduced (regression?) because of #1869236: AJAX Views delete ajax_html_ids and ajax_page_state
Comment #13
silverham commentedFlagging 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)
Comment #14
shrutidkadam commented+1 for #9, it helped me, it is working fine.
Comment #15
vinmassaro commentedPatch in #9 is working for me as well.
Comment #16
strinh commentedWe'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!
Comment #18
damienmckennaCommitted. Thank you all.
Comment #19
damienmckenna