Reuse billing information for shipping profile fields

I've been thinking about such a feature, but instead of using hook_form_alter we should instead create an addressfield plugin that could optionally be added to the shipping form.

I haven't tested this, but I'm guessing that if you enter the billing address in a later/earlier step than the shipping (which could be possible) that this will fail. So we need to consider that as well, if we want to make a generic solution to commerce_shipping.

Patch in #2 works for me, although had to be manually applied to the latest 7.x-1.x-dev code.

subscribing

I looked and tested the patch; the problem with this patch is that it completely ignores validation situations -- here's what I mean zipcode, names, etc.. are all required fields if Use Billing is not checked.. but yet it isnt.

Yeah. Had to get this up and running on a client site. I pretty much just do a listener js to put values of billing address to shipping address on checkbox "use billing" no need to do a submit callback.

Similar functionality is needed for the 2.x version of the module too.

No matter you check or uncheck 'use billing information'

$form['customer_profile_shipping']['commerce_customer_address'][$language][0]['#required'] = FALSE;

is applied to the code which is not correct. This should only apply if the checkbox is checked. Please fix and resubmit the patch.

See my note on #2 for what is required for this patch to make it in.

Can you please explain me how to use addressfield to achieve this?

Sorry bojanz, what do you mean?

UPDATE 1: November 10

There was an error in this code. commerce_shipping_checkout_submit should have been THEME_checkout_submit. I have corrected it below.

Updated original

I used this patch as a starting point for a custom "My billing address is different to my shipping address" feature, which hides the billing address fields until the checkbox is clicked. Here is the (custom) code:

This goes in template.php in your theme. Change "THEME" to your theme's machine name.

/**
 * Implements hook_form_alter().
 *
 * Adds functionality to the checkout form that allows billing information to
 * be reused for shipping.
 *
 * @see http://drupal.org/node/1243846
 */
function THEME_form_commerce_checkout_form_checkout_alter(&$form, &$form_state, $form_id) {
  $path = drupal_get_path('theme', 'THEME');
  $form['customer_profile_billing']['do_not_use_shipping'] = array(
    '#type' => 'checkbox',
    '#title' => t('My billing address is different to my shipping address'),
    '#id' => 'do-not-use-shipping',
    '#weight' => -100,
    '#attached' => array(
      'library' => array(array('system', 'ui.accordion')),
      'js' => array("$path/js/checkout.js"),
      'css' => array(
        "$path/css/jquery.ui.accordion.css",
        "$path/css/commerce_checkout.css",
      ),
    ),
  );

  // Disable the "required" validation.
  $language = $form['customer_profile_billing']['commerce_customer_address']['#language'];
  $form['customer_profile_billing']['commerce_customer_address'][$language][0]['#required'] = FALSE;

  $form['buttons']['continue']['#submit'] = array_merge(array('THEME_checkout_submit'), $form['buttons']['continue']['#submit']);
  $form['#submit'] = array_merge(array('THEME_checkout_submit'), $form['#submit']);
}

/**
 * Submit callback.
 *
 * Inserts the billing information into the shipping field, if the user
 * specified that the billing information should be used.
 */
function THEME_checkout_submit($form, &$form_state) {
  if (!$form_state['values']['customer_profile_billing']['do_not_use_shipping']) {
    $form_state['values']['customer_profile_billing']['commerce_customer_address'] = $form_state['values']['customer_profile_shipping']['commerce_customer_address'];
  }
}

This goes in /js/checkout.js in your theme.

/**
 * When the "My billing address is different" checkbox is clicked, hide and
 * disable all fields in that fieldset. (except the checkbox itself).
 */
Drupal.behaviors.checkoutAddress = {
  attach: function(context, settings) {
    var $checkbox = jQuery('#do-not-use-shipping', context);
    var $siblings = $checkbox.parent().siblings();
    var $inputs = jQuery('.customer_profile_billing input, .customer_profile_billing select', context);

    $checkbox.change(function() {
      if (this.checked) {
        $siblings.slideDown();
        $inputs.removeAttr('disabled');
      }
      else {
        $siblings.slideUp();
        $inputs.attr('disabled', 'disabled');
        $checkbox.removeAttr('disabled');
      }
    });

    $checkbox.change();
  }
};

subscribing

I've had a play with the code in #15... I've put it into module code (where it belongs, rather than theme code). It sort of works, but the country field isn't being handled, so I end up with a shipping profile in Afghanistan ;)

Also:

