Change the order of address fields

Can you explain a little more? Is it saving address formats properly but not using them to format customer addresses? Does it always use the store format? I looked through the code and didn't see anything suspicious on a first glance.

Oh, I see... in the actual entry form. Yeah, this is by design, because the formats are only intended to affect the actual display of an address. Those form elements would have to be rearranged in a custom module using hook_form_alter() to adjust the #weight on the individual elements you want to rearrange.

I made such a small module (called uc_customizations) to change exactly this. Perhaps somebody can use my code as an inspiration:

function uc_customizations_form_alter(&$form, &$form_state, $form_id) {
  if ($form_id == 'uc_cart_checkout_form') {
    $form['panes']['delivery']['delivery_company']['#weight'] = -1;
    $form['panes']['delivery']['delivery_first_name']['#weight'] = 0;
    $form['panes']['delivery']['delivery_last_name']['#weight'] = 1;
    $form['panes']['delivery']['delivery_street1']['#weight'] = 2;
    $form['panes']['delivery']['delivery_postal_code']['#weight'] = 3;
    $form['panes']['delivery']['delivery_city']['#weight'] = 4;
    $form['panes']['delivery']['delivery_country']['#weight'] = 5;
    $form['panes']['delivery']['delivery_phone']['#weight'] = 6;
  }
  if ($form_id == 'uc_cart_checkout_form') {
    $form['panes']['billing']['billing_company']['#weight'] = -1;
    $form['panes']['billing']['billing_first_name']['#weight'] = 0;
    $form['panes']['billing']['billing_last_name']['#weight'] = 1;
    $form['panes']['billing']['billing_street1']['#weight'] = 2;
    $form['panes']['billing']['billing_postal_code']['#weight'] = 3;
    $form['panes']['billing']['billing_city']['#weight'] = 4;
    $form['panes']['billing']['billing_country']['#weight'] = 5;
    $form['panes']['billing']['billing_phone']['#weight'] = 6;
  }
}

I'm reopening just to ask whether it'd be possible to have such weights set in the usual Drupal drag-and-drop way on the admin page admin/store/settings/checkout/edit/fields?

Marcus

With the current 6.x-2.x-dev version of Extra Fields Checkout Pane you will have the ability to change the order of the address fields. Applies for addresses belonging to the order or belonging to UC Addresses, but not for the store address for example.

Let's work on this for Ubercart 7.x-3.x first.

Clarified issue title.

I'm thinking of adding this functionality to Ubercart Addresses 7.x-1.x: I would make the address fieldable and changing the order of Ubercart core address fields would be made possible by implementing the hook hook_field_extra_fields(). To be able to display extra address fields in the address format, the address formats would be configured by using tokens. This is what Ubercart Addresses 6.x-2.x-dev already does.

There are two subtly different things going on here. Firstly it would be good to be able to rearrange the address fields at all, but secondly it would be even better if the address field order followed the per-country address format strings. I think the latter should be possible but it also might be slightly disconcerting if the address fields moved around when different countries were selected.

@longwave
It doesn't sound like a good idea to base the order of the address fields on the address format string. I think it's a better idea to make the address fields draggable on the address field settings form. This is what Extra Fields Pane 6.x-2.x already does:

Features

The 2.x version has the following features comparing to the 1.x version:

• Address fields appear in original delivery and/or billing panes
• Support of the field types textfield, select list, checkbox, constant, php string and php select list.
• Ubercart Addresses integration (see further)
• Ability to change the order (weight) of address fields
• Availability of an extra information pane

See also image.

The request in #2 does kind of make sense to me. If the address fields followed the country format string you could easily put first name and last name or state and zipcode on the same line, if you wanted to. Of course coding the ability to do that would be the harder part :)

This is more important in fully international stores, when e.g. users in Japan expect to enter their address in the opposite order from users in most Western countries.

@longwave

it also might be slightly disconcerting if the address fields moved around when different countries were selected.

I think you hit the nail on the head. It may be "bad UI" to have the fields in the "wrong" order for some countries, but I think it would certainly be worse to have them jump around on a user if they change the country. As an aside, how much of the address gets entered before they even enter the country? In a stock 7.x config, its all of it save the postal code.

So... Do we move Country up to the top of the form? If it changes, do we use AJAX to reorder the fields, or do we do a submit and reorder on load? With the former I think you have to throw up a message to the user that the address fields have been rearranged....

And does every admin want the country selector at the top of the form? What if they only support one country?

From a programming standpoint, changing the form to match the country address formats makes sense, but at the same time forces some really bad UI decisions. I think that if a foreign shopper is visiting the site there's a reasonable expectation that the address on the foreign site might not use the same terminology, or order as their own. At the same time, we cannot presume to use a US/UK format for everyone. I would suggest a site-wide address field order w/o the country-based reordering. If we go ahead with a country-based reordering, I strongly recommend a default country be selected in the admin interface along with an option to disable the reordering.

