State / Province drop down and Full State name in address field

I would also like to see the state/province as a drop down menu.

This would be great as an option to use instead of the auto-complete, especially with some of the varying ways to enter provinces (e.g., in Jamaica, the standard way to name a province is St. Andrew, but in Locations it's expanded to Saint Andrew -- which I'm sure is conforming to a wise standard, but causes some confusion when the St... doesn't auto-complete.

+1
I'm not a fan of the autocomplete, and many of my clients don't want it.

moving this to HEAD

+1 for drop-down option

After searching, I don't think there is a module that would enable this feature. Would like to see this integrated.

tagging

Hi,

Is there any updates on doing drop down for state/ province field?

+1000

See how this works for you.

Subscribing, greetings, Martijn

Patch only work for first time.. first time it shows state of US what about when we change Country

I need this functionality as well. I will post any success I have in implementing / finding it.

Great! Looking forward to it!
Greetings, Martijn

Subscribe +1

Agreed and following also.

Subscribing

Wait...The patch mrtoner made...Is Drupal-Tech saying it works for US and nowhere else, or works for US once and when country gets changed stops working at all?

works for me (US)

Though this should probably be a configuration?

Yes it works only for the default location,
ie if it is UK it shows states in UK same with USA.
Changing the country has no effect on the states. ie if I change country to xyz the states will still be showing the states in the default country.
I think the patch works partially, but think it needs a new location_autocomplete.js to make it work properly.

Bump

Especially with some of the lacking information about states in a lot of non-Western countries; this would be really helpful.

Also - I've already sunk a lot of time into updating some of the /supported files; should I start submitting them?

subscribing

BTW the patch in #10 worked for me.

subscribing.

I think this is an essential feature. I have to make this field required so that I can map correctly, but many of my users can't find their correct state/province through autocomplete. A drop-down is a must.

subscribing

I agree, this is essential. Like the above, I must require this field for proper mapping, but many of the users can't find their closest state/province which means they can't complete registration.

May be using hierarchical_select for this (www.drupal.org/project/hierarchical_select) ? That works great for taxonomy and nodes, but I do not see a location submodule yet. I am not a programmer, but would test for the builder off course.

Lots of blogging about it, see masterissue: http://drupal.org/node/31609#comment-906923. I think Wim and Bdragon didn't get in touch yet...

greetings, Martijn

subscribing

My 2-cents - - I very much need this, too - - in my case, I would love to have the ability to use JS to control specific options within a drop-down if the country has state/province info and a non-autocomplete text box for unsupported countries.

The main issue for our site is that we require the state and country and city for a node (and user) but find it is quite easy to fail validation WRT state-city matching (in the US). (Note that we are using the non-CCK implementation as this worked best for us.

Also, the current autocomplete is insensitive to country, so that a node located in (for example) the UK will auto-suggest US states. (Noting that the default country in our case is set the US) - - apologies if this is contained indifferent thread (I will search this out).

So, my wish-list is as follows - - and I would massively grateful for guidance as to patches and snippets:

1) drop-down for state-provinces that are supported - - use JS to swap in the correct widget or to populate the options within the select (the latter being preferred for obvious reasons).

2) in non-supported countries, use a non-autocomplete text box and allow mistakes (that is, do not validate country vs. province)

Has anyone done this sort of thing before? If so, love to pick your brain (and will certainly return the favor if I can). I am in the process of constructing a module to deal with this sort of thing.

thanks to all

n

Update to the previous post.

First of all - - apologies for posting before properly researching this (IMHO) excellent module / api (notwithstanding other (not-so-appropriate criticisms I have seen).

So, here is what I am doing:

SUDO:
in the node entry form, substitute a select drop-down for the current text box (not quite how I will do this yet) with the appropriate id and name and so on.

default to the US.

use location_get_provinces() to fetch an array of provinces

populate the box.

When the user changes country, use jQuery to detect the change and use ajax to call a module-based function to return a new select box (via json) to swap in.

submit the country in the ajax data - - seem to be able to use the simple jQuery load function.

I have run preliminary tests on this and it works - - but have not tried to submit it.

The question I am now looking at now is how to make sure the name and id match what the module expects and whether I can pass validation.

Concrete question:

the current text field ids output via my template as follows:

Thus: I will try to substitute something like this?

Does this make sense?

if so, then I will gladly post the php and jQuery snippets.

Goals - -

1) avoid complex client-side tricks

2) avoid validation errors by offering only options that are valid WRT the selected country

3) simple and hard-to-mess-up UI

Thoughts from anyone?

Thanks

S

This patch addresses the issue raised in the title.
This patch also addresses some bugs raised in comments #12, 17, 19 that provinces only reflect the default country setting.
Further questions raised within this issue, e.g. "Also how can you add new provinces?", should be addressed in a new issue.

newtonpage raises quite a host of topics in comments #27 and 28, those of which relate to the original intent of this issue are addressed by this patch. I confess I have not spent the time to grasp the full extent of the content of those comments. Please feel free to retool this patch and resubmit if anyone would like to further develop this patch. Please address those concerns only as they are relevant to this issue. Further issues, UI improvements, or more fundamental changes to the system should be raised in new issue(s).

