Billing same as shipping

I won't have time to work on this in the next 3 weeks.

I think a bigger priority is to allow profile reuse in the first place (#2844920: Allow customer profiles to be reused), especially since shipping and billing now use the same profile type.

I just realized we got this backwards.
Shipping information goes before payment information (in our checkout flow, most sites, checkout UX guidelines). That means that the customer will first enter the shipping address, and actually needs a way to mark the billing information the same as shipping information.

Hi @Bojanz,

According to your above comment, We need to rearrange the checkout pane.

1. Contact information
2. Shipping information
3. Billing information

Correct me if I am wrong.

Shipping information already comes first, if you're using the Shipping checkout flow that the module ships with, and have a recent Commerce -dev.

Not sure what you mean "most sites, checkout UX guidelines", however from my great experience as a shopper, most e-commerce sites offer billing address first and after that - Shiping same as Billing option. And this is logic as all Payments (cards) are linked to Billing address, while Shipping could be to more than one locations/address.

You can look at https://conversionxl.com/how-to-design-an-ecommerce-checkout-flow-that-c... under "Asking For Credit Card Info Last"

Payment method is the last - that's true, however that doesn't mean Billing should follow the Shipping Address (see image attached).
The article describes some ways to optimize the flow, but this is not most common used and this is the opinion of the author.

Payment method and billing address are always together. You can see my explanation in https://www.drupal.org/node/2856965#comment-11966129
I won't be discussing this topic anymore. I've described how this needs to work.

Hi Bojanz .. Any timeframe to get this started? I'm not familiar enough to help with coding but can do testing.

No plans to work on it before May, unless a client requires it. I need to focus on a Commerce RC1.

EDIT: A few notes on implementation: The checkbox needs to result in the shipping profile ID being set as the billing profile ID. Same profile, not the same data in two profiles. Guessing this would be best implemented as a #process callback added to the commerce_profile_select form element. I still think this is only safe to do once the profile reuse has been implemented.

I've started working on this, and spent a while trying to figure out how to properly handle the submission handler so that it sets the profile in such a way that the billing pane's submission handler picks up the shipping profile instead of the billing profile. But so far the submit handler doesn't function properly, and you end up with the billing profile fields still being used.

Just in case this helps anyone else working on this feature, in case I don't get back to it before then, here's my progress so far (entirety can simply be pasted into commerce_shipping.module to test):

Edit: Removed my code from here so I don't clog up the comments. I'll post and hide a patch with my progress.

Attached my progress on this so far in case anyone else wants to use it as a basis for finishing it up before I get back to it.

While figuring this out, I was thinking that it would be simpler to handle this functionality at the commerce_profile_select element level than it would be using alter hooks and extra submit handlers.

What if we add in a couple of extra options that can be provided to the commerce_profile_select element such as #reuse_profile_callback and #reuse_profile_label which, if specified, output a checkbox with that label, handles the JS hiding/showing using #states, handles the differences in validation required of the other fields depending on whether that's checked or not, and then in the submit handler asks the callback function to provide the reusable profile if it's checked?

All of that logic seems pretty generic, and someone might actually want to go the other way around and reuse the billing profile for shipping. If we made it generic functionality on the profile select element, then either use case would be simple to support, though the default use case could be in place already without any additional effort.

I think we can't use #states to show and hide the form items since they have HTML form validation. It prevents submitting the form currently. Do we need to remove the form elements and add them via ajax (not my preferred solution)? Otherwise we would need to remove and add the HTML form validation attributes using JS...

Isn't making the fields not required on the front-end what the 'required' state in #states is for? I thought the only thing that would leave then is having to override the server-side validation.

Using AJAX would be fine I suppose, though not as snappy as far as the UX, probably much easier for figuring out the validation issues. Perhaps it could be solved in the same way the profile select patch is doing it? Not positive offhand how that is done, but that either shows or hides the profile fields depending on if you've selected the option to create a new profile or not.

I would totally prefer a non-ajax solution. Having a server roundtrip will cause bad UX for sure.

I am not familiar enough form validation and #states. It would be perfect if this could be done with #states.

Since i needed a quick solution for my current project, i added a JS file that simply copies the form values resulting in duplicate profiles. It has one bug not properly handling changing countries. But for now thats fine for me.

I've got most of this functionality created generically in the commerce_profile_select element here: https://github.com/drupalcommerce/commerce/pull/714

Can be applied as patch here: https://github.com/drupalcommerce/commerce/pull/714.patch

Also instructions in that PR for how I'm testing this functionality (since it does nothing unless you pass options into the element).

Additionally, if anyone's in the same boat as me and also using the profile select enhancements from here: https://www.drupal.org/node/2844920

Then I've created a separate PR that combines both functionality, since there are a number of changes needed to support both:
https://github.com/drupalcommerce/commerce/pull/715
https://github.com/drupalcommerce/commerce/pull/715.patch

This functionality still needs further discussion and review. It works for me, but isn't exactly in line with how it worked in 1.x. Additionally, a separate patch is needed for actually creating options in commerce_shipping to configure this functionality within the pane.

One shortcoming I'm aware of at the moment, is I'm pretty sure if you check the box and go to the Review page and then go back to the previous page again, unchecking the box would likely show you two edit forms for the same profile. We need a way to revert back to the original profile if the form has already been saved with that box checked and the profile overridden (or perhaps a different way to apply the reused profile instead of overwriting the #profile element in the pane form).

Also commerce_shipping currently assigns the shipping profile to anonymous as a temporary measure, and it's very likely that will screw with this functionality.

I have a patch here that reverses that change so that the shipping profile is owned by the user again: https://www.drupal.org/files/issues/commerce_shipping-Reverse_temporary_...

However if you aren't using the #715 version that include the other profile select enhancements, reversing that change might cause other issues. I just wanted to point that out because I just realized it could be a reason why it works properly for me.

And finally, if using #714 or #715, here's an additional PR which adds options to the Billing Information / Payment Information panes to control the checkbox:

https://github.com/drupalcommerce/commerce/pull/716
https://github.com/drupalcommerce/commerce/pull/716.patch

Using those patches doesn't toggle the visibility of the billing profile:

https://github.com/drupalcommerce/commerce/pull/715.patch
https://github.com/drupalcommerce/commerce/pull/716.patch

The ajax callback works, but doesn't change the form.

Hmm,

I'm using those two patches and the profile is being shown/hidden appropriately. Trying to determine what might be different in my setup. If I figure it out I'll update the PR.

It should be this code which hides the profile fields:

    if ($reuse_profile) {
      foreach (Element::children($element) as $key) {
        if (!in_array($key, ['reuse_profile'])) {
          $element[$key]['#access'] = FALSE;
        }
      }
    }

If that code isn't running when the button is checked, that must mean that $storage['pane_' . $pane_id]['reuse_profile'] isn't set properly, which in turn seems to mean the reuseProfileValidate method either is not running, is not able to determine whether the checkbox is checked, or is not updating the form state properly.

I'm currently not able to reproduce the problem you're experiencing on my site no matter what I try, so I'm still trying to figure out what might be different on my end making it work so perfectly.

@lukas-von-blarer Out of curiosity do you have the same problem trying to use #714 instead of #715? 714 is much simpler, but doesn't include the select field for selecting from existing profiles, so I'm curious if that's related at all.

716 just adds the configuration options to enable/disable the functionality, so likely whatever the issue is here resides in the other patch.

@bmcclure i did test that quickly without success. in about an hour i can look into it closer.

So now testing #714 and #716 revealed that this always returns false:

$reuse_profile = (isset($storage['pane_' . $element['#name']]['reuse_profile']))
      ? $storage['pane_' . $element['#name']]['reuse_profile']
      : $element['#reuse_profile_default'];

$element['#name'] has this value: pane_shipping_information[shipping_profile]

$storage has only those indexes: $storage['shipping_profile'], $storage['field_storage']

Here is a screenshot of my checkout setup:

Ok cool, this helps. I think I know what needs to happen, that pane's form storage array is only getting set in certain cases (which just happen to always be true for me apparently). I'll update my patch shortly to resolve that. Thanks for the report!

So the issues i was facing were caused by a missing shipping method. The patches of #714 and #716 work perfectly for me! What is missing here? Tests?

@lukas Thanks for confirming, that's a relief!

As far as what's missing, this basically encompasses my proposed solution, but doesn't take into account the way this functionality worked in Commerce 1.x. So I think things that are needed:

1. One or more reviews about the details of the approach
2. Consensus on the naming of the options on both of the affected elements (payment gateway form and commerce profile select), as well as the options in the pane UI
3. Comparison of any missing functionality from 1.x and how to incorporate here
4. Adding the same options to the shipping pane to allow people to reuse the billing information the other way around if they want (should be very easy to do, just needs a patch for commerce_shipping whereas my patches were for commerce).
5. Tests, I'm guessing

@bmcclure : Do we need to add the #17 patch also ? because i applied #715 and #716 but i cannot see the checkbox in UI

Please Advice

@chishah92: It should work with just a combination of either 714 or 715, plus 716.

I was experiencing an issue I thought was related to this patch, turned out to be totally unrelated. This is still working well for me.

I debugged the code i am getting $reuse_enabled as false in line 192 , that's why the thing is not working.

Applied #714 and #716, it is working fine for me, i think we can take to needs review.

Here is a current snapshot of all 3 PRs as patches.

You need to use two out of the 3 patches for this to work. Use one of the "part_1" patches, depending on if you want profile select functionality included with this or not. Then use the "part_2" patch to add the ability to enable and control this through the billing pane UI.

The PRs will still be the most up-to-date, but wanted to give people here an easy way to test and provide feedback if they're used to patches in the issue queue.

This doesn't have tests, or very good documentation at this point (just a few comments).

I've updated pr 715 to resolve a couple of issues I was having with the other functionality that this issue is not specifically about (the profile select field). In case anyone is using 715 instead of 714 to get that functionality, just wanted to point out that the patch I just posted is slightly outdated in that regard. The "billing same as shipping" checkbox functionality is still the same either way.

Also, this is open for further discussion, but this issue is now very muddied (sorry about that) and is probably not even in the right project anymore if we're going with my approach.

I'll leave it as it for now so others can review first, but here's what I would suggest:

1. Combine the #reuse_profile options that this approach adds to the Profile Select field along with the other Profile Select patch that's out there already (https://www.drupal.org/node/2844920). It's impossible to use my PR #714 along with that patch, and both features directly make the Profile Select feature more robust and reusable, so rather than maintain separate conflicting patches, that functionality could all be there. That would essentially eliminate PR 714, and would replace the existing PR in issue 2844920 with my PR 715 (which contains all of the previous code from czigor's patch, all of the code from my 714 patch, plus some integration fixes)
2. Move this issue to the Commerce queue, because with my approach, the code changes are handled in the billing and payment panes, not in the shipping pane (though the callback which retrieves the current shipping profile might not belong where it is now). Also we could use this issue then only for my PR 716 patch
3. Create a new issue in the commerce_shipping queue for creating a patch similar to #716 but which adds options to reuse the billing profile for shipping, for people who want it to work the other way around.

Does this make sense?

Anyone using my PR 715 patch, note that there are a couple of logic issues I introduced into the code recently causing strange behavior in certain circumstances, like anonymous users viewing their profile when returning to the order page, instead of editing it.

I've been working for most of the day on revamping the profile select functionality together with the profile reuse functionality so that it all works better and more consistently. There's going to be a pretty big commit to PR 715 later today that should hopefully resolve all of the issues.

Note that the reuse checkbox related to this particular issue is still working fine either way, the only issue is with the slightly-unrelated other changes in 715 which add the select box for selecting existing profiles. I think the approach for the checkbox is still ready for review, and #714 and 716 together will give you a more pure test of this functionality.

I've updated PR 715. The profile reuse code works just about the same as before, but the code for selecting from existing profiles has been substantially revamped to resolve several issues. Also, PR 715 works with the latest updates to the commerce 2.x dev branch that change the ProfileSelect element to extend RenderElement.

Give it a try and let me know if this checkbox functionality still works properly for you with 715 and 716. I've also posted in the related profile select issue about my updates to 715 to get feedback about that portion of it (https://www.drupal.org/node/2844920#comment-12052172).

https://github.com/drupalcommerce/commerce/pull/715

For testing I moved the payment pane to the next step of the shipping pane. On the next page the “Same billing address” feature is broken. This is the error I get:

TypeError: Argument 1 passed to Drupal\commerce_payment\Entity\PaymentMethod::setBillingProfile() must implement interface Drupal\profile\Entity\ProfileInterface, null given, called in /web/modules/contrib/commerce/modules/payment/src/PluginForm/PaymentMethodAddForm.php on line 112 in Drupal\commerce_payment\Entity\PaymentMethod->setBillingProfile() (line 152 of modules/contrib/commerce/modules/payment/src/Entity/PaymentMethod.php).

I am using #714 and #716.

Currently #714 doesn't apply anymore, #715 still does.

Thanks for the reports!

I'll get #714 updated so it applies on the latest commerce dev. As you noted, #715 is already updated to work (and has received a lot of other modifications from me over the past several days), so I just need to pull over a few of the changes to the 714 PR.

In addition, I think I know how to get this working with the profiles in different checkout steps--I'll test this out ASAP and fix the issue in both PRs.

PR 714 is updated. Here's a patch in case anyone has an issue applying that from GitHub. PR 715 is also updated if anyone is using the combined version. Adding that patch as well. Choose one or the other.

I'll update 716 to resolve the other issue lukas found and post a patch for that once it's done as well. Until I post the new version of that, you still need the existing 716 patch as well.

Please note, these patches are both for commerce, not commerce_shipping, so tests here will definitely fail, and you should make sure to apply them to the right project.

Here's a new one to try to replace the previous PR 716 patch here. I've updated the PR as well, but wanted to get an updated patch here too.

I hope this resolves the issue lukas found with shipping and billing being on different steps. I don't use that setup but this seems really straight forward, so feedback is appreciated.

You'll need one of the two patches from the previous comment, plus this patch.

#714 and #716 work perfectly for me! You fixed the issue I discribed in #39! Thank you!

I'm getting some notices during checkout:

Notice: Undefined index: #name in Drupal\commerce_order\Element\ProfileSelect::processForm() (line 108 of modules/contrib/commerce/modules/order/src/Element/ProfileSelect.php).
Notice: Undefined index: #name in Drupal\commerce_order\Element\ProfileSelect::processForm() (line 111 of modules/contrib/commerce/modules/order/src/Element/ProfileSelect.php).
Notice: Undefined index: #name in Drupal\commerce_order\Element\ProfileSelect::validateForm() (line 170 of modules/contrib/commerce/modules/order/src/Element/ProfileSelect.php).
Notice: Undefined index: #name in Drupal\commerce_order\Element\ProfileSelect::submitForm() (line 188 of modules/contrib/commerce/modules/order/src/Element/ProfileSelect.php).
Notice: Undefined index: #name in Drupal\commerce_order\Element\ProfileSelect::processForm() (line 108 of modules/contrib/commerce/modules/order/src/Element/ProfileSelect.php).
Notice: Undefined index: #name in Drupal\commerce_order\Element\ProfileSelect::processForm() (line 111 of modules/contrib/commerce/modules/order/src/Element/ProfileSelect.php).

Using #715 instead of 714 fixes the issue.

Thanks for the report! I know what the issue is. ProfileSelect was recently changed to a RenderElement instead of a FormElement, so it no longer has a #name in all cases by default. In #715 I'm manually assigning a name if it doesn't exist, so I will try the same thing for 714.

714 PR has been updated to fix that issue, I believe: https://patch-diff.githubusercontent.com/raw/drupalcommerce/commerce/pul...

(Didn't update the patch in this issue yet, make sure to use that link for now)

hi bmcclure

Thx for the patches. I tested the latest 714 and 716 together with the latest commerce and commerce_shipping module.

The patch basicalliy works, but there is one annoying bug. Because I use the commerce_shipping module, I have multiple Checkout Flows. I configured on my Order Item to use the second checkout flow called "Shipping".

Unfortunatly, the option about reusing the shipping address is always taken from the first checkout flow, no matter what you configured on the second checkout workflow. You can easily reproduce this by installing the commerce_shipping module which will generate an additional checkout flow.

@ayalon:

I'm using two different checkout flows, and have unique settings in each one and I believe it's working well for me.

I think a problem such as you describe would likely come from somewhere else in commerce, since the pane configuration is handled the same here as configuration in other panes.

However if there is something wrong with the patch causing this that I've missed, I'd definitely be willing to fix it!

Do you have the checkbox settings on the first or on the second checkout flow? I tested this quite intensive and added breakpoints to see, where the data is coming from. And I'm pretty sure, that it takes the configuration from the first checkout flow.

I just tried translating the text of the checkbox ("My shipping address is the same as my billing address.") but I couldn't find it in the User inteface translation like other sting in the checkout flow.

@ayalon: This would seem to indicate some issue elsewhere I think, a checkout pane itself shouldn't be concerned with where its configuration comes from, it's getting passed in from somewhere else and is simply using $this->configuration to access it.

What needs to be done to make the pane configuration translatable, does it need a schema, or something else?

I am getting the following error on an anonymous checkout:
Notice: Undefined index: #name in Drupal\commerce_order\Element\ProfileSelect::processForm() (line 108 of modules\contrib\commerce\modules\order\src\Element\ProfileSelect.php).

I'm using the commerce dev with commerce-pr_714-42.patch

Which version of commerce are you using? And are you using any other patches?

I believe a change turning the Profile Select element from a form element into a render element also made it not get assigned a #name property by default, so I think one needs to be assigned manually in the code.

I believe I fixed that in my other PR related to this issue, but it should probably be resolved in this one too I suppose. Good catch!

I'm on latest dev with only patch: commerce-pr_714-42.patch

I could not apply commerce-pr_716-43.patch. I suppose this requires other modification that I may not have a use for at this time.

The patch in #43 doesn't apply on RC1

Subscribe

I updated the patch for commerce RC1.

@ayalon
The patch does not work for me. I applied the same setting as in the screenshots posted above but I have no check box in the purchase tunel to say that the shipping address is the same as the billing address.

@zenimagine please use the "follow" button as described here: https://www.drupal.org/node/1306444

The patch applies, but I have the same issue as described in #59

@ayalon is the RC1 patch in #58 standalone, or does it still require one of the earlier patches as well?
#58 applies fine and provides the new options in the configuration, but nothing changes in the actual checkout flow for me.

You are right, I forgot to mention that. You have to use 2 patches:
1. https://www.drupal.org/files/issues/checkbox-same-as-billing-2852207.patch
2. https://patch-diff.githubusercontent.com/raw/drupalcommerce/commerce/pul...

The old patch still applies (714)

composer:

            "drupal/commerce": {
                "Same address for billing": "https://patch-diff.githubusercontent.com/raw/drupalcommerce/commerce/pull/714.diff",
                "Checkbox same address https://www.drupal.org/node/2852207": "https://www.drupal.org/files/issues/checkbox-same-as-billing-2852207.patch"
            },

can you try that?

Great, it works perfectly now. Thank you!

How can we make the "Reuse shipping profile label" translatable?

At #62
The Patch works great. Thank you ;-)

To Bojanz:
So you have a little less work with it.
In the zip are the full patched Files for the next dev...

Greetings from Hamburg-Germany

I suggest to rename the default address as "Registered Address".
During Check-out we may have to select:
- Shipping same as Registered;
- Billing same as Registered;

That will avoid confusions as the account could contain multiple Shipping addresses, while the Billing is mostly the same.

Thanks @ransomweaver.

The checkbox-same-as-billing-2852207-69.patch works for me. I also ran testings for ProfileSelect, it looks great. Perhaps, we should need more others' feedback and the feature should be covered with testing.

The patch in #69 doesn't apply on official release

I have an input on the wording of the checkbox:

My shipping address is the same as my billing address.

In my opinion it should be the other way around:

My billing address is the same as my shipping address.

Thanks @ransomweaver
Patch work fine with drupal 8.4, commerce 8.x-2.0 and commerce shipping 8.x-2.0-beta4 .

my patch in composer.json:

        "patches": {
            "drupal/commerce": {
              "reverse profileSelect change to allow PR 760": "https://www.drupal.org/files/issues/2844920-reverse-profileSelect-temp-fix.patch",
              "reuse profiles": "https://patch-diff.githubusercontent.com/raw/drupalcommerce/commerce/pull/760.diff",
              "reuse profiles enhanced": "https://github.com/fliegen/commerce/commit/57c11175d279fe55db9454b4274608195211aeb8.diff",
              "checkbox same as billing": "https://www.drupal.org/files/issues/checkbox-same-as-billing-2852207-69.patch"
            },
            "drupal/commerce_shipping": {
              "profile select enhancement": "https://github.com/fliegen/commerce_shipping/commit/797b5ef351851d60b2cb6c1a55837501c2a036a5.diff",
              "profile in shipping method widget fix": "https://www.drupal.org/files/issues/profile-reuse-enhanced-2908683-1.patch",
              "auto-recalculate shipping": "https://www.drupal.org/files/issues/commerce_shipping-autorecalculate-2849756-35.patch"
            }
        }

i can't get this patch to work with drupal 8.4, commerce 8.x-2.0 and commerce shipping 8.x-2.0-beta4 ... hunks failed.

@ransomweaver ... actually i did a wget into commerce root and -p1

so i probably did some bonehead thing like wrong directory or whatever. all i know is shipping without this feature is not user friendly at all. so it will be great to know where i went wrong. thanks

@ransomweaver ... i am using composer and have added the patches there like #74 ... then i am supposed to run composer update, right? but there are no changes to the checkout form. or is that the wrong composer command to apply the patches in composer.json file? many thanks for any tips how to get the patch to apply.

I found this too. Could

I found this too.

Could it be that it is also necessary to be running the dev versions of commerce and commerce shipping?

You might be needing to do this first:
composer require "cweagans/composer-patches:~1.0"

@ransomweaver I'm having issues applying these patches to Commerce 2.2. All three patches you mention fail to apply. It looks like some functionality already made it into Commerce 2.2?

Some more testing results. Using Drupal 8.4.4 Commerce 2.2 Commerce Shipping 8.x-2.0-beta4. Also had to apply the patch at https://www.drupal.org/project/commerce_shipping/issues/2927898 to Commerce Shipping (may not be necessary with Comm Shipping Dev?).

Firstly, re 85/86 - the patches applied successfully after I added them to composer.json/extras/patches, as shown in #74. (I eyeballed the related files in Commerce 2.2 and can affirm that the patches haven't yet been rolled in there.)

Permutations:
I tested with a few combinations of settings for my Checkout Flow -> Shipping, just to double check that shipping auto-calculate was not interfering with profile copying. Also did some back and forth movements like a customer might.

1)
Shipping:
Hide shipping costs...: No
Payment information:
Reuse shipping profile by default: Yes

2)
Shipping:
Hide shipping costs...: Yes
Payment information:
Reuse shipping profile by default: Yes

