State Field Option List

Orson,

hmmm this is the problem. Its about the same problem i face using autocomplete.

On Location D5 i was only opted to use autocomplete because i failed in doing the same with select list. However, im had some new ideas that might be possible to do so. (Yet unsolved for disabled JS users). I will try it in a few days.

regards,

massa

This is something I'm interested in as well. For a country with a limited number of provinces, a dropdown is easiest.

At the least, the field should note that the abbreviation is to be used. Most users will end up typing the full name, causing a needless form error.

I may look at this soon :)

Here is a patch which takes a slightly different approach. Dealing with looking up the country and showing appropriate provinces with JavaScript is a pain, and obviously doesn't work unless you combine lists for non-JS users. Instead, this patch lets users type in the full province or state name, and then converts it to the province code on validation. This also increases the maxlength for province fields to 64 characters, as 16 isn't enough for full names.

This could be a very stupid remark, but why do you choose for an autocomplete field while a pulldown list seems so much easier for the enduser? Most big applications online where I have to register (thinking about FaceBook, Hotmail, ...) all use a pulldown list.

Are there countries with that much provinces that it would be a problem?

It's not actually an autocomplete field. Instead, it just lets you type in the full name of the province instead of just the abbreviation. So, with the patch you can now type "Ontario" instead of being forced to do "ON".

The reason it doesn't do a dropdown is because you can select multiple countries, meaning you have to do a javascript AHAH replace for the list of valid provinces if you have a large number of countries. I'm personally not against such a feature, but it would take more time to do :).

The weird thing is I can't get it working for Belgium. When I type "Limburg" (a province in Belgium) it doesn't work. I also tried LI (abbreviation).

this may sound crazy, but... i can't get this to work for ANY countries! i am running Addresses 6.x-1.05 on Drupal 6.9, using it for User Profiles at this point only... the fields appear in the User Reg page as expected, but the state/province field is showing up just as a regular textbox, with no autocomplete or select list or anything else to tie it to those lists of states/provinces in the addresses/countries/*.inc files... what do you need to turn on to use this feature?

cheers
Fish

@codemann: So it works for other countries? Try Canada and see if it works (since that's what I tested with).

@goatvirus: Please see my comments in #5. This patch doesn't implement full auto-complete functionality, but simply allows users to use the long or short forms of provinces. A patch implementing #autocomplete functionality would be nice though, so feel free to write one up!

@deviantintegral: it works when I use "VLI", which is the code that I found in be.inc. But the full name is "Limburg" and in short I would try "LI", but off course not "VLI", the V has no meaning there. I assume that "VLI" is used because "LI" was already used elsewhere?
An autocomplete or even better a pulldown of the full names would be the feature everyone wants off course! :)

I think the whole concept of allowing users to freely type in province names and having to match an entry in a limited list of provinces it just plain crazy from a usability perspective.

First of all, people are going to make spelling mistakes, as most people are bad spellers. Secondly, there could be numerous spelling variations or aliases for one province, which in practice reduces the province field to a guessing game.

Also, there'll always be provinces that aren't in the database.

Personally I haven't yet been able to type in anything that this field would accept. Luckily we don't have provinces in my country, so if our users just leave the field blank, we won't have problems there, but whenever someone from abroad tries to register, they're told that the province they typed in doesn't exist.

Of course everyone who tries to enter an address with a province on my site gets furiously mad. And I can totally understand them.

So if users can only choose from a pre-defined list of values, a select box should clearly be used. But why not - even better - remove the pre-defined list and make users type in what they want?!

Subscribing....Need an option list

Is it possible to get a drop down list for state and city?

Subscribing...

What about using something like hierarchical select http://drupal.org/project/hierarchical_select
It would seem to be perfect for something like this.

suscribing too, I've been unable to input anything the field will accept, this will drive all our users mad, so this module can't be used until this is fixed. Good work with the rest of it, though!

This is what I’m using to have a states(provinces) as select list that is auto-populated each time the county is changes (USA is default):