Overview

General:

• This patch maintains full backwards compatibility for existing installations. None of the changes in this patch will affect existing implementations adversely.

Admin notes:

• Admins can now select whether State/Province fields should use "autocomplete" (default) or "select" widget in the "Collection Settings" fieldset of the location administration form (applies to CCK and node_ and user_location)
• If selected, "select" widget replaces the default autocomplete on the user-facing location form

User-facing notes:

• the select widget is initialized with the appropriate options for the default country
• If "country" is being collected, the select widget is updated with the appropriate options each time the user changes the country field

Developer notes:

• Implemented javascript menu callback location/fetch_provinces to retrieve json'ified list of provinces for the selected country
• Updated location_invoke_locationapi: for $op = 'field_expand', $a4 now expects an array of field-specific settings in the same format returned for $op = 'default', e.g.
  
  array('collect' => 1, 'default' => 'us', 'widget' => 'select', 'nodiff' => FALSE)
• State/Province options are initialized in funciton _location_expand_location in order to maintain state across form POSTs
• Implemented function location_field_widgets to encourage further extensibility
• Extended javascript library (location_autocomplete.js) to support rebuilding "select" widget on country change.

Moving back to HEAD.
I'm torn between calling this a feature request or bug report.
Since the latest patch doesn't address any of the javascript-based usability concerns, I'll leave it as a feature request.

Again, if you need support relating to this issue, please open a new issue or go to the forums / irc.

I apologize to all if I posted comments #27 and #28 within the wrong thread - - by way of explanation, I began with a concrete question but then segued into proposing a solution for my particular requirements - - which are (simply stated): to present the user with a dynamically populated states/provinces select widget keyed to country.

As a note, I have solved my problem and it works well - - and while the referenced patch addresses some of my issues, there are enough things I need that are not addressed that I have implemented a solution that does not require patching.

Note that one reason I needed this is that this site is international and the node form of interest requires correct entry of both country and state/province - - this is, of course, not unusual - - but in our case, we were failing validation under the following (common) user-input cases:

1) users in the US could (and often did) input misspelled/malformed states in spite of the autocomplete text field;
2) non-US users had the same error-possibility as above but were also presented with the US-based states in the autocomplete;
3) further, for some countries, users were entering provinces that they felt were correct but which did not match the DB - - thus, triggering validation errors that they could not understand.

While failing validation is not disaster, it did present challenges in the error-case UI since this is a multi-stage form. Thus, avoiding easy-to-create errors is a priority. In essence, this required a "guided-path" UI that forecloses the possibility of incorrect input (short of hacking the form, an error cases trapped by standard validation provided by the location module).

For those who need something like this (to present a dynamic states/province select widget keyed to country), I am happy to post the code. In my case, I used code in a template for this form, a small js file that uses jQuery and small module for ajax callback. It is not complex and works quite well.

If posting this solution is desirable, where would the issue maintainers prefer I post this? Sorry for my ignorance, but I honestly do not know.

thx

n

+1 to post your solution!
Greetings, Martijn

I am happy to but do not want to "clog-up" this thread - - where should I post? as a reply to this comment?

I think so, it has to do with the dropdown, so no clogging up, right?
greetings, Martijn

I suspect the moderators may yell at me for this but here goes:

Here is what I did.

Requirements:

- - country default = US;
- - state select box on default contains the US states;
- - location elements are non-CCK;
- - when the country select box changes, the state / province select box is auto-filled when with the provinces supplied by the location module.

In my template that renders this form, I did this:

I create the select box and populate it with the US states - - AND also render the state text fields BUT hide that field in the CSS (I used display: none;).

Thus:

Note again that the text box is hidden via CSS.

Then, in a jQuery file (I created one to go with a module that controls these elements), I did this:

Then in a module:

Next, I discovered that the location module wants the submission for the province field from the text widget only. so, I write the currently selected option text to the hidden text field that was output by the template (the one that I hid with the CSS).

So, after the json object is returned, I do this:

Finally, I detect when a change-of-state occurs in the newly-populated state / province select box and write it the value to the hidden text field:

Note that there are a few supported countries with no provinces (Vatican, for example, as well as a few in the Caribbean).

Since this case will yield an empty array, I trap this in the module-based callback by returning a text string rather than an array. (This logic is not shown in the snippets but is obvious.) The javascript detects this and hides the select box and inserts the phrase. In my case, I used: "This country has no provinces". Other techniques may suit you better.

So, in this case, since the location validator accepts an empty field for these countries, I make certain the hidden text field is empty.

Net-net, this works nicely. Some may view this as a hack, but in my view, it is, rather, a workaround for an excellent module that provides lots of other functionality. Also, in my opinion, it really only requires a few lines of code.

Note that I use a custom throbber while awaiting the json return (which the jQuery "shows and hides" as appropriate) and have other UI features that I have excised from these snippets.