3)
Shipping:
Hide shipping costs...: No
Payment information:
Reuse shipping profile by default: No -> then checked "billing same as shipping"

4)
Shipping:
Hide shipping costs...: Yes
Payment information:
Reuse shipping profile by default: No -> then checked "billing same as shipping"

5)
Shipping:
Hide shipping costs...: Yes
Payment information:
Reuse shipping profile by default: No -> then did NOT check "billing same as shipping"

6) Allow reuse of shipping profile: No

All of these combinations worked as expected. I ran most of them right through a Stripe test configuration and payments went through successfully. (Though email addresses don't get sent to stripe with orders, possibly a regression from Commerce Stripe 7...)

The only problem I noted arose when you EDIT SHIPPING address (from checkout review page), the way a customer would if they realize they made an error in their entry. The Payment address does NOT update with the edited shipping address, resulting in address mis-match on the order. Both profiles (i.e. the pre-edited address and the post-edited address) continue to exist in People > Profiles.

Overall very promising though. Thanks to all who have worked on this (what seems to me) crucial capability.

I have used composer install command, i have done cweagans/composer-patches:~1.0, i have #74 patches in composer,json, i have cleared caches numerous times, all modules are the correct version ... still i do not see this option available

Payment information:
Reuse shipping profile by default: No -> then checked "billing same as shipping"

payment information pane has no gear i can click to configure anything.

what can be wrong? many thanks kevin

@drupalstrap #88 try this in your composer file :

"patches" : {
            "drupal/profile" : {
                "Display profiles in a profile options widget": "https://www.drupal.org/files/issues/display_profiles_in_a-2652170-9.patch"
            },
            "drupal/commerce": {
                "reverse profileSelect change to allow PR 760": "https://www.drupal.org/files/issues/2844920-reverse-profileSelect-temp-fix.patch",
                "reuse profiles": "https://patch-diff.githubusercontent.com/raw/drupalcommerce/commerce/pull/760.diff",
                "reuse profiles enhanced": "https://github.com/fliegen/commerce/commit/57c11175d279fe55db9454b4274608195211aeb8.diff",
                "checkbox same as billing": "https://www.drupal.org/files/issues/checkbox-same-as-billing-2852207-69.patch"
            },
            "drupal/commerce_shipping": {
                "profile select enhancement": "https://github.com/fliegen/commerce_shipping/commit/797b5ef351851d60b2cb6c1a55837501c2a036a5.diff",
                "profile in shipping method widget fix": "https://www.drupal.org/files/issues/profile-reuse-enhanced-2908683-1.patch",
                "auto-recalculate shipping": "https://www.drupal.org/files/issues/commerce_shipping-autorecalculate-2849756-35.patch"
            }
        }

Then run composer install.

Go to Order -> Flow and then you will cog...

The patches in #88 seem to not work for commerce 8.x-2.4

For me the patches we're not applying in 2.3. Really not sure what I am doing wrong. Struggling with Composer.

This is important functionality and the fix seems to have been available for several months. What is stopping it from finding it's way in to Commerce Shipping?

Patch from #69 rolled against Commerce 2.4.

The patch in https://github.com/drupalcommerce/commerce/pull/760 fails to apply. Has anyone re-rolled it?

#93 works! thank you so much.

#2852207-93: Billing same as shipping works for me too! Thanks!

However, I have found one issue:
If you have few payment methods:
1. Tick the checkbox "My billing address is the same as my shipping address"
2. Change the payment method
3. The checkbox "My billing address is the same as my shipping address" will be unticked again.

The "Payment information" pane settings:
Allow reuse of shipping profile: Yes
Reuse shipping profile label: My billing address is the same as my shipping address.
Reuse shipping profile by default: Yes

Also a bug: If another address field widget is used for displaying the address form elements, the billing profile will continue to use the default one.

Are you guys using this patch in conjunction with any other ones? I am getting the following error with #93.

The commerce_profile_select element requires the #default_value property. in <em class="placeholder">Drupal\commerce_order\Element\ProfileSelect::processForm()</em> (line <em class="placeholder">93</em> of <em class="placeholder">modules/contrib/commerce/modules/order/src/Element/ProfileSelect.php</em>). <pre class="backtrace">call_user_func_array(Array, Array) (Line: 993)
Drupal\Core\Form\FormBuilder-&gt;doBuildForm(&#039;commerce_checkout_flow_multistep_default&#039;, Array, Object) (Line: 1056)

Hi, I can't apply the patch #93 throught composer.
Same issue with #69

It applies for me perfectly. It does't when combined with the other related patches.

The patch #93 can be applied via Composer, but it must be applied to drupal/commerce and not to drupal/commerce_shipping.
Example:

        "patches": {
            "drupal/commerce": {
                "Same billing address": "https://www.drupal.org/files/issues/checkbox-same-as-billing-2852207-93.patch"
            }
        },
        "enable-patching": true

Yes, it took some time for me to realize that I don't need the patches of #2844920: Allow customer profiles to be reused anymore. This patch works on it's own.

On another site I tried this patch with I also get the error described in #98

I had those patches applied to commerce_shipping:

"drupal/commerce_shipping": {
    "profile select enhancement": "https://github.com/fliegen/commerce_shipping/commit/797b5ef351851d60b2cb6c1a55837501c2a036a5.diff",
    "profile in shipping method widget fix": "https://www.drupal.org/files/issues/profile-reuse-enhanced-2908683-1.patch"
}

Removing them solved the issue for me.

Still a bit confusing.

Please could somebody post latest code to get this working, similar to that found in #89

Thanks

Hello,

I reversed and placed checkbox on shipping form instead billing form. Now when it's checked, shipping info reuses billing info, but there is a problem to calculate shipping costs. How to calculate the costs (if "same as billing info" checked) according to billing form on "Order Information" page ? on this step, shipping form is empfy.

#93 works great, thank you very much.

The only problem I found so far is that the text "My shipping address is the same as my billing address." doesn't seem to show up as a string that can be translated. Please advise me on how & where to report this.

I found the same problem. Solved it by translating the text in the checkout flow.

To make "Reuse shipping profile label" translatable (have the set label text appear as a translatable string) I had to edit "/modules/order/src/Element/ProfileSelect.php" line 141 and wrap $element['#reuse_profile_label'] in a t() function. I changed

'#title' => $element['#reuse_profile_label'],

to

'#title' => t($element['#reuse_profile_label']),

Sorry I don't know how to properly submit a patch to fix this, hope someone helps this bit to find its way into the code.

Hi everyone!

Been trying to use this patch and I've got an issue, which I don't know if is related to the patch or not.

After filling out the Shipping Information form, I click in the Pane's submit button and a "Please select a shipping method" message appears up top.

Although, there is no option to select any shipping method on the form, even though I do see a Recalculate shipping button. If I click it, the shipping method radio button appears and if I then click on the "Pay and complete purchase" option, I get to the next pane (Completion message).

So, it seems that the shipping method selection isn't showing up on the first render, only showing up after AJAX is used to recalculate the shipping costs.

I'm using a Checkout flow setup as in #26 and I only have one shipping method set up in Commerce's configuration (flat rate per item).

I was wondering if there is any way to prevent this "Recalculate shipping" bit, as I only have one option available. I mean not only fixing it so that it shows up on the first render, but also the ability to bypass it entirely, because it is an extra step that makes no sense for my case, as I'll only have 1 shipping method available.

Now, related to the patch itself, the store will sell shippable items and (not shippable) services. Will this patch affect that in any way? IE, if there are no shippable items, will it still prompt the user about the shipping information?

Actually, never mind the last bit. The shipping selection wasn't showing up because I had the "Hide shipping costs until an address is entered" option wrongly configured in the Shipping Pane.

Also I noticed that when only non-shippable items are being checked out, I still have the "billing info matches shipping info" checkbox selected, and I have to click it to show the form.

Which info is actually being entered on the toggled form? the billing info or the shipping info? If it is the shipping info, this shouldn't happen for non-shippable items. If it's the billing info, shouldn't be always visible?

Has anyone found a solution to the issue in #98?

#104: Currently the only working version is to apply only this patch. And none of the ones related to #2844920: Allow customer profiles to be reused and the ones for commerce_shipping:

"drupal/commerce": {
    "#2852207: Billing same as shipping": "https://www.drupal.org/files/issues/checkbox-same-as-billing-2852207-93.patch"
}

#108: This is a workarund. While this works for the moment, we will solve this using config translation. So this solution will break a some point.

i think the checkbox should be moved to after the billing address form. also, there should be an option to initially have the shipping form hidden and check the box to display the form "ship to a different address" checkbox. it makes more sense that way as far as useability.

Just tested, this patch. Thanks very much, this feature is essential. I found one problem. If the 'My shipping address is the same as my billing address.' checkbox is checked and you change the payment method the checkbox gets unchecked. It should stay checked.

Shouldn't we move that issue to Commerce? Or at least open another issue there and postpone this one on the new one?

I've just applied the patch from #93 and it seems to work well. I've checked/unchecked the checkbox, modified shipping address, went to next checkout step and then back, modified address again, etc.. no problems found.. I also haven't experienced the problem from #113 - maybe because I have the checkbox activated by default?!?

The question now is, what we can do to move this forward. The current patch is an essential workaround for everyone needing this feature, however I believe that it has zero chances to get committed because of the following reasons:

1. I quickly scanned through the code. One thing that definitely will have to be changed is commerce_order_get_shipping_profile(), for at least two reasons. It should sit in a service, And it adds a soft dependency to shipping, which is another contrib project. When we'd add a "hasField()" check to the if, it shouldn't break a non-shipping installation, but it's still a code smell to do that
2. Given the previous point, we have to find an elegant way to enable the payment pane from Commerce core to change it's behaviour when a certain kind of other checkout pane is available and retrieve information from it -> the shipping pane from Commerce Shipping in this case
3. missing tests

Update

I haven't noticed the already linked issue from Commerce, so I'll mention it again: #2910193: Allow reusing profile values from another inline form ("Billing same as shipping")

I'm no shipping maintainer, but I'd postpone this issue on #2910193: Allow reusing profile values from another inline form ("Billing same as shipping") b/c in the end, this one will most likely get obsolete and solved by the other one

Agree that this should be moved to commerce. Patch from #93 works partially, but doesn't apply on the latest 8.x-2.x anymore, thus needs a re-roll. As mentioned in #96, the code in the patch doesn't set the right default for the checkbox if you have multiple payment methods and one of them injects a form via ajax request. (For example the dummy payment gateway with onsite payment).

Here's a re-roll applying on the latest 8.x-2.x that also fixes the mentioned problem when switching payment methods. Won't set this to needs review though, because as stated in the previous post, still needs tests and some other improvements.

Patch in #93, as well as the reroll in #115 both, fail to apply to today's 2.5.0 release. I don't have time right now to look into it, just letting you all know.

Let's try this one... PhpStorm was intelligent enough to be able to apply the patch, altough there were some deferrals of lines due to some newer commits

btw, I've also experienced some problems with the older version of patch today - once I had checked the override flag and went back, it just seemed that I could change values, but it kept overriding them instead :(

Let's see, if that's still the case here

ok, forget the last one. it is breaking things!!

ok, there was obviously a bug in #115... let's try this one

ok, it applies and nothing is broken... but it ain't working at all :( The checkbox on the pane is completely gone :(

I found a solution see file

Right on @Saidatom. Patch applies and works for me.

@saidatom

The patch in #123 breaks the default value of the checkbox if you have multiple payment methods enabled. The checkbox will not be checked if you switch from a method with a form to one without. You reverted what i did here, if you would include that again it'll work with multiple payment methods: https://www.drupal.org/files/issues/2018-03-15/checkbox-same-as-billing-2852207-115.interdiff.txt

@Hubbs

If you'd have read what i posted in #115 you'd understand that my patch was against 8.x.2.x and not against the release.

ok, there was obviously a bug in #115... let's try this one

@agoradesign What bug?

@s_leu: sorry, I guess it was rather a something PhpStorm did merge in the false way.. I didn't really have time to look into this.

In #118 I committed a patch based on PhpStorm merged #115 in current dev.

This fully broke checkout with a PHP error. I went again into PhpStorm and saw the red underline somewhere, where "+ $profile_select_options" was added to an array. Then I saw the getProfileSelectOptions() and thought, you've just left this line unchanged. After that, the error was gone, but so the feature :D

I think, the very best would be, if you'll find some time and try to re-roll it against the current dev, because you're already familiar with this. It would be amazing, if you could do that!

reroll for commerce 2.5

also maybe this issue should be moved to commerce core?

@niko- I'm marking this as Needs Review further to your request in #commerce on drupal slack to get someone to review it :)

Hi niko, thanks for the reroll :) looking forward to try this, once I've found time :)

And no, there's already one for Commerce core: #2910193: Allow reusing profile values from another inline form ("Billing same as shipping")

In fact, all we do now here is to keep a workaround up to date, to be able to bypass the problem as long as Core hasn't added that feature.

In the end, we will be able to close this one as a duplicate hopefully :)

