Problem/Motivation
This is a follow-up to #2189321: Secondary options closed after submit if filter identifier is not left default.
The patch works well, however I have uncovered one issue. There is a problem when the View uses Ajax to submit filters, and one of the secondary options is an autocomplete taxonomy term field. In this scenario, Ajax returns a value of the field to be "All" when no filtering has been selected.
Therefore the secondary option fieldset opens when Ajax returns the form, even though the fieldset was never opened and no values were set by the user. This functionality is controlled in the following logic in better_exposed_filters_exposed_form_plugin.inc:
foreach ($this->display->handler->get_handlers('filter') as $label => $filter) {
if (!$filter->options['exposed']) {
continue;
}
if (!empty($exposed_input[$filter->options['expose']['identifier']]) && $settings[$label]['more_options']['is_secondary']) {
$secondary_collapse = FALSE;
break;
}
}
Proposed resolution
There should be an extra check added to the conditional to determine if the value is not set to "All." This will ensure the fieldset stays closed when all values are being returned by default. This would be accomplished with the following adjustment:
foreach ($this->display->handler->get_handlers('filter') as $label => $filter) {
if (!$filter->options['exposed']) {
continue;
}
if (!empty($exposed_input[$filter->options['expose']['identifier']]) && $exposed_input[$filter->options['expose']['identifier']] != 'All' && $settings[$label]['more_options']['is_secondary']) {
$secondary_collapse = FALSE;
break;
}
}
| Comment | File | Size | Author |
|---|---|---|---|
| #14 | better_exposed_filters-secondary_options_ajax_all-2483023-14.patch | 3.73 KB | sgdev |
Comments
Comment #1
sgdev commentedHere is a patch for review.
Comment #2
sgdev commentedJust found another situation where this occurs. If an exposed filter is a date field, and the operator value is set to "in between," the value is not empty even when no information is entered by the user.
The value rendered into
$exposed_input[$filter->options['expose']['identifier']]is an array, as follows (serialized):The min/max date values are empty, but the fact that the array exists makes the exposed input value not empty.
Additional code would be needed to support this, including checking if
['min']['date']and['max']['date']exist, and if they do, checking if they are empty. Feels like the code in theexposed_form_alterfunction needs to be flexible enough to handle different types of non-standard fields (autocomplete, date range, etc.) as they are identified.Comment #3
sgdev commentedHere is an updated patch. I've pulled the logic for determining if an exposed filter is empty into its own conditional. My thought is if that section becomes long enough, it might make sense to move it into a separate function.
Let me know any questions or feedback, thanks.
Comment #4
sgdev commentedProbably makes sense to rename this as something more generic.
Comment #5
sgdev commentedIdentified another scenario that needed a condition. The previous patch included min/max for date fields, but also should include min/max for generic fields.
Please review the attached patch, thanks.
Comment #6
mikeker commentedThank you for the patch and my apologies for the delay in addressing it.
However, I wasn't able to reproduce your original issue -- that an auto-complete term field in as a secondary filter would cause the fieldset to open when other filter values were selected. There seem to be other issues with the autocomplete not working correctly but that could be from many different sources, including the theme layer. I haven't had a chance to investigate it yet.
I was able to reproduce the issue with date fields.
If you're still seeing the problem with autocomplete fields, can you attach an export of the view in question? Thanks.
Comment #7
sgdev commentedYes, I'll be able to post a sample view in a couple of weeks. Wrapping up with a project at the moment. Thanks.
Comment #8
begun commentedI have encountered the same issue. In this case I am using a combination of select fields and checkboxes in the secondary filter fieldset. Because the default value of the select field is 'All', when the form is loaded the secondary options are displayed. This is because `$exposed_input[$filter->options['expose']['identifier']]` is not empty.
If I change the exposed filter to use radio buttons/checkboxes the issue is resolved. It would seem that the plugin needs to be alter so that it the exposed filter widget is a select element, then it should only set `$secondary_collapse = FALSE`, if it is not using default value.
Comment #9
sgdev commentedSorry, I had become busy with another project and didn't have a chance to post a sample view per your request in #6. Below is an example. If the patch I created in #5 is applied, there are no issues.
Comment #10
sgdev commented@Begun, please try the patch I posted in #5 and see if it resolves your issues, or let me know if you are able to identify other problems. Thanks.
Comment #11
tterranigma commented#5 works great. The only minor issue with it is that if you have opened the fieldset for the secondary (ajax) filters but haven't selected any, and then use an ajax primary filter to search, the filedset collapses.
Comment #12
vegansupreme commented#5 works for me. Not using AJAX filters though.
Comment #13
sgdev commented@terrangima, can you describe to me the use case where this would be needed? The reason for opening the fieldset is to show values if they have been entered. If nothing was entered in the secondary filters, why keep it open and maximize space?
Maybe you're taking it from the point of view that if the user does anything in the site to change a format, the system should keep track of it. This is what's done when using vertical tabs in content types... it keeps track of the last saved "active tab" by storing a value in the database. However that's extra work for not a lot of extra benefit. We should focus first on just trying to get this patch committed, and then can consider add-ons such as that.
I'm moving the issue back to 'needs review' and hopefully @mikeker can look at it again.
Comment #14
sgdev commentedLooks like patch #5 no longer applies cleanly to 7.x-3.x-dev since line numbers have shifted. Attached is an updated version for review.
Comment #15
sgdev commentedThis patch still applies cleanly to the newest 7.x-3.6 release. Would appreciate any feedback or review.
Comment #16
neslee canil pintoHi, there will be no more future development for 7.x branch. If you see this issue in 8.x, feel free to file an issue. Closing this as Closed(wont fix).