Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Steps to recreate:
- Create a View with two separate blocks
- Add an exposed Views SHS filter to both blocks
- Place both blocks on the same page
- Result: The second filter will not function
This was true regardless of if Autosubmit was enabled or not.
Thanks for a lifesaver of a module, btw!
Comment | File | Size | Author |
---|---|---|---|
#5 | Screen shot 2013-03-07 at 7.23.08 AM.jpg | 117.75 KB | sokrplare |
Comments
Comment #1
stBorchertWill have a look at it ...
Comment #2
sokrplare CreditAttribution: sokrplare commentedThanks - happy to help too if you want to point me in the right direction, just wasn't quite sure where to start looking.
Comment #3
sokrplare CreditAttribution: sokrplare commentedAny luck looking into this? I'd be glad to have a go at it if you have pointers?
Comment #4
sokrplare CreditAttribution: sokrplare commentedLooks like we've got identical controls and IDs for the two elements - however, that is true for all Views filters input/form fields when there are two embedded Views of the same type so in theory it should still work. My first guess right now is we have some JS that needs to narrow things down by the View DOM ID first before picking up the actual controller. For reference...
First Occurence (view-dom-id-1c824bdf3bfb33d4aa2fe80ade42b787 | form ID = views-exposed-form-manage-questions-embed-1)
(Input ID = edit-shs-term-node-tid-depth | name = shs_term_node_tid_depth)
(Select ID = edit-shs-term-node-tid-depth-select-1)
Second Occurence (view-dom-id-796843cdedd06326b830018f9879316e | form ID = views-exposed-form-manage-questions-embed-2)
(Input ID = edit-shs-term-node-tid-depth | name = shs_term_node_tid_depth)
(Select ID = edit-shs-term-node-tid-depth-select-1)
Now to track down the possible rogue JS...(pointers on where to look still welcome! :)
Comment #5
sokrplare CreditAttribution: sokrplare commentedHmm...so just came up with a dead-simple workaround I can't believe didn't hit me sooner: change the Filter identifier!
I did that (see attached screenshot for any folks coming later who aren't sure what that means) and voila - we're in business!
Still might be a "bug" to pursue with getting View-driven selection in the JS, but at least there is a workaround for now/ever.
For reference, this Views issue is tangentially related to all this #832026: Multiple copies of a view embedded on a page - trouble with exposed filters.
Comment #6
stBorchertThanks for you detailled reports and sorry for my silence. I'm very busy right now so I didn't had a chance to look at this.
Regarding you latest comment: using the same identifiers may cause problems even without using SHS since each view using this identifier may think "hey, I know this" and try to filter its results based on the given value.
So I think its best practise not to use the same identifier in views displayed on the same page ...
As soon as I've got more time I will try to provide a solution so SHS didn't fail in this cases.
Comment #7
stBorchertMarking this as won't fix for now since Simple heirarchical select could not differentiate between both fields if the identifier is the same.
Comment #8
waqarit CreditAttribution: waqarit commentedthis won't fix even if identifiers are different.