I can't apply the patch from #127

I get:
Could not apply patch! Skipping. The error was: Cannot apply patch https://www.drupal.org/files/issues/2018-03-21/checkbox-same-as-billing-2852207_127.patch

edit: I updated first to Drupal 8.5 and Commerce 2.5

Hi, The patch in #127 works for me. Thank you!

@fotograafinge I'm using Drupal 8.5 and Commerce 2.x-dev..

Patch #127 works for me too.
Drupal 8.5.0 + Commerce 2.5

The patch #127 is causing the following error on /user/{user}/payment-methods/add:
Error: Unsupported operand types in Drupal\commerce_payment\PluginForm\PaymentMethodAddForm->buildConfigurationForm()

Steps to reproduce:

1. Install Drupal 8.5 and Commerce 2.5.
2. Apply the patch #127 to drupal/commerce.
3. Enable Commerce modules.
4. Create payment gateway.
5. Visit user/1/payment-methods/add.

#127 + fixed issue from #133.

Use billing address for shipping (vice versa variant from existing one).

#137 these patches keep failing for me. i suppose one goes in commerce_shipping and one in commerce?

@niko- now i can apply patches. thanks!!!!!!! i will test

so testing fails with following error

TypeError: Argument 1 passed to Drupal\commerce_order\Entity\Order::setBillingProfile() must implement interface Drupal\profile\Entity\ProfileInterface, null given, called in /srv/bindings/714a4d9250874b7389282ca4bf34b475/code/web/modules/contrib/commerce/modules/payment/src/Plugin/Commerce/CheckoutPane/PaymentInformation.php on line 475 in Drupal\commerce_order\Entity\Order->setBillingProfile() (line 189 of /srv/bindings/714a4d9250874b7389282ca4bf34b475/code/web/modules/contrib/commerce/modules/order/src/Entity/Order.php) #0 /srv/bindings/714a4d9250874b7389282ca4bf34b475/code/web/modules/contrib/commerce/modules/payment/src/Plugin/Commerce/CheckoutPane/PaymentInformation.php(475): Drupal\commerce_order\Entity\Order->setBillingProfile(NULL) #1 /srv/bindings/714a4d9250874b7389282ca4bf34b475/code/web/modules/contrib/commerce/modules/checkout/src/Plugin/Commerce/CheckoutFlow/CheckoutFlowWithPanesBase.php(598):