If this were to be generalized and integrated into the module, it could be done in similar fashion to five-star where the admin pages offer the ability to use a js - ajax callback - - and this can be either the pre-canned one or one you supply. The js could be easily rolled in - - but does require at least jQuery 1.2 (I use 1.3 here). But I suspect that this may not be at the top of list for new features.

Questions and critiques welcome.

n

newtonpage:
There's nothing wrong with posting another solution - that's what this forum is all about.
However, it's very difficult for others to test your solution without a proper patch (see http://drupal.org/patch/create for an explanation).

After reviewing the code you posted I think we're both working towards a similar solution.
I think the best pieces of both could be combined to reach an optimal solution to this issue.

I'll take a stab at rolling a combined patch as soon as I can if no one beats me to it.

hello aaron

thx for the reply - - sorry for my long-ish reply here - - net-net I would be happy to help in anyway I can.

As for patching, I am quite inexpert at rolling patches. But . . . I promise to work on this as I want to be useful contributor here.

I suppose that (assuming that I "cure" my patching experience), a patch would 1) create a menu item; 2) create a new callback for this item. I assume this would go into the location module and this seems simple enough.

But in my solution, I assume: 1) that there is "target" select element into which the json returned data is placed. If there is a default country (as in my case), the theme layer populates this select with the default country's provinces /states. If there is no default country, there must be a blank target - - and again, in my case, I made that target a select element. But this may not suit everyone as it assumes my theme layer deals with this.

I looked at creating the select element in the location module but, to honest, I was afraid I would break something - - especially since I had to "workaround" the fact that the module (seemed to) require input from a text element, rather than a select element. But it appears to me that a patch would have to modify (at least): 1) location_settings() (to offer the option of a populated select box); 2) location_locationapi() (case = "field_expand" / case = "province") (where there would have to a logic branch to bypass the existing code in the event that a select is chosen - - and wherein it returns a element with the options supplied by location_get_provinces($default_country).

Again, to be honest, I was afraid of breaking something but - - agin - - I will help in any way I can.

BTW - - in the post that follows is the result of our researching what "provinces" are called in each supported country.

n

This follows up previous comments #35 and #37.

Note : aaron - - I include this if the event that it would be useful - - and again, if I can assist in a patch, I am happy to do so.

I am not certain if this would like to be rolled in the patch discussed in comment #36, but here it is.

In our application, it is desirable to make certain that a "province" was correctly named (and we are looking at the translation aspect, as well but only support English at the moment).

So, if, for example, the country is Slovakia, they call their provinces "Prefectures", whereas, the Cyman Islands have "Districts".

Further, if there are no provinces, we need to display that we cannot find them - - for example, the Vatican may be selected as a country but has nothing like a province.

The implementation is rather simple but detailed:

In the module callback, we first test if the country has provinces in the db - - if not, we return -1 in the JSON. This was developed by trial and error. We took the approach of testing with a case statement but may change this.

Then if the array in non-empty, we do this:

The function that is called above to create is the "insert" phrase (named select_section() ) is as follows:

If this format is not useful, I can supply the raw data.

Finally, in the jQuery that supports this form, we split the first option text and extract the proper phase for form announce section.

Thus, for the Cyman Islands, we output "Please Select District" followed by the dropdown with the districts.

newtonpage, re #38:
this is great work - looks like you did a lot of research, so thanks for sharing.

I agree that the switch/case is unwieldy. Probably the best way to go would be either a mapping table with this data, or some kind of solution involving Drupal's translation system (I'm not very familiar with i18n support, so I don't know how feasible that would be).

Either way, this discussion is tangential enough to merit its own issue.
Let's try to keep the focus of this issue on the input type of the field.

I understand and appreciate the kind response - - as a note, I posted #38 in the event that something like this may be included in a patch since this code is included in the callback in my current solution. The switch/case structure is clunky but was the shortest path for me at the time. There are certainly many better ways to do it.

looking forward to helping with this issue going forward.

n

OK, I've rerolled the patch to take into account concerns about the handful of countries with no provinces.
After reviewing the comments in this thread, I am fairly certain that all concerns relevant to the original issue have been addressed.

This patch is almost the same as comment #29,
with the following change:
if a country is selected that doesn't have any provinces,
the State/Province <select> element is truncated to a single value:
<option value="">n/a</option>

This hopefully eliminates any user confusion about whether to leave the default "Please Select" value, or to choose "NOT LISTED".

This patch does not address #636464: When State/Province is required, cannot validate for countries without States/Provinces

Either this isn't working properly, or I made a slight mistake when I manually applied the patch. If that's the case, perhaps someone can help me figure out where that was. I was able to toggle the collection widget between autocomplete and dropdown, but the collection form isn't updating the available provinces when I change the country. In the screenshot, I've set the country to Argentina. It's still showing the US provinces, and there's a "()" between "NOT LISTED" and "Alabama", which leads me to suspect I may have broken some syntax. In a view I've created, nothing has changed since I applied the patch, although I've tried removed the provinces filter, saving, and adding it again, as well as clearing both Location caches. The exposed filter continues to display as an autocomplete widget, and only loads US states. When I un-set my default country in the Location settings, the widget fails to load any states/provinces at all.

Ideas?