Using Address 8.x-1.7
I have a view defined that I'm adding exposed filters based on the content's address field. I've added two filter criteria, one for country code (exposed) and one for administrative area. I'm trying to select the option for administrative area for country source to be "The value of an exposed filter", but it tells me that I have to have an exposed country code filter.
I've tried every way I can think of to remove and re-add these filters, but no combination seems to appease the admin area filter and it remains in a "broken configuration" state.
Any help is much appreciated.
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | 3087201.2_5.interdiff.txt | 940 bytes | dww |
| #5 | 3087201-5.address-admin-area-filter-pick-country-fix.patch | 1 KB | dww |
| #2 | 3087201-2.address-admin-area-filter-pick-country-fix.patch | 925 bytes | dww |
Comments
Comment #2
dwwI ran into the same thing. I was really confused what was going on, and I added this feature in the first place! ;)
Turns out that we missed this over at #3034122: Rename the 'country_code' views field and filter to 'country'. The plugin ID of the country filter went from 'country_code' to just 'country' but we don't have any tests of the Views UI and the settings forms, so we missed this. Apparently, they didn't closely grep the source tree for 'country_code' as part of that issue. Oh well.
Anyway, this seems to solve it for me. Instead of directly testing that the plugin ID of the exposed filter is exactly
country_code, we just see if the plugin ID starts with the substring 'country'. Maybe we should explicitly test for bothcountry_codeorcountry.Comment #3
dwwUgh, the automated tests for this project are currently a bit of a mess. See #3087847: Sort out address project's automated test configuration
Meanwhile, I'd love to hear:
1) If patch #2 fixes the problem for @chrisbudy.
2) If the code should continue to test the substring or be more explicit and check against exactly 'country' and 'country_code'.
Thanks
-Derek
Comment #4
bojanz commentedThis feels better to me.
Comment #5
dwwRe #4: Yeah, I think so, too. I originally wrote it that way, changed to
substr()to be more flexible / lenient, but then had 2nd thoughts. ;) Glad you agree.RTBC?
Thanks,
-Derek
Comment #6
dwwp.s. I double-checked the similar code for providing options if you want to use a contextual filter (argument) for the country source. It has a @todo comment about limiting the choices to only arguments pointing to countries, but when I was writing this code in the first place there wasn't an easy/obvious way to do that. So for now, it gives you all the arguments on the view, and is therefore immune to this bug.
Comment #7
lisastreeter commentedPatch #5 worked for me, for exposed filters.
Comment #9
dwwThanks for testing, @lisastreeter!
Committed and pushed to 8.x-1.x.
Also crediting @lisastreeter for testing and @bojanz for review / feedback.
Comment #10
chrisbudy commentedApologies for the delayed reply, but just wanted to confirm this did resolve the issue for me as well. Much appreciated @dww!
I also agree on your second question that the explicit check feels better.
Thanks again!
Comment #12
chris matthews commentedComment #13
bwoods commentedThe patch in #5 seems to work, at least, it allows me to select the exposed filter used for the country. Unless I'm missing something else, when I actually use the filters in a View display block, I have to press the Apply button to see the State pulldown. I was sort of expecting the State pulldown to auto-populate via Ajax since I have Ajax enabled in the View. I'm in the early stages of testing this functionality for use, but I figured I'd ask before trying to extend.
Edit: Just found the ticket that addresses my question - https://www.drupal.org/project/address/issues/2840717