Thanks @drupalstrap,

Sorry for some spam-like activity now without any comments. (have "go live" today for one of my client)
The patches above starting from #136 has the following diffs against #127
1. ability to enter payment information as main address and add "use shipping same as billing" checkbox on shipping pane (vice versa variant from #127) has added
2. the patches prior to #136 has issue: if user has only one payment method per shipping address and click on "next" button (without clicking on recalculate one) we should auto recalculate actual shippments and apply it to order on checkout form main submit, pane doesn't support this behaviour.

The following patches are applied on my project
https://www.drupal.org/files/issues/2018-03-28/checkbox-same-as-billing-...
https://www.drupal.org/files/issues/2018-03-28/checkbox-same-as-billing-...

all patches are for commerce 2.5 and latest commerce shipping beta at the moment

about #141 please try to apply patches as I described in #142 and #143

here is part of my composer.json

      "drupal/commerce": {
        "Checkbox same as billing": "https://www.drupal.org/files/issues/2018-03-28/checkbox-same-as-billing-commerce2852207_137.patch"
      },
      "drupal/commerce_shipping": {
        "Checkbox same as billing": "https://www.drupal.org/files/issues/2018-03-28/checkbox-same-as-billing-2852207_138.patch"
      },

@niko-

i am pretty certain i have applied the correct patches (per your json file) to commerce_shipping (Version: 8.x-2.0-beta4+7-dev) & commerce (Version: 8.x-2.5) both patches applied cleanly ... but the following errors occur on /order_information page

The website encountered an unexpected error. Please try again later.
TypeError: Argument 1 passed to Drupal\commerce_order\Entity\Order::setBillingProfile() must implement interface Drupal\profile\Entity\ProfileInterface, null given, called in /var/www/html/ergodesk/web/modules/contrib/commerce/modules/payment/src/Plugin/Commerce/CheckoutPane/PaymentInformation.php on line 475 in Drupal\commerce_order\Entity\Order->setBillingProfile() (line 189 of modules/contrib/commerce/modules/order/src/Entity/Order.php).

Drupal\commerce_order\Entity\Order->setBillingProfile(NULL) (Line: 475)
Drupal\commerce_payment\Plugin\Commerce\CheckoutPane\PaymentInformation->submitPaneForm(Array, Object, Array) (Line: 598)
Drupal\commerce_checkout\Plugin\Commerce\CheckoutFlow\CheckoutFlowWithPanesBase->submitForm(Array, Object)
call_user_func_array(Array, Array) (Line: 111)
Drupal\Core\Form\FormSubmitter->executeSubmitHandlers(Array, Object) (Line: 51)
Drupal\Core\Form\FormSubmitter->doSubmitForm(Array, Object) (Line: 585)
Drupal\Core\Form\FormBuilder->processForm('commerce_checkout_flow_multistep_default', Array, Object) (Line: 314)
Drupal\Core\Form\FormBuilder->buildForm('commerce_checkout_flow_multistep_default', Object) (Line: 212)
Drupal\Core\Form\FormBuilder->getForm(Object, 'order_information') (Line: 94)
Drupal\commerce_checkout\Controller\CheckoutController->formPage(Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 582)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 151)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 68)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 99)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 78)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 50)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 657)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