- the order review page still has a shipping order section (which just says Afghanistan...)
- the shipping profile is created, and is empty (well apart from Afghanistan, but assuming we fix that). That's going to be confusing for store admins. The problem here is that the ticky box for 'addresses are identical' is pure UI -- there is no data actually stored to say this is the case.

As said further up, it's an attempt at a quick cosmetic fix.

I'm not convinced #1276462: Allow a checkout pane to use values from another checkout pane is the right solution either. That's would mean we copy values from the shipping profile into the billing one. If the addresses are the same, why have two profiles at all?

I'm going to call this a bug, and a major one at that. No self-respecting client or end-user is going to tolerate having to enter details twice; no commerce package worth its salt should be producing this kind of UI WTF ;)

But here's a patch :D

I've reused some of the code from #15, but taken a different approach: if the user doesn't select the checkbox to indicate the two addresses are different, then the billing profile is never created.

This works by using hook_commerce_checkout_pane_info_alter() to replace the checkout pane callbacks that commerce_customer module provides:

- when the billing pane is submitted, our replacement submit handler looks at the checkbox value, and only if it's selected is the original commerce_customer submit callback called with the data. That in turn takes care of saving the profile.
- turns out we don't need a JS file; it can be done all with FormAPI states. There's a bit of convolution because of the complex addressfield, hence the need to also explicitly set #required = FALSE on the field as a whole.
- we also replace the pane review callback, as the commerce_customer shows a message for an empty profile, whereas IMO we should show nothing.
- when a store admin edits an order, a blank billing order is shown. I added a @todo note to hide that, although it occurs to me that actually, store admins should be able to *add in* a billing address after the fact if they need to. Hence it could be it's fine as it is. At any rate, it's an admin-side only problem.

Now whether having no billing profile at all has consequences, I don't know. To my mind, it's cleaner not to duplicate data. But will other things that rely on there being a billing profile get flummoxed?

If that is the case, then that's easily remedied: because we have our own submit callback, commerce_shipping_profile_pane_checkout_form_submit(), and because these get the *entire checkout page form* we can quite easily reach into the form state values for the *shipping* profile, and save those into a new *billing* profile.

Hey there!
I totaly agree to this! This patch is a must have and should be imported.. but i get some notices after aplying this!

  * Notice: Undefined index: commerce_shipping in commerce_shipping_pane_checkout_form_validate() (Zeile 112 von /var/www/vhosts/.../commerce_shipping/includes/commerce_shipping.checkout_pane.inc).
    * Notice: Undefined index: commerce_shipping in commerce_shipping_pane_checkout_form_validate() (Zeile 113 von /var/www/vhosts.../commerce_shipping/includes/commerce_shipping.checkout_pane.inc).
    * Notice: Undefined index: shipping_methods in commerce_shipping_pane_checkout_form_validate() (Zeile 120 von /var/www/.../commerce_shipping/includes/commerce_shipping.checkout_pane.inc).
    * Notice: Undefined index: commerce_shipping in commerce_shipping_pane_checkout_form_submit() (Zeile 144 von /var/www/vhosts/.../commerce_shipping/includes/commerce_shipping.checkout_pane.inc).
    * Notice: Undefined index: commerce_shipping in commerce_shipping_pane_checkout_form_submit() (Zeile 145 von /var/www/vhosts/.../commerce_shipping/includes/commerce_shipping.checkout_pane.inc).

@joachim: i appreciate your work. I tested it and all but wonder what would it take to make billing the default

I am selling both downloads and physical products from my site and think a patch that requires billing info by default and makes entering shipping address optional is most suitable for this and general purposes. I mean commerce allows for the selling of digital products but at same time requires a shipping address. I could remove shipping from my checkout pane but then i couldnt ship physical products. Ive sought out Rules to remedy this but dont think the configuration is possible given their parameters.

Yeah, that probably makes sense.

> Now whether having no billing profile at all has consequences, I don't know. To my mind, it's cleaner not to duplicate data. But will other things that rely on there being a billing profile get flummoxed?

From this point of view too -- lots of modules may expect a billing address because that's part of Commerce core. But only Commerce Shipping knows the shipping address exists, for now -- and other modules that come along and make use of it will know once this patch is in that they must check to see if there actually is one. Or we could provide a helper wrapper function that returns whichever of the two profiles should be used for shipping.

However, we should also consider what makes the most sense for the UI.

Like I said in #2, if this is to go in, I want this to be an adressfield plugin, as I don't want to force this on people. Not everyone are using billing and shipping address, it's an optional feature.

