A popular way of handling filters in for instance Commerce situations in the wider web community (ie, outside of Drupal) is to list currently Applied Filters (aka Active Filters) in a separate section (as well as within the filter itself). Particularly useful on mobile where keeping the exposed filters area as a whole open by default can mean the content change is not apparent.
More details:
Create an exposed filter to a taxonomy
Apply the 'Make filter options collapseable' from BEF advanced options
Filter is now collapsed
Use the form and select an option within the filter.
Apply filters
Filter is no longer collapsed
Allow site builders to specify that they would like the filters to remain collapsed.
Provide merge request
None unless site builder explicitly opts in to the new feature
None
New config option in schema
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes, plain diff MR !70 / changes, plain diff MR !62compare changes, plain diff MR !20compare 
Comments
Comment #3
scott_euser commentedMerge request available here: https://git.drupalcode.org/project/better_exposed_filters/-/merge_reques...
Comment #4
smustgrave commentedTested out the MR but still closed by default.
Comment #5
scott_euser commentedThanks for trying it out. Staying closed is the intention though.
Without the patch it opens if there is a selected option inside.
With the patch and ticking 'Disable the automatic opening of collapsed filters with selections', it is expected to now stay closed (necessary when the UX practice of 'Applied Filters (aka Active Filters)' is in place described further in the issue summary.
Comment #6
smustgrave commentedGotcha. Could we get a small test for this feature added if you have time?
Comment #8
smustgrave commentedClosed #3227130: Allow secondary options to be closed by default after search as duplicate
Comment #11
smustgrave commentedSorry for the noise.
I ended up adding a test for another issue that seemed aligned with this so I just went ahead and extended the test for here
Comment #14
smustgrave commentedHate to do it but this caused #3442199: Update hook wiped out config and had to revert. Safer to revert then spend a few days with this in the wild.
Comment #16
smustgrave commentedFor reporting this issue.
Comment #20
scott_euser commentedI'm not sure how that upgrade hook ever worked, sorry about that! Sure enough, a quick test and it wipes for me too. Perhaps way back then in 2022 the format was slightly different... Glad you caught it quickly! Updated the update hook + added a test to show its working now (before updating the update hook, test fails with wiped config as expected).
Comment #21
programmerdiego commentedsmustgrave mentioned that 'Version: 6.0.x-dev" would solve this issue, but it doesn't. Tested on Simple Test Me.
Comment #22
scott_euser commentedYep it got rolled back (see comment #14). Thanks for testing it out, what were the results? Did it solve the problem for you as well?
Comment #23
penyaskitoCould we have a diff of both upgrade functions? Hard to spot what was wrong, and how this is fixed now.
Comment #24
scott_euser commentedSure, diff is here. The original update hook started with an empty $bef_settings and built it up (and obviously not fully). This update hook starts from the existing config and only modifies the bit it needs to if it finds it.
The original update hook essentially copy pasted from better_exposed_filters_update_8001() and modified which resulted in #3112834: Exposed Filter Settings gone after upgrade.
Comment #25
seanpb commentedAs discussed in #3442511: "Exclude textfield" from auto-submit logic ignored since 6.0.4 when using autocomplete the change here (https://git.drupalcode.org/project/better_exposed_filters/-/commit/7fbd2...) breaks the ability to disable auto-submit on text fields. The change effectively removes the application of the "data-bef-auto-submit-exclude" attribute.
I'm not sure why this change was made in the first place, perhaps it was due to that attribute causing something to happen on the js side of things? In any case, I doubt that removing this functionality was an intended change.
I've added a patch in #3442511-6: "Exclude textfield" from auto-submit logic ignored since 6.0.4 when using autocomplete reverting that change.
Comment #26
scott_euser commented@seanpb did you mean to post that in this thread? If so, could you explain how it is related to this merge request?
Comment #27
seanpb commented@scott_euser, yes, MR 20 (and 61) caused not only the config-breaking issue but also the one in #3442511: "Exclude textfield" from auto-submit logic ignored since 6.0.4 when using autocomplete. The specific commit that appears to cause the issue is the one linked in my comment above (#25).
Comment #29
smustgrave commentedWill post in the other issue but believe these are unrelated since this is just now being committed.