@niko-

tested new patch and fails with following

patching file src/Plugin/Commerce/CheckoutPane/ShippingInformation.php
Hunk #8 FAILED at 274.
1 out of 11 hunks FAILED -- saving rejects to file src/Plugin/Commerce/CheckoutPane/ShippingInformation.php.rej

Same problem as #146, patches apply fine, but can't continue checkout

I also can confirm the problem described in #146 - I was trying https://www.drupal.org/files/issues/2018-03-28/checkbox-same-as-billing-...

@niko-
most likely your setup includes only payment gatewys implementing SupportsStoredPaymentMethodsInterface, because the error happens in the else branch of this condition. This would explain, why you didn't experience that problem

Hi @agoradesign

Thanks for your explanation but I can't find interface named SupportsStoredPaymentMethodsInterface
Could you show correct interface name or maybe code reference and versions of commerce core and commerce shipping on your installation, so I can update my previous patches

@niko-
sorry to be unprecise. It's not directly in your patch, but the patch has impact on current code.

If you look into the stacktrace posted in #146, pay your attention to this part: "called in /var/www/html/ergodesk/web/modules/contrib/commerce/modules/payment/src/Plugin/Commerce/CheckoutPane/PaymentInformation.php on line 475 in Drupal\commerce_order\Entity\Order->setBillingProfile()"