It would also need to be able to handle shipping and billing address not being on the same checkout page, as that could be the case.

> I want this to be an adressfield plugin

Could you explain more about how you envisage this working?
What do you mean by a plugin - does addressfield have those?
Would the altered addressfield then know to go and slurp up the data from the billing profile and enter it into the hidden fields on the shipping profile?

> I don't want to force this on people. Not everyone are using billing and shipping address, it's an optional feature.

I don't understand what you mean by this.
Surely a shipping address is an essential component of the shipping module? I've certainly not seen how it's optional, apart from disabling the Shipping Profile pane. Would the shipping module even work in that case? What address would it use?

> It would also need to be able to handle shipping and billing address not being on the same checkout page, as that could be the case.

That would work if I put the 'addresses match' checkbox on the shipping profile pane as suggested in #20. The form submit handler I added in my patch doesn't need to know anything about the billing profile, it just obeys the checkbox and skips saving the profile entirely.

You obviously know this module better than me ;) -- does not having a shipping profile at all cause problems with other parts of the module?

Could you explain more about how you envisage this working?
What do you mean by a plugin - does addressfield have those?
Would the altered addressfield then know to go and slurp up the data from the billing profile and enter it into the hidden fields on the shipping profile?

The addressfield works internally by using ctools style plugins to create the addressfield form. That is why it is possible to select name as single input vs first and last name.

I don't understand what you mean by this.
Surely a shipping address is an essential component of the shipping module? I've certainly not seen how it's optional, apart from disabling the Shipping Profile pane. Would the shipping module even work in that case? What address would it use?

A shipping address or shipping profile is not strictly needed to make this module work. Shipping methods might depend on the address if the fees depends on the shipping location.

You obviously know this module better than me ;) -- does not having a shipping profile at all cause problems with other parts of the module?

With or without it functions the same, it's a sensible default to create such a profile, but isn't used anywhere in code.

This is for 1.x branch, the 2.x branch that Ryan has been working on might be very different.

> The addressfield works internally by using ctools style plugins to create the addressfield form. That is why it is possible to select name as single input vs first and last name.

Right, I get you now.
But that means that you'd be saving two customer profiles, which just happen to have identical addresses. I don't think that's the best way to handle data, either for the store admin or for the customer returning to their order.

> A shipping address or shipping profile is not strictly needed to make this module work. Shipping methods might depend on the address if the fees depends on the shipping location.

Surely you need an address for the stuff to *go* to? I still don't follow.
And if the intention is that a store can say that products are shipping to the billing address, then not giving the customer the opportunity to ship to a different address seems rather short-sited to me. People will always need that option, because credit cards need the billing address to match the bank's details, and people may want things shipped to a relative, to friend, a holiday home, etc. A store going with that configuration would be shooting themselves in the foot.

Anyway, here's an updated version of my patch with the change suggested in #20. It's now the shipping pane that has the checkbox and can opt to save nothing, hence customers always get a billing profile and only a shipping profile if the address is different. This should work fine if the two panes are on different checkout pages, as the form submit handler doesn't look at the billing address pane at all.

I don't like to repeat myself.

I still stand by #2 unless you can convince me of a better solution.

I've applied the patch in #18 but it hasn't worked straight out of the box. Am I missing a configuration option somewhere?

@splatio are you using 7.x-1.x-dev? it should.
@joachim the new configuration looks better and seems to make better sense. i am testing it now

I have applied the patch in #18 but I get the following strange behavior when I change the countries of the billing or shipping address:

Scenario 1
I load the checkout page
I check "My shipping address is different to my billing address"
Now all field are marked as required.
I change the country of the shipping address to something else.
Now no fields of the shipping information are required.
I uncheck "My shipping address is different to my billing address" and check it again.
Now I have two *s (to indicate they are required) next to all fields.

Scenario 2
I load the checkout page
I change the country of the billing address.
I check "My shipping address is different to my billing address".
Now I have three *s next to all fields.

If I change the country multiple times, the number of *s keeps increasing.

Hi, For now I used the patch in #25, which is working also on 2.dev!
Greetings, Martijn

I have updated comment #15 and the code in it with a correction that I believe addresses all or most of the issues raised in #17 and #19.