Well, I'm willing to review patches that implement either of these. I don't think this is really a case where one size fits all and there are arguments for both implementations.

I think if we make the address fields draggable as in the screenshot in #9 that would be a good start for 7.x, and the easiest thing to fix initially.

I will try to get around this within 2 weeks. I will go for the solution that's already in Extra Fields Pane.

This patch adds the following:
- Weight to address fields in uc_store_process_address_field().
- Draggable address fields at the "Address fields" page (/admin/store/settings/countries/fields).
- The variable "uc_address_fields_weight" in which the weights of address fields are stored.
- The function uc_address_field_get_weights() to get the current address field weights setting. I added this function to have one place where the default value for the variable "uc_address_fields_weight" is defined.

Thanks for working on this. I've cleaned up the code a little, renamed the default variable function, and reordered the columns in the table.

I'm tempted to remove the field renaming entirely and force people to use locale/string overrides, but perhaps at rc2 it's too late to do that now.

Are the two undraggable rows even used anywhere now? We should probably check that and remove them if they aren't!

Thanks for the code cleanup.

Are the undraggable rows used?

I'm not sure if the two undraggable rows are used anywhere in Ubercart 7.x-3.x. The field "Street address" ("street") was used in Ubercart 6.x-2.x as the field label for "street1" at checkout (see theme_address_pane() in uc_cart_checkout_pane.inc), but Ubercart 7.x-3.x uses "Street address 1" ("street1") as the field label for "street1" at checkout.

In the function uc_get_field_name() the field labels can be get. Labels can also be get for "street" and "address" which represents the two undraggable rows. To test if they are used I added the following code at the beginning of the function:

switch ($field) {
    case 'street':
    case 'address':
      throw new Exception(t('Field %field is accessed', array('%field' => $field)));
      break;
  }
 

After that I accessed the checkout page and the order edit page. I also executed all automated tests that are available for Ubercart. The exception wasn't thrown and all tests passed except "Attribute API" and "Credit cards", but these may be caused due to a local misconfiguration (In my Drupal setup I had set that all PHP errors must be shown, including notices). Anyway, the exception message wasn't reported on the test result page.

I also searched the Ubercart code for all calls to uc_get_field_name(). None of them asked for 'street' and 'address' literally.

The automated tests may not cover everything, but because the exception wasn't thrown on the pages where I might expect that these field labels are used, we can assume that field labels from the two undraggable rows are not used anywhere in Ubercart core code.

However, they could be used in contrib modules. I have only a few Ubercart contrib modules in my Drupal 7 environment and a lot (but not all) in my Drupal 6 environment. I did a search for uc_get_field_name() in my Drupal 6 environment and the only modules that used the label "street" were Ubercart Checkout Tweaks in theme_address_pane_amazon_style(), Ubercart Addresses 6.x-1.0 and some of my custom made Ubercart extension modules. Ubercart Addresses is now controlled by me and I'm quite sure the Drupal 7 version I will soon start to develop will not need the "street" label.

So, to make a long story short, I'm okay with removing the two undraggable rows. You may remove the two field labels in uc_get_field_name() also.

Remove the field renaming

I'm okay with removing the field renaming. This might solve some of or all the problems reported in #834290: Address fields are no longer multilingual variables and cannot be translated, that's an advantage. A disadvantage of this is that fields can be less easy renamed, as not all Ubercart site administrators may be familiar with string overrides. If we remove the ability to change the labels on the address fields page, maybe we should add a help message to the page that tells to use string overrides if the site owner wants to use other labels? Maybe we should discuss this in a separate issue.

Committed #16. Back to active to sort out the remaining points in #16/17. I think perhaps we can change the default strings for street address 1 and 2 to "Street address" and "" respectively to go back to how things were in 6.x by default, and remove the undraggable rows.

I am not so sure about removing the field renaming right now as I imagine it's already used in several stores, I think that #834290: Address fields are no longer multilingual variables and cannot be translated will have to be fixed a different way, perhaps by implementing translatable support via the variable module and hook_variable.

Patch attached that removes the undraggable rows and cleans things up a little more.

Committed #20.

Sorry that I did not responded to this earlier. I had intentions to review the patch, but I couldn't find the time for it yet. I'll reopen this issue if I notice any issues with the change.

very simple to resolve.. just make some changes in uc_store.module : uc_store_address_field_weights()
change weights according to your requirement. :)

changing the weight in /admin/store/settings/countries/fields works aswell

imagine that a extra field that is created has a weight value of 0

Change the other fields by selecting a value arround zero.