And when you then look into the PaymentInformation class, you'll see the if/else inside of submitPaneForm(). The error is coming from the else branch of the condition "if ($payment_gateway->getPlugin() instanceof SupportsStoredPaymentMethodsInterface)"

Commerce 2.6

I reroll patch from #153 because it is missing class "BillingInformationPaneBase.php" which caused site crash.

The patch applies, also didn't experience the problem mentioned in #146. But there are still some problems - afaik earlier versions do have the same ones.

When you enter addresses and later return from review pane to edit them, there are a couple of things that do not work as expected.

First, the checkbox always gets the default value as configured in the checkout flow, but doesn't store and reflect the actual choice - reproduce, if you enable the checkbox by default, go to checkout, uncheck it, go to review, then return to order information step -> the checkbox will be checked again. The same problem exists the other way round.

Even worse: if you checked to use the same address once, you cannot split up later on change (obviously the same profile ID is referenced). Reproduce by check to use the same address as billing, proceed to review, then try to edit the billing address by e.g. entering a different street -> the shipping address will also be changed

I have rerolled patches to commerce (#154) and to commerce_shipping (#147) against core 8.5.2 / commerce dev-2.x / commerce_shipping dev-2.x

Just for redundancy, one patch should be applied against commerce and the other against commerce_shipping:

      "drupal/commerce": {
        "Checkbox same as billing": "https://www.drupal.org/files/issues/2018-04-24/commerce_checkbox-same-as-billing_156.patch"
      },
      "drupal/commerce_shipping": {
        "Checkbox same as billing": "https://www.drupal.org/files/issues/2018-04-24/commerce-shipping_checkbox-same-as-billing_156.patch"
      }

And, like in #153/154, I excluded BillingInformationPaneBase.php from the commerce patch. Rerolling.

these latest patches seem to fix the crash issue though i have not done extensive testing. i can say however there is a major issue with the logic here. if you click the same as billing address checkbox the billing info form is hidden and we have the shipping address displayed. this is wrong. we need to hide shipping and just keep billing displayed. billing form will typically have more information like tax numbers etc that we do not want to see on shipping form. in fact, the same form is duplicated twice ... so a tax number or such will appear in both billing and shipping forms. this is just not correct.

Hi @drupalstrap, check the discussion about that logic in #2626948: Checkout UX Meta or the links bojanz provides in the beginning of this thread. It is part of the commerce UX flow and outside the scope of this issue.

Any eta. on the "shipping same as billing" feature for the Shipping module?

Anyone tested it for anonymous user or new account? When I test it with anonymous checkout, it doesn't do anything.

correction: works as designed.

But it does not work together with the reusable profile (patches from https://www.drupal.org/project/commerce/issues/2844920 and https://www.drupal.org/project/commerce_shipping/issues/2948954)

The patch from #157 looks like fail when going to user page and try to add a new method of payment. I fixed with a simple verification. I attach new version.

I forgot the new file.

Sorry now yes.

Another update with some improve.

The issue reported in #133 works again for Drupal 8.5 + Commerce 2.6 with the patch from #157.

The patch does the same as #165.

I didn't use the patch from #165 because I am not sure why the following code is removed from modules/payment/src/PluginForm/PaymentMethodAddForm.php

'#default_value' => $billing_profile,
'#default_country' => $store ? $store->getAddress()->getCountryCode() : NULL,

Max what version of module are you using? I tried to apply but failed.

I tried #166 in simplytest.me and did not get the checkbox. Maybe it didn't apply correctly.

@fastangel Drupal Commerce 2.6

Patch 166 works as described!

Usability question.
This patch only makes sense if the ShippingInformation Pane is above the PaymentInformation Pane.

However, when you enter ShippingInformation pane first, the Available Shipping Methods suddenly appear, pushing down the payment information.
I personally think its better with the Payment Information on Top. and then the Shipping information below, with a Shipping same as Billing Checkbox.

What do you guys think?

@jonnyeom: Yes, personally I think you are absolutely right. All of the websites we maintain have billing first and shipping second. It's just the natural order for all shops I know and I have yet to find a client who would accept the order flipped around. Unfortunately the Drupal commerce maintainers decide to do it the other way for some obscure reason and any discussion about this was more or less abruptly squelched. Guess we have to accept that decision. But, nevertheless, it would be nice of course if this patch supported both orders. Otherwise we probably need to move the patch into a separate module or sth., because I also don't have an application for this patch as long as it requires the "wrong" order.

Double posted for some reason...

Just tested the patch in #166 on Commerce 2.7 and Shipping on latest dev. Works perfectly!

What is missing to get this committed? Maybe an update of the IS would make sense?

There is still one issue I reported earlier: If there is a existing payment method and choose add a new one, the setting of "Reuse shipping profile by default" isn't taken into account. It is always disabled when adding another payment method:

behavior is not too hard to implement. Lets get this patch in and then take care of your request.

@jonnyeom @rgpublic This really depends on the use case. To me the current behavior is the one I want on all my sites. I guess your desired

@Lukas, not sure but afaik the problem I've described in #155 isn't solved yet

@agoradesign Ah ok. Sorry, I didn't read that comment.

Does anyone have a patch compatible with #2844920: Allow customer profiles to be reused?

What a pity that this issue is quite stuck atm... I'll be too busy at least for the next two weeks, hoping to have time then to look into this, unless someone has time earlier... We'd need this for every single Commerce project we launch

Patch 166 works for me with commerce 8.x-2.8, however it breaks when also installed with patch 91 at Implement registration after guest checkout.

I have to chime in on this, too, in the hope that it receives higher priority.

Any client that is shipping a product is going to ask about this feature — it's a given. I haven't seen a checkout that doesn't include this since the early days of e-commerce.

I want to see Commerce gain adoption, but delaying important details like this one can hinder that. The priority on this should be considered Major. I'm not a developer, otherwise I'd offer more than just my 2 cents

How does it break in combination with the other patch? I've used both yesterday for a project, that is still in development. Only looked at it quickly. At first glance it seemed to work (except the problem mentioned in #155)

IMHO, what's currently problematic with the situation: There are far too many patches necessary to get decent basic functionality. A patch should be a one-off thing for rather exotic things. Not sth. that you have to do on each and every single website to get a running system. The problem I have is: Those patches change regularly. They influence each other. Have to be applied in the correct order. And so forth. If at least some of the current patches (Billing same as shipping, Reuse billing/shipping profile, Allow registration after guest checkout) would be integrated into the main codebase, then we'd have sth. to rely on for other, smaller patches...

OK. I summarize the points from #155:

1) The checkbox state [x] Billing same as shipping is currently not restored properly when you return later from the review page. (Wrong default value)

2) If you selected "[x] Billing same as shipping" and later change your mind, return from the review page, and enter a separate shipping address, the billing address is inadvertently changed as well. (A clone should be created; Profiles should not point to the same entity anymore)