Is it possible to post Joachims (#25) patch as code as I cannot use git on my server?
Many thanks

The patch in #25 work for me, apart from one issue. When you tick the checkbox all of the shipping fields are required. Normally Address 2 is an optional field, so it doesn't make sense to have it optional in billing but required in shipping.

Is there any way to replicate the required states from billing rather than just setting everything to required?

I tried the patch #25 in 2.x branch and seems to be working (applied the patch by hand). I improved it a bit since there were couple of things which needs to be taken into account.

Shipping address pane should be able to be moved across the checkout pages
This was a major thing because checkout process is customizable so we need to handle that too. I did that by using hook_form_alter() instead hook_form_FORM_ID_alter() and react on all form ids which starts with "commerce_checkout_form_".

The checkbox doesn't have any default value handling
So, on submission I save the checkbox value into $order->data['shipping_different']. That way if user decide to come back to shipping address pane, the default value will be taken from that property.

What to do with orders with same address?
That is still open question. At least, it should clear the profile reference in case if user has first typed in the address and then modify and unchecked the different shipping checkbox.

I'm interested in 2.x branch, so this patch is written that in mind :)

Here are some things I noticed about patch #34:

1) It seems to me that a lot of site admins actually will want to save a shipping profile even if the customer specifies that their shipping will be the same as billing. This approach seems more consistent as a storage and retrieval method, that is, shipping will always be shipping and billing will always be billing. So if we go with a server side approach like this, I think we will want to copy billing values to shipping when saving either profile.
2) Setting "required" in the #states of a form element doesn't affect validation on the server, but rather it just prints the required marker (see http://api.drupal.org/api/drupal/includes--common.inc/function/drupal_pr...). There needs to be a validate handler to determine what is actually required.

I wrote an alternate patch that takes more of a client side approach and doesn't rely on callback overrides. All it does is copy the billing address fields into the shipping address form from either a saved billing profile or billing address values in the form state.

Honestly I'm not sure whether the client-side or server-side approach is better - both have pros and cons.

I needed to do this for a pet project, so decided to implement this in a generic fashion since this has been a popular issue.

Anyways I have created an addressfield plugin, so that it will be optional to use this feature or not.
Current it's JavaScript dependent.
You will need to enable to addressfield plugin for both the billing address and the target address (could be made into a different address than shipping, but current it only works for shipping address)
Also both addresses will need to be on the same form for this to work.

This is not the perfect solution I would like, but it's optional, based on addressfield plugins and covers most use cases, which makes it good enough for now.

Committed to both 1.x and 2.x

Works like a charm after updating to latest 2.x-dev and applying the patch in #1387074: Wrong parameter names in hook_ctools_plugin_directory. Thanks googletorp for the nice work.

Thank you, googletorp, I needed exactly this functionality (using 2.x dev branch 2011-Dec-28)

The is one thing (I think) that might improve this feature even more:

1. I use checkbox 'Use billing address as shipping address', enter the billing values
2. I go to the next page (Review order in my case)
3. Now, when I hit back button, the checkbox 'Use billing address as shipping address' is UNchecked and both addresses are filled with the same data.

Is it possible to make some kind of detection and leave checkbox checked (if the addresses are the same)?
Thank you.

#38 You can make as a new feature request (a new issue). Not sure I would want that behavior though.

Thanks googletorp it works well in the frontend, but, doesn't seem to work for logged in admins, has anyone managed to get that working?


Also I am thinking that it is preferable to have it checked by default which would keep the page nice and clean visually, then when the user clicks to go to the next step it populates, or if they need to add a shipping address they untick it to reveal the shipping address form....hmm need to think that through... ;-)

I agree that shipping address are in most cases same as billing address.

That is why it should be checked by default.

Hi,
I like #25 more than #35
With #25 you only have to do something if the shipping address is different.
With #35 you have to tell the system the shipping address is equal, which is counter intuitive in my perspective.

greetings,
Martijn

Regarding #36 where you say:

You will need to enable to addressfield plugin for both the billing address and the target address (could be made into a different address than shipping, but current it only works for shipping address)

I can't figure out how to do this. I have looked in all the places I can think of but I see no option to enable the addressfield plugin. Can you share some specifics on how that is accomplished?

I am using the 7.x-2.x-dev version of the module (downloaded using drush)

Thanks!

I, too, am confused as to where this functionality resides. I'm using 7.x-2.x-dev. I have the module enabled as well as having enabled the Shipping UI. Is it necessary to create a shipping method or service in the UI first? The shipping information form is in the checkout page as I would expect but I don't see any checkbox or other method for the shipping address to be the same as the billing address. It is manual entry only.

The address form is defined by the addressfield which has a plugin system. This is where (field settings) you need to enable the feature.

Success. Thank you, googletorp.

For people who are a little lost like me, this is where you will find the settings:

• store/customer-profiles/types/billing
• store/customer-profiles/types/shipping

Halfway down the page, under Format Handlers, you'll see a checkbox with the following text:
"Copy billing address (required to be activated on billing profile along with the profile you want to copy the address on to. In order to work properly, the two addresses need to be on the same page.)."

Check this on for both the billing and shipping profile types. Save both. I'd imagine you also need to make sure the other format handlers are identical between the two profile types--though I haven't tested it.

Spawned a child issue to change this for 2.x, as my preferred approach would be to make use of #ajax and not be dependent on client-side JS only. See: #1410022: Improve copy address functionality - create a more generic solution

Hey there!

Great work guys! Works like a charm but i cant figure out how to hide also the fieldset.. Is this possible?

greetings!

Did you ever figure out how to enable this by default and hide the shipping pane initially?

Thx dpolant - #35 gets my vote as it works with our custom shipping pricing module and makes sense logically - storing 2 addresses. tried another version re showing billing only with checkbox for showing del address but it didnt work with our module and also made address 2 required which is bad UX/unecessary.

Will be good to get this rolled into the shipping module by default!

It is great that this option now exists, thanks for making it. It would be even better if:

1. The checkbox wasn't located at the very bottom, *after* the two form fields. The customers may think they need to fill out both forms and get annoyed, before seeing the 'Use billing address as shipping address' checkbox, and get more annoyed.
2. If the 'Use billing address as shipping address' was selected by default, and only after unchecking it would the 'Shipping information' form be shown.

EDIT: Actually, there is an easy fix for #1, which would be to put the 'Billing information' form before the 'Shipping information', which you can do from this page: admin/commerce/config/checkout

Path for the two settings

• admin/commerce/customer-profiles/types/billing/fields/commerce_customer_address
• admin/commerce/customer-profiles/types/shipping/fields/commerce_customer_address

Hi Thanks for building this and #46 and #52 for how to handle this!
Greetings, Martijn

You might evaluate #1410022: Improve copy address functionality - create a more generic solution as a core Drupal Commerce replacement for this functionality.

You have to distinguish between Commerce 7.x-1.x-dev and Commerce Shipping 7.x-2.x-dev. The functionality has been removed from Commerce Shipping 7.x-2.x-dev (the branch you should be using) and added into Drupal Commerce itself in the 7.x-1.x-dev version (which you should be able to use with no problems until we package a 1.4 release).

Just update and run update.php. I don't even think we've had any database updates since the 1.3 release, and I'll get a 1.4 out here shortly.

I want to use this option "reuse billing information" too, but when updating my current commerce module to 7.x-1.x-dev with Drush I get a "specified version not found" error?
Can you update the commerce module when you used commerce kickstart? I used the command "drush pm-update commerc-7.x-1.x-dev", but with no success so far...

I know how to do it manually, but you should be able to do it with drush, no?

I would agree with sandravdv, why wouldn't this be available in the development release of the module itself? Maybe we're missing something?

DW

So… 1.4 still not out, jumping into using the dev version, as that functionality is important. Wish me luck.

Hey Ryan,

Were you able to look into adding this to a 1.4 version?

Thanks!

It's already going to be in 1.4 when that is tagged. In the meantime, you can use Drupal Commerce 1.x-dev with no issues, but some of the features may be subject to change - i.e. we're going to add the option to default the checkbox to copy addresses to be checked.

> In the meantime, you can use Drupal Commerce 1.x-dev with no issues

... apart from project managers and clients being iffy about such a mission-critical module running off a dev release :/

Please release a 1.4 :)

Yep, it'll come as soon as it's ready. Hopefully by last Friday.

I just noticed the checkbox in the pane configuration: admin/commerce/config/checkout/form/pane/customer_profile_billing

I hadn't noticed this yet either.

Thanks for the pointer!

I find this whole thread extremely confusing. The best way IMHO is the patch for the commerce core module. The patches in here are a good start, but commerce core handles it much like #34 but with the 'data preserving idea' of #35.

So best bet is to use: http://drupal.org/node/1410022#comment-6008792. As this has been added to commerce core, it should IMHO be removed from the commerce shipping module.

It's been removed from this module already, just check the timestamps on the previous comments. The thread was only recently necro'd to point out where the setting is in core. : )

Can it be locked maybe then? Now it should really be clear :-p

Unfortunately, no. I've posted such a feature request to the webmasters queue, but right now on d.o there's no way to lock anything. Makes it hard to be a maintainer, too. : P