1. http://drupal.org/node/182310 - add #DANGEROUS_SKIP_CHECK as it was in Drupal 5

   In /includes/form.inc need to replace

   if (isset($elements['#options']) && isset($elements['#value'])) {
   with 
   if (isset($elements['#options']) && isset($elements['#value']) && !isset($elements['#DANGEROUS_SKIP_CHECK'])) {
   

2. I’m attaching 2 files that you need to replace in addresses module(6.x-1.05) :
   addresses.module
   addresses.settings.inc
   just take a look on functionality that’s has //New: mark in comments
3. The changes in this files to make states auto-populate working are:
   1. Add new menu item
      i. Path admin/settings/address/province/%/%
      ii. Callback _addresses_get_states($field_name, $delta) in addresses.settings.inc
   2. Add new functions arguments to use form element values as #name, #id
      i. addresses_addressesfieldapi($op, $fields = array(), $values = array(), $element = array())
      ii. _addresses_addressesfieldapi_form($fields = array(), $values = array(), $element = array())
      iii. everywhere where this functions are used
   3. Add #ahah behavior for country and select for provinces (states)
      i. $form['country']['#ahah'] = …
      ii. $form['province']['#DANGEROUS_SKIP_CHECK']
      iii. Default country is USA

suscribing - need dropdown for province/state.

#16 works with warnings and don't want to modify core files.

this module http://drupal.org/project/profile_location seems to have found a way to implement this. Not sure exactly if it will be what is needed, but it might help.

Don't have time to submit patch, but this should be quite easy using core #ahah drupal possibilities with 6.x.

fix #16 to work with user_addresses (#16 was for CCK only)

Attached is a module for the addresses module that creates a select dropdown of provinces for the selected state and saves it correctly. This module works in most standard installs. For it to work two conditions apply:
1. country and province fields must be switched off in addresses configuration for the content type
2. the country_select module has to have a higher weight than the content module. The .install file sets it to 1 so it should work out of the box if weights have not been changed.

Package also includes the activeselect module which is required.

Enjoy
Passing Phase Web Development

subscribing

Out-of-the-box the provinces in this module are unusable for UK users. Making users have to guess the format of this field is unreasonable. Until that's fixed I have to abandon this module.

Attached is a patch that turns the province field into a select field controlled by the value of the country field. I have it mostly working, but don't know enough about CCK to fix the remaining bugs such as loading/saving values. Anyone with knowledge of CCK that could contribute would be great.

Cheers,

Antoine

I tried the files at #20 but I get a 403 error in a popup when I try to change the country:

An HTTP error 403 occurred. /admin/settings/address/province/addresses/-1

It works if I just choose a province and don't change the default country.

(It would be nice too to have a way to choose a default country in this module instead of having it hard coded.)

subscribe

I talked with Bruno last night and will be helping maintain this module. That means, that when patches have been reviewed by the community, I can commit them to the repository and create releases. I can't commit patches unless they have been reviewed, so please review the patches.

That said, I have improved upon my patch in #25. It completely fixes this issue by turning the province field into a select list that is populated based on the current selected country. It also fixes the issue of data not being saved. Please test and get back to me ASAP so I can get this committed. This has been a thorn in the side of many people.

This patch is also against the latest code in the repository, so I am changing the version to 6.x-1.x-dev.

Cheers,

Antoine

Found a bug where I forgot to set the default value of a parameter to a function.

Cheers,

Antoine

Just applied #29 to the latest dev release and it just breaks my site, I get a blank white page.

Marcus178,

A blank white page means your http server had trouble with the code. Could you please look at your http server error logs and report back what you find. I would like to get this fixed for you ASAP!

Cheers,

Antoine

Marcus178,

I found the errors causing the white screen. I have attached a new patch.

Cheers,

Antoine

Hi Antoine,

Because I don't know how to apply a patch to a module, I downloaded the 6.x-1.x-dev (2009-Dec-15) and thought that this downloaded module contained the patch you mentioned in #32 (2009-Dec-14). However, the State field does not change to an Option List when I change the country field to either United States or Canada in the User Registration form at user/register.

I need to have this fix as soon as possible. Would you please put your latest code into either Recommended or Development releases? I appreciate your help and thank you so much.

Kit

Hi there,

Would any one please help me? Thank you very much and have a Happy New Year.

Kit

I applied the state patch for the state option and for the cck patch.

When I run the update after applying both patches, I get the following error:

user warning: Table 'vitaesha_drp01.variable' doesn't exist query: DELETE FROM variable WHERE name LIKE 'addresses_format_%' in C:\www\drupal-6.13\sites\all\modules\addresses\addresses.install on line 30.

This is the query that failed:

addresses module
Update #6106

    * Failed: DELETE FROM variable WHERE name LIKE 'addresses_format_%'

Neither the state drop down box appears nor are the variables available to CCK.
I'll cross post in the CCK issue.

Took it in smaller steps this time.

1. pulled down the head version of addresses
2. applied the patch
3. moved code to localhost
4. checked to see if there where updates to run at update.php, there were none
5. added only Canada and United states to the country list
6. accessed the addresses via user profile tab
7. created a new address in the united states - there is a pull-down list for states and it appears to be accurate and works.
8. created a new address in Canada - the pull down list is for states in the united states -- NOT canadian provinces and I get the following error:

An HTTP error 404 occurred. 
/drupal-6.13/addresses/province_js/a%3A1%3A%7Bi%3A0%3Bs%3A9%3A%22addresses%22%3B%7D

Same environment as before: WAMP, Apache 2.2.11, Php 5.2.9-2, Mysql 5.1.33, Drupal 6.13

Hi AntoineSolutions,

Thank you for the patch at #32 (http://drupal.org/files/issues/addresses-244471_4.patch).

After I applied this patch, everything is fine except the required status of the "State / Province" field. This is the problem: I have made the "State / Province" field required and when I select a new country in the Country field, the "State / Province" field becomes not required. Would you please tell me how to fix this problem? Thank you and I appreciate your help.

Happy New Year!

Kit

@bekasu comment #36
You need to flush your cache as the patch creates a new path at addresses/province_js/%. Once you do that Drupal will recognize the path and you won't receive the 404 error. Also as a note to your other post, the update's Delete query performed fine on my instance of Drupal 6.15.

@kit22aa comment #37
The way the patch functions is that the first province listed is selected by default, thus any required check would be fulfilled. It would be possible to have a default item such as "Please select" at the top of the province select box, but I do not know if that would be desirable.



I am going to investigate the following to ensure that the system is usable:

What happens when the user has JavaScript disabled?

• Does Addresses intercept and prompt the user to select a province matching their country selection?
  We would have to ensure that countries that do not have states pass through this check.
  We would also have to create a system in which users can easily choose the province desired without presenting the user with errors should the option needed not be presented (ie. they have changed the country selection)
• Is an input box provided?
  If so then we should really expand the patch to allow users to enter the spelling of the state/province and not just the abbreviation.
• Does the user have to submit the form and then edit it to get the Province list?
  This is the worst option as it requires a user to edit a node/profile after they set/change the country and could be very problematic in many ways...

I attempted to create a node through the CCK add-on with an address and changed the country to something other than United States and received "An illegal choice has been detected. Please contact the site administrator." as the error for the province not being a province of the country selected.

From a usability perspective this is very bad as it tells the user that the system is broken. From running through the process in my head this would be the most usable implementation:

• When the form is generated it is created as an input field.
  • The field would include a description which prompts the user to "Enter the two letter state/province code"
• For users with JavaScript enabled the input field and description would be replaced with the select box through jQuery on load which would also select the value rendered in the input field, if one is available.

Following this logic a select box would never be rendered directly from Drupal's form API for the province field and instead would only be created through the existing _addresses_province_js() call. In addition a small amount of code would be needed to make this call on load so that users with JavaScript see the select field available instead of the input box.

Changed status to needs review

@codycraven comment #38

Thank you for your comment. I think I did not describe the problem clearly.

Let me describe it in details as follows:
I make all the address fields such as Street, City, State / Province and Country required, so, labels for these fields all have red stars next to them. When I select a new country in the Country field, states/provinces corresponding to my selected country populate the "State / Province" field, but the red star next to the label "State / Province" is not shown any more. The disappearance of this red star is very obvious because labels for all the other fields still have red stars next to them.

If you know how to fix this problem, please let us all know. Thank you and I appreciate your suggestion and help.

Kit

Kit, I understand what you are saying and will look in to the issue with Antoine - I have made this a separate issue #679452: State field option list required marker as I'm afraid it will get lost in the current progress of the patch. My previous input in #38 was regarding the fact that the State/Province field requirement will always be fulfilled by this patch as there is not option for a user to submit the field blank. Thus this is really just an aesthetics issue.

Once the state field patch is finalized I will look further in to the issue that you have brought up and see what we can do to keep the aesthetics of the form consistent in regards to the required marker. If I am missing something please add it to the other issue created.

From my post in #39

I am making a decision, as I have not received any alternatives/feedback on my proposed design, to proceed with my proposed solution to improve usability of this add-on.

I will begin programming the changes in the next day, so if you feel that the proposition has flaws please let me know immediately and we will evaluate the best way to proceed.

One thing I would add is there need to be an option to have the select box contain the short or long version of the state/province, as here in the UK there is no short form for county names, or even a standard universal list of what anyone might call their 'county'*. Hence #24's issue with he current system.

*When asked I might say Greater London, West London, Middlesex, etc depending on what control/list a web form has available (None of which are in the current list, it would take me a few tries at the form before Ealing was accepted).

RalphSleigh,

Thank you for your input on UK provinces/state field. If you are knowledgeable about administrative divisions in the UK I urge you to open a new issue with a list of which divisions you feel should be available through the module and the reasoning and sources supporting your input.

As far as long vs short, the idea behind this patch is that you browse the available values through a list in which the state/province is listed. Thus there is no need/reason to have the ISO alpha 2 values displayed. Once this patch is finished I will be creating another to allow users to either enter the full name of the state/province or the ISO alpha 2 value in the event the user has JavaScript disabled.

Re-rolled patch from #32 to apply against latest HEAD.

After thoroughly going through the patch from #32, I have found that there are many, many unrelated changes in this patch which is making review incredibly difficult. As such, I will go through the patch and pick it apart only using functionality improvements to further the issue.

As a note, many of the changes are good changes which improve coding standards, however they just make reviewing/improving this already complex patch too difficult. As such I have opened a new issue to improve the coding standards throughout the module, many of the changes so far based on #32, in #687138: Improve code readability.

When will autocomplete for the state field be complete?

I put this module up on my site and see the countries list, but the state list never autopopulates or fills when you select a country. How can I fix this issue?

Natalie, this is actually something that I am working on at this moment. It will probably be a few days before a working version is committed to HEAD and probably a week or two until the release of 1.07 - which will include this fix, along with some others.

Just a note, I will be taking over the further development of this issue as Antoine hasn't been active recently and this is an issue that many users are in desperate need of.

What I will be doing is creating JavaScript that will replace the current province text field on load and upon change. This will ensure the module gracefully degrades.

I will not be using AHAH as I can not securely implement it in the variety of situations that the module requires, and I do not wish to modify the hook_addressesfieldapi().

Thanks, Cody!

For my own sanity, here is a list of the formatting of rendered address fields:

• User settings / address book
  • wrapper:
    • ID: edit-addresses-wrapper
  • country:
    • ID: edit-addresses-country
    • Name: addresses[country]
  • country wrapper:
    • ID: edit-addresses-country-wrapper
  • province:
    • ID: edit-addresses-province
    • Name: addresses[province]
  • province wrapper:
    • ID: edit-addresses-province-wrapper
• CCK implementations - # indicates field key in incrementing array sequence
  • wrapper:
    • ID: edit-field-address-#-wrapper
  • country:
    • ID: edit-field-address-#-country
    • Name: field_address[#][country]
  • country wrapper:
    • edit-field-address-#-country
  • province:
    • ID: edit-field-address-#-province
    • Name: field_address[#][province]
  • province wrapper:
    • ID: edit-field-address-#-province-wrapper

Patch containing my current progress

[edit]
Sorry I forgot to strip out the path of my editing environment. If you wish to apply the patch you will need to do a Replace All on the file for public/sites/all/modules/addresses/ and replace it with nothing, then apply it to your addresses directory.

So that you know this issue isn't going stale I've been working on #692644: Allow province/state field to accept province/state's name. This integrates closely with this issue, I found myself inadvertently working on the other issue while developing the state field option list, and thus broke it in to it's own issue to keep this patch as simple as possible.

Please review the attached patch, you will need to clear your cache as there is a new entry in hook_menu().

Note this degrades gracefully :D

I am trying this out now... thanks!

Natalie,

Let me know how it worked out for you and I'll commit if you have no issues.

Since the patch has gotten no feedback, I am committing and will handle any issues discovered in separate issues to better facilitate development.

This worked out well for me. When are these changes going to moved from a DEV state to a release state?

Anyone else try these out?

I'm looking to fix a few other issues before releasing 1.07, once they are ready it will be included in 1.07.

ok thanks again Cody!

Patch does not work properly, the 'addresses-province-field' class is overridden in function addresses_elements_process().

Please review patch to fix this.

Thanks.

Patch in #63 worked for me. Thanks lesergi!

often in Drupal we use:

    _form_set_class( $extra[$ename] , array('text') );

It is a private function from the form API, but it is very commonly used to replace such code:

      if (isset($extra[$ename]['#attributes']['class'])) {
        $extra[$ename]['#attributes']['class'] .= ' text';
      }
      else {
        $extra[$ename]['#attributes'] = array('class' => 'text');
      }

I applied patch in #63. The _form_set_class() may duplicate all the entries (the $class array should make use of keys equal to the class name.)

Thank you.
Alexis Wilke