As suggested in #180, bullet 2; this patch changes function "submitForm" in modules/order/src/Element/ProfileSelect.php to create a duplicate of the profile instead of sharing it.

$element['#profile'] = $profile;

becomes

$duplicate = $profile->createDuplicate();
$duplicate->save();
$element['#profile'] = $duplicate;

This seemed to fix the issue of inadvertent profile changes for me, but could use more testing.

patch #181 is missing a file. This patch should be complete.

@spacetaxi: I didn't have the time to try it yet, but I wonder: Doesnt this *always* duplicate the profile? Even if the same profile is selected? I think this should be avoided, shouldn't it? But perhaps you already thought of this. Just wanted to make sure...

@rgpublic: I'm using this with an authorize.net payment module, which stores the card before the review step. When I go back to the overview step, I get a set of radio buttons to select an existing payment method (with my current one selected), or enter a new one entirely. See screen shot below.

So for a billing address change, I would have check the new credit card radio button to re-enter the card and address (or check the box to copy the shipping address).

In other situations, what is likely to occur is that when one goes back to the checkout overview step, the billing information fields will now be populated with the newly created profile and the box to copy the shipping information will be unchecked. Since the box isn't checked, it won't create yet another duplicate when the form is submitted. (At least I think this is how it will work, I still need to test).

Thus, maybe the checkbox state not remembering the previous selection might be interpreted as a "feature" and not a "bug" ? :)

@spacetaxi: Hm, well the problem with that approach is: The user ends up with two completely identical addresses in his/her address book which show up if they go to the "My account" section. I don't think this is really an optimal solution...

@rgpublic: I understand. Then my best guess would be to store the checkbox state to the order object and have the billing profile form hidden unless it is unchecked. Does that sound right?

@spacetaxi: I'm no official commerce expert/developer, so I can give just my €0,02, but: I'd say that probably you don't need to actually store the state somewhere. You can simply check whether shipping and billing point to the very same profile (ID). This avoid that you might run into inconsistency problems one day when for whatever obscure reason the stored checkbox state doesnt match the actually state of the profiles.

OK, have been banging my head against this for about half a day.

I've been working on commerce/modules/order/src/Element/ProfileSelect.php trying to see if I can get the checkbox to check, but no joy.

There is a line of code that doesn't seem to be working:

$reuse_profile = (isset($storage['pane_' . $element['#name']]['reuse_profile']))
      ? $storage['pane_' . $element['#name']]['reuse_profile']
      : $element['#reuse_profile_default'];

$storage['pane_' . $element['#name']]['reuse_profile'] doesn't seem to be getting set.

I tried changing this code to check if the shipping profile matches the current billing profile. This does seem to work:

$order = \Drupal::routeMatch()->getParameter('commerce_order');
$reuse_profile = ($element['#profile'] == $order->getBillingProfile())
     ? TRUE
     : $element['#reuse_profile_default'];

But the rest of the code governing the turning off of profile form elements and turning on checkboxes appears completely broken. Maybe someone else could take a look?

@spacetaxi I can't help you with the #188 problem, at least for now, but I found some redundant code in your patch. Please take a look to the file.

Uops! Sorry, wrong patch in #189, this is the correct file.

Third time's the charm!

Shouldn't this technically be an issue in the general commerce module? When you apply the patches here it's against the dev version of commerce not the commerce_shipping module.

@DaPooch no, since this feature is only needed if commerce_shipping is installed.

Just as an information:

This implementation will clash with the planned commerce core feature to select existing profiles:
https://www.drupal.org/project/commerce/issues/2844920

Using this patch, on every order a new profile will be created. Unluckly the profile select patch and this implementation heavily clashes. Maybe we should think about finding a solution, that works together with the new profile select widget.

@Juanjol - Thanks for cleaning up the repetitive code

Here is a new patch that will reuse the shipping profile as the billing profile without duplicating it. It will, however, create a new billing profile if you subsequently go back, uncheck and enter a new address.

I haven't tested with reusing existing profiles, but seems to fix the issues brought up in #155 and summarized in #180.

Sounds great :) Could you also provide an interdiff please? Would be a lot easier to review for others

thanks :)

@spacetaxi: The new patch in #195 has multiple issues:
- The validation is completely broken. It you check "Shipping address is the same as billing" and the form is not displayed, you will get an error about missing fields that are not even visible
- The new patch does only support the address field. Its a common use case, that you add new fields like the Phone Number to the customer profile. These additional field will not work and will always be displayed. With patch #166 it works correctly.

@ayalon: Thanks, I see now that I was handing the form Ajax completely wrong. I reworked it and now it switches #access to all fields on and off. Previous patch versions were set to only turn #access to false if $reuse_profile was true.

One piece of code that needs work is determining if the checkbox should be checked. As I mentioned in #188, the code in previous patches to determine this doesn't seem to work:

$reuse_profile = (isset($storage['pane_' . $element['#name']]['reuse_profile']))
      ? $storage['pane_' . $element['#name']]['reuse_profile']
      : $element['#reuse_profile_default'];

I've left this in, but followed with a check of my own, which compares the profile ids and checks it if they are the same id:

// set $reuse_proflie if profile ids are the same
if (isset($complete_form['payment_information']['billing_information']['#default_value'])) {
  if (!empty($complete_form['payment_information']['billing_information']['#default_value']->id()) && !empty($element['#reuse_profile_label'])) {
    if ($complete_form['payment_information']['billing_information']['#default_value']->id() == $complete_form['shipping_information']['shipping_profile']['#default_value']->id()) {
      $reuse_profile = TRUE;
    }
  }
}

Can anyone suggest a better technique?

@spacetaxi: As I stated in #187, I think you're definitively on the right track. It's nonsense to store the "reuse_profile" info separately somewhere. It's not needed. It's just redudant info that has to be kept in sync. If the profile IDs are the same, then the profile is reused. If they are different, they are not. So, I think you can safely remove the $reuse_profile line IMHO.

@rgpublic but very often there won't be profile IDs at all at this point, because the entered addresses are new ones - but it should still be possible to reuse the profile here

@agoradesign: Hm, but what I don't understand: Why is there any need to put the checkbox state into the form storage? I enter a new address. Then I check the box [x] Billing same as shipping. I click on submit. At this point the information whether the checkbox has been checked or not is obviously still available, because it's the current POST call.

If the checkbox is checked, only one profile is created and shipping and billing will point to the same profile ID happily ever after. Now, I go back to the previous page. We want to know: Should the checkbox be checked already when the page is loaded (i.e. default value)? Of course, we can now look at the profile IDs and compare them. There's no need to put the checkbox state into the storage explicitly, I guess. Or is there any case that I missed?

Thanks @rgpublic and @agoradesign for your help.

It turns out that storing "reuse_profile" is necessary because billing profile fields are refreshed dynamically via Ajax when the checkbox is changed, but the profile id is not. So you can end up in a situation with previous patch where you might uncheck the checkbox, but the profile fields remain hidden. The problem is, "reuse_profile" is not available at the start of the form.

I fixed the Ajax so that it uses the #checked boolean instead of #value for "reuse_profile." I then reworked the setting of the $reuse_profile variable to first to check for this storage (Ajax requests), then matching profile ids, then the default setting.

Again, there is probably a cleaner/better way to do the billing/shipping profile id comparison. I also wonder if there is some way to have the "reuse_profile" storage set as a session variable; that would make the initial billing/shipping profile id comparison not necessary.

I honestly havent'd dived to deep into the existing implmenentation, nor the patches here. I just thought that we shouldn't forget about that many/most profiles aren't saved at this moment. The last interdiff looks reasonable, I hope that we are getting close to a working patch now :) (unfortunately there the patch will have to be adapted again after #2844920: Allow customer profiles to be reused is solved)

As an idea, maybe reuse_profile value can be stored in $order->setData. I think this is a logic location to store this info better than store it in session.

We have another major issue here: We do not respectthe fact, that these profiles should be reusable!
If a logged-in user enters the checkout, he should be able to select his address from a previous order.

