Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
First. please don't confuse this issue with #1152760: Using country list as select list in views exposed filter..
Basically, I wonder if it's possible to have a select list as an exposed filter for State address field. This could be a bit tricky, as not all Countries have a specific set of states defined in plugins/format/address.inc. Also, this should be dependent on Country filter to expose relevant states.
Please advise if this is possible or any direction about coding this feature.
Comments
Comment #1
webankit CreditAttribution: webankit commentedAlternative: I think you can use Location Taxomonize Module to apply a Taxonomy...
Comment #2
Remon CreditAttribution: Remon commented@babbar.ankit, thank!, but this is not even an option for me :P
Comment #3
webankit CreditAttribution: webankit commentedFYI: It is compatible with addressfield also
Comment #4
stewart.adam CreditAttribution: stewart.adam commentedI would appreciate this as well, it would be very great to have a drop-down selection of states/provinces, even better if it has an option to limit the possibly options to the ones available in the query results.
Comment #5
Yaazkal CreditAttribution: Yaazkal commentedI vote for this, is a needed feature :)
Comment #6
Yaazkal CreditAttribution: Yaazkal commentedI have found a way. I can update a patch but is not a good one because is just one question left. Let me explain how to make it work.
In views/addressfield.views.inc, put this on line 24 (just before return $data;):
Then create a file views/addressfield_views_handler_filter_administrative_area.inc with this code (if dosen't work just add this code at the end of views/addressfield_views_handler_filter_country.inc without the first line <?php):
I have put the same array for my country administrative area as in #1707192: Add Columbian administrative areas (departments)
This could be an answer. But is not a pretty one answer because it assumes that you will use only one country and all that administrative areas are fixed, so this is a "manual" answer, is near and it will work in case you will use only one country and need that feature fast (as I do).
It will be nicer if there is a function that given X country (the selected country in the form of exposed filters) it retrieves all its administrative area names. Could be to retrieve all the administrative areas that are defined in plugins/format/address.inc but this implies more work and I don't have the time to do it right now. So, this is a fast not-very-well solution but works.
Any idea about how to finish it?
Regards!
Comment #7
Yaazkal CreditAttribution: Yaazkal commentedComment #8
aitala CreditAttribution: aitala commentedI'm running into the same issue for US States... I may try the 'fix' in #6 at some point.
Eric
Comment #9
adamwhite CreditAttribution: adamwhite commentedI just tried out the solution in #6 and it does work. Granted I'm just hard-coding the US states in for the time being as a test:
One thing I noticed is that unless I put the code in addressfield_views_handler_filter_country.inc it would give me an error of:
EDIT: Actually I believe I've resolved this. I wasn't adding the file include to the addressfield.info
files[] = views/addressfield_views_handler_filter_administrative_area.inc
Of course, #6 is totally correct that this should ideally be dynamic. I'll see what I can do.
Comment #10
adamwhite CreditAttribution: adamwhite commentedLooking into this, the countries dropdown is being populated by the country code / country name pairs stored in the iso.inc file in core. There doesn't appear to be anything similar for administrative_area (state / province).
As for grabbing some dynamic list of administrative areas from current locations, it appears that that the only thing the database appears to store is the two-letter abbreviation, so we'd still need to have some additional list of abbreviation / name pairs kicking around.
Comment #11
mo3.mo3 CreditAttribution: mo3.mo3 commentedi have been looking for this.
Ideal would be to allow admin to pick a Country as an exposed filter and in the settings, it allows an option to display States/Province. It then displays the Country as a drop down in the front end and based on the country, States/Province drop down show up similar to how it does when filling in the address (during the creation of the content). If only one country is used, then if admin adds Country as exposed filter and chooses to display States/Province then in the front end it only shows a drop down for States/Province.
This way, we can allow visitors to filter content by Country and then States/Province and further more, allow Zipcode and City filter as well.
Also, can anyone please direct me to a good tutorial on how to use Location Taxomonize module?
thanks!
Comment #12
rajmataj CreditAttribution: rajmataj commentedNicely done, Yaazkal and adamwhite. I have also successfully implemented this workaround with 7.x-1.0-beta3 using Canadian provinces and territories. Although it is hard-coded, at least it works for now until the developer can integrate these features into the next release. Here's the code I used for Canada (note, I only needed the abbreviated prov/terr's for the value, but you can of course substitute the full names yourself).
Comment #13
lathanrelated issue as this needs ajax callback in the options of this filter #1183418: Ajax attached to exposed filters in form_alter doesn't trigger callback.
Comment #14
rerooting CreditAttribution: rerooting commentedLooks like some great progress is being made!
Can we expect patches for this, and eventually a commit, or is this going to remain more of a per use case, custom implementation kind of thing?
Heres how I would love the views handlers to work:
The choices in administrative area can be limited by the availability of the 'country' filters. So for example, if I allow country filters of only US and Canada, then I can have the administrative areas list be of 'state/province' and the user can select from there states or canadian provinces. If the user already has applied a country filter, or has chosen a different value in the country filter, then the available administrative areas would be limited/expanded to reflect this choice. Ideally.
This way, a (or multiple) seperate array would not be necessary, as we already have the built-in ISO codes and strings, correct? This could at least work *only* when a filter country is selected, and thus call up the specific administrative area options via ajax by borrowing some of the functionality from the addressfield form?
Thoughts?
Comment #15
rszrama CreditAttribution: rszrama commentedThis will be dependent on #1829900: [meta] Address Field 2.x needs pluggable administrative areas and an actual API, as we don't have an easy API for getting at the lists of administrative area data (without building the form for a country and extracting the #options list). We definitely don't want to implement a handler that simply duplicates those state / province lists. : )
One thing I don't get about this feature request, though... are you guys fine with the country being an hardcoded option? Otherwise how should the handler know which administrative areas to populate the select list with?
Comment #16
rerooting CreditAttribution: rerooting commentedRyan,
good question!
I was thinking it could behave in one of two ways:
1. A combined Country/Administrative Area exposed filter handler, with options
2. Separate but mutually aware country/admin area handlers
Either way, the administrative area field could be in a disabled or hidden state until you choose country, which would then populate the administrative area option list via AJAX. Thus behaving somewhat like the addressfield form itself. This could even extend further down the line if the issue you mentioned gets into some fancy solutions for sub admin areas, etc.
I can also recall once, on a D6 site, using Location, I had two filters of note - one that was not exposed of 'country' where I chose US and Canada, and the other, which was exposed, of administrative areas which I labeled 'State/Province'. It populated the list with both US states and Canadian provinces (doesn't work with the latest version of location though, just checked, haha!). This could get very unwieldy once you ratchet the filter up to multiple (or all!) countries with lots of administrative areas. However, its a flexibility option that might prove useful to some.
Also, I'd like the choices to be available as select or autocomplete fields, and to allow multiple of course! And a pony!
Comment #17
pyxio CreditAttribution: pyxio commentedAm I correct in understanding this functionality already exists on the node edit/add form? If I choose US from countries the City, State and Zip fields dynamically appear with States pre-populated. I just want to ensure the same functionality is not possible to accomplish with views exposed filters yet. Or perhaps it does and I am configuring it wrong. Just needed a confirmation on this. Thanks. Kevin
Comment #18
rerooting CreditAttribution: rerooting commentedHey Kevin!
Good question, I myself wondered the same thing.
It is not currently available, despite it being available in the field widget. As Ryan seems to indicate, it was very difficult for the addressfield folks to get this working because currently the API for fetching all these various data items is not super flexible (or really a true API?). Once this part of addressfield is refactorered per the issue he indicated, a views handler filter as such should be far easier to implement.
Meanwhile, I've got a strong hunch that I can get this working via Views Autocomplete Filters per recent experimentations with this module. I will be glad to share my results in a blog post on this issue until the upstream issue is resolved with addressfield.
Comment #19
rerooting CreditAttribution: rerooting commentedQuick reportback on VAF : does not seem possible OOTB, but a patch to addressfield or VAF might seal the deal on this provisional fix.
Meanwhile, if folks are interested in moving this along, I'd suggest following Ryan's advice and jumping in on #1829900: [meta] Address Field 2.x needs pluggable administrative areas and an actual API and related issues with testing, patches, ideas, etc.
Additionally, I'd suggest giving further input re: Ryan's questions regarding how we envision these filters to be implemented.
Comment #20
rszrama CreditAttribution: rszrama commentedRight, the big question is how do you determine the country to use in the select list. The simplest format would be a giant list of checkboxes in the filter options - hardly an appealing UI, but the simplest way to give admins access to control which administrative areas are used to populate the list. On the address field widget form, we know the country because it's part of the form input, so it's no problem there to restrict the administrative area options to the currently selected country.
Comment #21
pyxio CreditAttribution: pyxio commentedHey there,
Ahhh what a pity. I think this a REALLY important module. I took a quick look at the Views Autocomplete Filters module and not to sure that is going to integrate seamlessly with this module without a lot of elbow grease. But if you figure it out please let me know. I am sure the good folks here on top of it as well. Anyway, see you over on the Radix side. I wonder why they don't have an HTML5 theme yet!!! Cheers, Kevin
Comment #22
Taz CreditAttribution: Taz commentedSee patch, an elegant way that exposes this select option for a number of the columns available on the address field
Comment #23
pyxio CreditAttribution: pyxio commentedHi taz,
I am very surprised there has been no feedback on this if in fact it does work! I will give it a try today and report back. Thanks. kevin
Comment #24
pyxio CreditAttribution: pyxio commentedTaz,
I was unable to apply the patch
b < 1304288-select-exposed-views-filter.patch
patching file addressfield.module
can't find file to patch at input line 40
Perhaps you should have used the -p or --strip option?
The text leading up to this was:
--------------------------
|diff --git a/views/addressfield.views.inc b/views/addressfield.views.inc
|index 77a5b45..bb0fe97 100644
|--- a/views/addressfield.views.inc
|+++ b/views/addressfield.views.inc
--------------------------
Comment #25
stewart.adam CreditAttribution: stewart.adam commentedYou will most likely need to use the -p1 option, for more information please see Applying Patches.
Comment #26
hass CreditAttribution: hass commentedThis could be written a lot shorter. Use in_array() and you are able to reduce this to one if() condition or more easier to read, use a switch statement.
Comment #27
sheldonkreger CreditAttribution: sheldonkreger commentedAfter applying the patch in #22, I am getting a missing/broken handler error when I try to add the exposed filter administrative_area.
Comment #28
jhedstromThe patch from #22 appears to be missing the new handler
addressfield_views_handler_filter_column
that it references.Comment #29
paul53181 CreditAttribution: paul53181 commentedI have the same issue as well.
Comment #30
heshanlkA new patch attached with the US states.
Comment #31
heshanlkComment #32
oranges13Patch #30 works for me! Ack, I forgot to add there's a call to dsm(); in the patch code which will probably break anyone without devel enabled.
Comment #33
Yogesh Kushwaha CreditAttribution: Yogesh Kushwaha commentedIs it available for all countries? I have installed dev version but it is not coming. Also I Tried #30 on simpletest but got error.
Comment #34
oranges13@yogesh.kushwaha89 You will need to manually apply the patch in comment #30
It has a call to dsm(); which requires that devel be installed and enabled which is probably why it is not working on simpletest, either. But yeah, patches are not automatically included in dev versions unless they're marked as committed.
Comment #35
oranges13Here's an updated patch that removes the call to dsm(); so it should be production ready.
Comment #36
Yogesh Kushwaha CreditAttribution: Yogesh Kushwaha commentedThanks #oranges13,
#35 works for me thanks again.
Comment #37
lunk rat CreditAttribution: lunk rat commented#35 works perfectly. Hunk #1 failed for me when I ran
patch -p1 < 1304288-add-default-state-values-35.patch
So I just patched the .info file manually.
The functionality works great.
Comment #38
epringi CreditAttribution: epringi commentedJust thought I'd drop a patch that applies to the latest dev in the interim, since I've come across the need for a select list as well. Also with Canadian provinces.
Any progress on making this patch more dynamic?
Comment #39
NWOM CreditAttribution: NWOM commented#35 and #38 didn't work for me sadly. Not sure if it has to do with my custom address format module which adds the Administrative Area field for Germany, or if it has to do with the view being a Search API indexed view.
Either way, as a workaround, I added a Grouped Exposed Filter instead which let me add each value for the dropdown manually. I figured this might help those that can't get the patch working.
Comment #40
brooke_heaton CreditAttribution: brooke_heaton commented#38 is bringing up Canadian Provinces only for me. No US States. US States have been removed from patch.
Comment #41
jenlamptonLooks like there are three confirmations that the recent patches here still need work. #35 seems to only add US states, and #38 adds only canadian provinces. Both are hard coded.
I've created a views handler for Backdrop CMS that provides a select list for both Country and Administrative Area. The options in the Administrative Area field are determined by the selection made in the Country field, which is why they are paired together.
It would likely take minimal effort to port this back over to Drupal if anyone is interested in taking it on.
Pull Request: https://github.com/backdrop-contrib/addressfield/pull/11
Patch link: https://github.com/backdrop-contrib/addressfield/pull/11.patch
Comment #42
rszrama CreditAttribution: rszrama at Centarro commentedThanks for sharing, Jen! Just saw that you'd made an Address Field port when I was checking out 1.3. : )
Comment #43
dave.erwin CreditAttribution: dave.erwin commentedHere is the patch from #35 fixed so you don't have to manually copy the line in the info file.
Comment #44
DrCord CreditAttribution: DrCord commentedI was able to port over the Backdrop CMS addressfield country and administrative area code from jenlampton. It took a bit off work and diffing as some of the integral parts of this upgrade had been added to Backdrop addressfield in previous commits. I tracked down those additional changes via diff and added them to make this work as well as making the "Any/All/all" searches work right for both country and administrative district/state/province.
Currently this only shows the administrative districts (also known as states or provinces) that you have addressfield entries for on the field you are using in your exposed filter. This is different than the above patches with the lists hardcoded where you get a full list for the US or Canada, which seems less smart and kinda more frustrating while using the filter but more expected by the general user...I could easily see this being added as a toggle setting on the views exposed filter, to either only show the administrative areas you have data for or to show them all.
This patch is against the latest dev version.
Comment #45
DrCord CreditAttribution: DrCord commentedComment #46
DrCord CreditAttribution: DrCord commentedoof, apparently i added a bunch of whitespace errors, I will clean those up and resubmit this patch, not sure why I got those, but will make it happy :D
Comment #47
DrCord CreditAttribution: DrCord commentedOk, I think I got the whitespace errors fixed in this now, it applies for me fine now to the latest dev.
EDIT: it may only apply cleanly to the latest dev on windows...I'm checking for more whitespace errors now...
EDIT: Nope, seems to work fine on linux, I think this patch may be good to go, if I find anything more weird that needs updated/changed in it I will re-roll it but it works for me and applies cleanly.
EDIT: this patch applies cleanly via `git apply [patchname]` but does not with the "patch" utility. If anyone knows the difference and what to do to fix this, please let me know.
Comment #48
NWOM CreditAttribution: NWOM commentedMaybe it has something to do with all of the white spaces. I was having issues as well with Drush Issue Queue Commands and for some reason I couldn't create a patch after removing the white spaces. If you highlight the entire file, you'll see that there are a lot of white spaces still which seems to be the same problem that I was having. I sadly didn't find a fix.
Comment #49
DrCord CreditAttribution: DrCord commentedHere is a patch without whitespace issues, this one works for me applying it with git or patch.
Comment #50
joelstein CreditAttribution: joelstein commentedIt seems the patch in #49 is missing the Views handler files...?
Comment #51
DrCord CreditAttribution: DrCord commentedThat doesn't seem to be the case for me, but if you want to reroll the patch go ahead.
Comment #52
joelstein CreditAttribution: joelstein commentedMy bad, for some reason my find/replace was being wonky.
Comment #53
Anas_maw CreditAttribution: Anas_maw at Vardot commented#49 works for me
Thanks
Comment #54
oranges13#49 doesn't apply for me. I tried using a drush .make file and I also tried patch directly.
Comment #55
oranges13Comment #56
oranges13#43 is working for us in production if we want to go to RTBC with that patch
Comment #57
biarr CreditAttribution: biarr as a volunteer commentedPatch #49 workes for me. Good solution, thanks!
Comment #58
NWOM CreditAttribution: NWOM commented@oranges13, did you apply #49 to the newest dev or stable?
Comment #59
oranges13@NWOM in my drush make file I have the following
The patch from #43 applies, the patch from #49 does not apply.
For giggles and grins, I also tried using the newest stable in the drush.make file instead, and it also failed.
Comment #60
NWOM CreditAttribution: NWOM commentedOh ok, just was making sure you were applying it to a dev release (since I hadn't tried stable). Weird, via "git apply -v" it applied cleanly for me.
Comment #61
gillesmpem CreditAttribution: gillesmpem commentedNoticed in addressfield-7.x-1.2, addressfield_views_handler_filter_country is properly called, however addressfield_views_handler_field_country and addressfield_views_handler_field_administrative_area are not being called at all.
What I mean is they being totally ignored by Drupal.
Anyone ever tried it out?
Any fix for this?
Comment #62
oranges13Circling back to this. I got the patch from #49 to apply, by completely blowing away the module directory and re-downloading it from git.
Installing the module with `drush make` and drush patching did not work with the patch from #49. I had to manually download 1.x-dev from version control and apply the patch with `git apply` and even then there were whitespace errors listed.
So, the patch from #49 DOES NOT DO what the previous patches did. This does not fix the "Administrative Area" filter into a select list, it only seems to add its own "Country And Administrative Area" filter, which won't work for my use case. In the case of our site, we have a default country, which this newer filter isn't honoring. You can't set a default (to the USA or Canada, for instance) and expose only the state select box, which is what I need it to do.
Comment #63
NWOM CreditAttribution: NWOM commented@oranges13, as you can see from the comments, every person that said #49 worked has most likely used Address Field with Administrative Areas outside of the USA (based on the country in their profile), whereas #30, #35, and #43 literally handles only the USA (since the states are directly added to the patch).
Also, there are numerous Administrative Area addressfield submodules for specific countries which should be taken into account as well.
I may be missing something, but maybe having a closer look at both patches (#43 & #49) with respect to ALL countries, might be a better approach.
Edit:
@joelstein did #49 end up working for you?
Comment #64
dapseen CreditAttribution: dapseen commentedI have been following this issue since 2014, hopefully the following patch i'm about to try works
Comment #65
oranges13Yes, my issue as it stands now is that for the USA specifically, Addressfield includes places like "Puerto Rico" and the "U.S. Virgin Islands" in the select list for state addresses, but the hard-coded patches don't include that.
#49 doesn't solve my use case because we want to have a default country but still have state as a select box (so it accomplishes half of what we need.)
If we could somehow add default choices to the views filter, that would be great.
Comment #66
aitala CreditAttribution: aitala commentedI think this is the patch time forgot...
Anyone else have a solution?
E
Comment #67
oranges13Unfortunately it depends a lot on what you need. Many of the solutions are country-of-coder specific. For my use case, I rolled a custom patch that fits our use case (USA, including some of the outlying islands but not all of them). Unfortunately I know that won't work for 100% of the drupal audience so I did not provide it.
Comment #68
aitala CreditAttribution: aitala commented@oranges I would not mind seeing that patch as that would be more maintainable than the current situation.
Or would it be possible to roll a custom module to handle this? Then have a way to share those?
Eric
Comment #69
oranges13@aitala Here is the patch.
In my case, we needed all 50 US states + Puerto Rico. Those are hard coded, however so it's not very transferrable to other users.
Comment #70
aitala CreditAttribution: aitala commentedI'm using basically the same patch but w/o PR.
Eric