Please have a look at this issue:
https://www.drupal.org/project/commerce/issues/2844920

This is a screen with the current patch over there:

All efforts are worthless if we do not take into account, that this feature hopefully soon will get into commerce.

Thanks @Juanjol, that seems like a great option.

To the points made by @agoradesign & @ayalon, we've taken this as far we should until https://www.drupal.org/project/commerce/issues/2844920 is resolved. However, I do think that what we have is compatible with reusable profiles.

Hi, Using Commerce 2.10 and Commerce Shipping 1.0-beta5. When tried #204 applied to the commerce module, if the product is available to ship it works correctly, but if the cart has a product that is not shippable I got this error:

The website encountered an unexpected error. Please try again later.
Error: Call to a member function id() on null in Drupal\commerce_order\Element\ProfileSelect::processForm() (line 118 of modules\contrib\commerce\modules\order\src\Element\ProfileSelect.php).
Drupal\commerce_order\Element\ProfileSelect::processForm(Array, Object, Array)
call_user_func_array(Array, Array) (Line: 997)
Drupal\Core\Form\FormBuilder->doBuildForm('commerce_checkout_flow_multistep_default', Array, Object) (Line: 1060)
Drupal\Core\Form\FormBuilder->doBuildForm('commerce_checkout_flow_multistep_default', Array, Object) (Line: 1060)
Drupal\Core\Form\FormBuilder->doBuildForm('commerce_checkout_flow_multistep_default', Array, Object) (Line: 561)
Drupal\Core\Form\FormBuilder->processForm('commerce_checkout_flow_multistep_default', Array, Object) (Line: 318)
Drupal\Core\Form\FormBuilder->buildForm('commerce_checkout_flow_multistep_default', Object) (Line: 216)
Drupal\Core\Form\FormBuilder->getForm(Object, 'order_information') (Line: 94)
Drupal\commerce_checkout\Controller\CheckoutController->formPage(Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 582)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 151)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 68)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 57)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 99)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 78)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 47)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 52)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 23)
Stack\StackedHttpKernel->handle(Object, 1, 1) (Line: 665)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

As noted in #108, the reuse_profile_label seems still not to be translatable. I added the proposed solution there and created a new patch based on #204 and latest dev.
Or is it already possible to translate that string via config translation?

I recognizes, that the "Reuse profile" checkbox is always checked if the default value is true, even if the user is coming back from the next step of the checkout form.
In my oppinion the checkbox should not be checked, if the order has already a billing and a shipping profile set and those are not the same.

I created a patch, that takes this into account.

Patch in #211 works for me

#211 Worked for me.

Confirm that #211 worked for me with Drupal: 8.6.5, Commerce: 8.2.11 and Commerce-shipping: 2.0-beta5 and PHP 7.2.
So thank you. It would be nice to have Payment information first and then have Shipping information below with the checkbox. But it works and do the job.

The guest checkout is not working - profile is not being created. If you allow registration on checkout - a profile is being saved and user can log in - but if user want to buy more - all fields are empty. So here is my question: Do I need any other patches from above to be able to pick a profile? Sorry if its stated above - but I cant figure it out? Or do I need some other patch not in this issue?

Tks

In short, all these patches are dead end. AFAIR @bojanz is now working on fixing this in a completely different way which requires changes in Entity API, Profile and Commerce.
I doubt any of patches here will be ever merged since every patch has some issues.
We just need to wait till Commerce Guys do everything right.
I'm updating the issue status to Postponed.

I agree with PeterStubPeytz ... the checkbox should be on the shipping information pane ... it should be shipping same as billing. i have never seen it this way before and don't really understand why go through all of the work to make this patch (at least one year now) and do not even put it in the correct place. Don't get me wrong, I am very grateful for the contributions and effort being made on this, and i am thankful it kinda works finally. It is just a frustrating that such a basic and common functionality has taken so long and is still not correct. Perhaps a bounty needs to be created for this ... I am willing to chip in if others are as well. I think we finally need this functionality done right and stable.

@pyxio I think both is possible:

But form a UX perspective it makes sense to think about shipping first and then about billing.

"I might need to check whether the seller ships to that particular location. Then if it ships I might enter billing address."

"When you are prompted for shipping address I think users immediately know the answer (where I want my goods to be delivered). It's a simple answer. However, in the case of billing address users can be hesitant (makes them think), but if they have already inputted the shipping address it will be easier for them to come to the conclusion that if they're shipping somewhere different than their home address (your usual billing address) then it is different."

https://ux.stackexchange.com/questions/105206/shipping-address-is-same-a...

@pyxio: Yes, I also find this situation very unfortunate and frustrating. Nevertheless, as some kind of explanation and better understanding of the whole history of this mess, this is my take on this:

1) I think the real reason why it was decided that shipping should come (by default) before billing is that external payment gateways like BrainTree etc. usually also store the billing information with the payment credentials (i.e. credit card number etc.). And from an UX point-of-view, it makes some sense to ask for payment data last to avoid putting off customers in previous checkout steps.

2) Unfortunately, I have yet to find a customer who accepts this flipped order. When we tell them we want to put shipping first they think we're nuts. No matter what good arguments we might have. And the explanation "People want to check first whether the item ships to their location" makes some sense of course, but isnt of any importance for national shops. It gets worse if you also sell virtual items that don't ship anywhere. Whatever. There's been a huge discussion around this and it has been decided to leave it that way.

3) Next problem: This issue here of course largely depends on the "reuse profile" feature to become stable. As we can witness here, it just doesnt make sense to solve this issue until the other issue is really finalized, because all the great patches we already have break again as soon as they change the reuse profile feature.

4) The change profile feature, in turn, has also been quite a bumpy road. It was implemented first and only seemed to have some open bugs. But then it was completely re-implemented as a modal dialog. Then someone changed it back to the original version. And finally, they found out that the whole approach just isnt feasible and very difficult to get really bug-free. This is because of an unfortunate design decision in commerce where complex controls like the profile selector are implemented as render elements. I've stumbled A LOT upon this working on Commerce projects and found those elements very difficult to tame but never really questioned this original design decision. I just thought it needed to be that way. So, finally, they decided to abandon that approach and replace it with an easier system where such "complex" control elements (i.e. elements consisting of multiple fields like the profile selector) are implemented with a plugin system. I havent seen the implementation details yet, but I think in general this is a great idea and makes much more sense than the render element solution. It will make a lot of other things easier to deal with in the long run (like altering those profile selectors later etc.). So, on a positive note, I think it is a good thing that this is changed - even after all that time spent in vain.

5) Now. Where do we stand? IMHO we should now just wait for the reuse profile feature to be stable in Commerce core. Next, this feature can be implemented. I personally think this feature must work both ways. Billing same as shipping. Shipping same as billing. Why? Simple reason: You can modify/reorder the checkout panes in the UI by drag & drop. This is an existing feature and I think it's brilliant. This feature here should just adapt to whatever is configured. The default can very well be shipping before billing but if you move the panes it should IMHO still work properly. If this issue here (after it is fixed) won't work that way I'll immediately file a new issue because I'd consider that a bug. We'll see how the Commerce folks react to that ;-) If they close that bug as WONTFIX, then I'll write a separate module that will implement this behavior because for us here it's simply needed for all shops we're currently taking care of. But, as you can see, it only makes sense to do one thing after another. I doesnt make sense to write that module until this issue and the reuse profile issue is stable and fixed. Keeping fingers crossed.

@rgpublic ... thanks for the awesome detailed reply. You really helped me understand the complexity of the issue which is good as I just couldn't understand why this feature was taking so long and so complicated. Now I get it. Anyway, i once again would like to thank everybody who is working on this important issue. your contributions are much appreciated. cheers kevin

Want to add another point of view that we have a isseu with. I think the order is not a problem if you have a shipping methode with also is a real shipment at the moment we also use shiping for an option to select pick up in store, the problem here is that shipping information is required but with a pickup it would not be needed. I understand that this wont be in the scope of commerce_shipping but because there are no other solutions yet that we know of we use it this way. this also applies to like the carrier DHL which offers a delivery methode to pick your order at some of there pickup points

Hello together

While updating commerce to 2.12 the patch in #211 does not apply anymore. Does anybody have the same problems?

Yeah, #211 cannot be applied on 2.12..

Yeah, #211 cannot be applied on 2.12..