Allow customer profiles to be reused

Let me work on it !

@jkuma Check the bojanz latest commit. He works on this right now.

Not sure if it is my specific issue or it is somehow related with the commit. What is interesting (see screenshot's second attempt to update) after manually adding "drupal/address": "1.x-dev" to my composer.json "require-dev" block it reports this:

The requested package drupal/address (locked at 1.0.0-rc3, required as 1.x-dev) is satisfiable by drupal/address[1.0.0-rc3] but these conflict with your requirements or minimum-stability.

And that is despite the fact 1.x-dev version is available for composer to install. (composer info -a drupal/address)

@bojan

Sorry for the delay in my reply. Last week-end, I spent quality time to study the way to fetch customer profiles for the current logged user. The problem is, as you may know, there are no such methods to get all customer profiles from an UID. So, we can create a plugin or add a new method in order to do so, but I think it's nasty.

From my perspective, we need to create a customer entity type and gather all related data (customer profiles, customer preferences) on this entity type. We can keep the uid property on order, but each time an order is created, we create or udpate a related customer entity. Using the customer entity, it'll be more easier to fetch profiles, but also to build a "my account" page.

Assigning.

The attached patch kind of works. TODO:

1. Cleanup, docs, comments.
2. Fix buggy '+ Enter a new address'
3. Tests
4. PR

As for the functionality it looks good and quite similar to the one suggested by bojanz here but I'd like to see this solution rewritten like this:

That way we can do all the actions with one button. No +Enter new address and Edit and Return to address selection buttons. When clicked at one of the Select an address options you'd get all the appropriate fields filled in with the information for this address. When clicked at the Continue to review button the new profile is created if some of the existing profile field values were changed. If user wants just to edit existing profile without creating new one, they can go to Address Book in a user profile and do this. It is better because the history of all the address profiles and their ever used revisions are kept and managed in one place.

@drugan Discussed this with @bojanz and the problem with omitting the buttons is that it's not clear for the user what's going to happen when they edit a profile: is it going to create a new profile or update the old one? So we decided to stick with the buttons.

There's one difference from the 7.x-3.x implementation: when editing a profile the profile will be updated in 8.x, and not a new one created as in 7.x-3.x (which might be a bug there).

My PR is here, still without tests but everything else is fixed:
https://github.com/drupalcommerce/commerce/pull/631

Checkout as anonymous should not offer anonymous profiles.

Fixed the anonymous checkout case, tests are green on the PR.

@czigor : I applied the patch, but when i click to +Enter new address , Add new address and click on proceed to review it gives me WSOD

The patch is not working , as when i click to +Enter new address , Add new address and click on proceed to review it gives me WSOD

@chishah92 For me it works on a clean drupal commerce 2 install. Can you provide some extra information that helps me to reproduce it?

@czigor :
I too have a clean drupal commerce 2

1) It works fine when i place the order for the first time where there is no address in the profile

2) But for the second time when you go to checkout and select Enter new address and click to proceed to review it gives WSOD

3) Also if you select the used one's and edit it and click to proceed to review, it gives WSOD

Please Advice,

Let me know if you want more information

Also to add on, I get below error from error.log

[Mon Feb 20 13:10:03.244281 2017] [php7:notice] [pid 2094] [client 127.0.0.1:40598] PHP 191. Drupal\\Core\\Form\\FormErrorHandler->setElementErrorsFromFormState() from core/lib/Drupal/Core/Form/FormErrorHandler.php:60, referer:

@chishah92 What versions of drupal and commerce are you using?

I also face the same issue as @chishah92.
I'm using Drupal core 8.2.4 and commerce 8.x-2.x

Drupal core 8.2.4 and commerce 8.x-2.x

Still can't reproduce.

I did the following:
1. Downloaded the 8.2.4. tarball
2. I added the drupal repository to the core composer.json.
3. Ran composer require drupal/commerce.
3a. EDIT: Applied the PR https://github.com/drupalcommerce/commerce/pull/631.
4. Installed drupal through browser using a standard install profile.
5. Enabled commerce, commerce_cart, commerce_checkout, commerce_order, commerce_price, commerce_product, commerce_store.
6. Imported US dollar as currency at /admin/commerce/config/currency.
7. Added a store with random values at /admin/commerce/stores.
8. Added a product with one variation at /product/add/default.
9. Did 2 checkouts with uid1, both times created a new profile.

Is there anything you did differently?

i also can't reproduce.

My version was drupal/commerce 2.x-dev

@chishah92 Mine as well. Added step 3a to the steps above.

@czigor

It worked. I tested using the wrong patch. Previously I tested by applying commerce-profile_select-2844920-7.patch patch. After applying https://patch-diff.githubusercontent.com/raw/drupalcommerce/commerce/pul... it works!

The profile selector is not working for the shipping information pane provided with Commerce Shipping Module. Maybe it must be an issue with the commerce shipping module.

@Safallia Joseph For me it works. Can you describe what you expect and what happens instead?

I enabled commerce shipping module and added the Shipping information pane. On checkout, the profile picker dropdown is displayed in the Shipping profile pane. But Selecting a different profile does not replace the current address summary with the new one. I used commerce shipping module version 8.x-2.x-dev.

Thanks, I have fixed it. Can you test it?

Same PR? Was that issue related with profileSelect?

Yep! Its working now.
Thanks for the fix

@czigor : It works fine for both billing and shipping. But when i updated the 8.x-2.x-dev version of commerce_shipping released on feb 20. The profile selection feature doesnt appear in shipping info and also after add the new address and edit on review, the user has to fill up the shipping info form once again.

@chishah92 This is because of #2852719: Temporarily stop storing shipping profiles in the address book. This has to be fixed in commerce_shipping.

Cool no issues. Thanks for the patch.

@czigor : I had created issue On editing the shipping info on review page , user has to fill up the form once again. for shipping module but it seems the issue is due to this patch

@czigor : also we are getting same issue for billing address, the once we save an address on review, when we click on edit we get the first address instead of the saved one.

@chishah92: Not sure what you mean. Do you need shipping to reproduce this? I have several billing profiles, I select one of them, click Edit and in the form I see the selected profile's values correctly.

@czigor. I also got a same issue. When i click Edit link on review page, the billing and shipping information shows default first address not that we were selected the address.
This is the review page with updated address. I am clicking Edit link here, it goes to order information page

After i got the order information page, my selected address is not showing.

@chishah92 @padma28 Added a fix, can you review it?

Thank You @czigor. The patch is working fine.

@czigor : Patch works fine. Thankyou so much for a quick update, Appreciated.

This still needs tests.

patch works like a charm with latest dev

This patch is working well for me too (from the GitHub PR).

For anyone using this patch and commerce_shipping, you can revert the recent temporary commerce_shipping change that stopped this from working using the patch I'm attaching here. I'm going to hide it since it's not the real patch for this issue, but it works well with the real patch for anyone using commerce_shipping's latest versions.

Here's a reroll of the patch against the current commerce release with one fix (setting $default_profile_id to NULL by default so it's not unset in case it doesn't get overridden later).

I commented in the PR so hopefully it'll be fixed there, too, but I needed somewhere to patch from in the meantime.

One thing I've found, this may be a known issue already, but this patch assumes that "address" is the only field that's a part of the profile. For instance, I have a field_phone field which should ideally be shown/hidden along with the address field since it's a part of the profile being reused, however the field is still present when the address is hidden.

Thanks @bmcclure, fixed these issues as well. They are in the PR. Tests are still needed.

@czigor : After applying the latest patch from git , when the user enters the address for the first time , The review button get's is disabled

ScreenShot :

Currently we have a Quote checkout flow that uses commerce_shipping, but does not have billing information. The shipping profiles are using the profile select element via this patch.

As an anonymous user, when I fill out the profile form, calculate shipping, and then continue to the next step, it works fine, but I also get:

"Notice: Undefined index: pane_shipping_information[shipping_profile] in Drupal\commerce_order\Element\ProfileSelect::submitForm() (line 312 of modules/commerce/modules/order/src/Element/ProfileSelect.php)."

I'm not certain offhand if something is different on my installation causing this, or if this is an issue with the patch. Anyone else experiencing this?

Simply modifying the conditional from (in_array($storage['pane_' . $pane_id]['mode'], ['new', 'edit'])) to (isset($storage['pane_' . $pane_id]) && in_array($storage['pane_' . $pane_id]['mode'], ['new', 'edit'])) fixes the issue for me. But I don't know why, because it seems like the profile isn't being saved then. However considering it works fine, I'm assuming something else is saving the profile in this anonymous / new profile case.

@bmcclure : I tried to apply the patch #47 , but when i create new profiles , it overrides the previous one instead it should create new ones

Please Advice

@chichah92 I would recommend using the patch in the GitHub PR instead of mine, as it's been updated since I posted my version. Do you still experience that issue with the latest patch from czigor's PR?

@bmcclure : Yes i have used the patch from czigor's PR , and i facing this issue as stated in #53

@czigor : The Patch Works Fine if i don't have a shipping profile, if i have the same and suppose i edit or create a new profile in my shipping information, it disables the review button.

This issue / task sounds really interesting, and needed in its correct implementation, but once applied the latest patch (from GitHub PR) I experience the following bad use cases:

• Cannot Add a new Customer Profile in the Order checkout / Payment Information State: no Add button present
• Cannot Save any Edit to the Customer Profile in the Order checkout / Payment Information State: just the “Return to profile selection” button appears in the edit form
• In the Order edit page/form, the Select & the Edit button on the Profile / Billing Information fieldset don’t work at all.
• It is not possible to edit (any way) the Billing Information in the Order edit page (as a result of the previous)
• Once the Order is placed (checkout completed), if the user changes his address_book / customer profile info, than it is changed also in the Order itself. Is this the wanted behavior? or should it be kept (frozen) the data provided in the checkout process? (as it is in the actual core behavior) and edited just in the Order Edit form …

It's worth noting that I don't experience a couple of the issues you mention.

• Adding a new profile should be an option within the select list, and that works fine for me
• Saving the edits happen when you continue to the next step of checkout
• Admittedly I haven't tested this on the order edit page yet so there may be issues there that I just haven't found (I'm sure our client will)
• This is just how Commerce works currently. There are several potential issues with entities that are reused, such as payment information and profiles, in that they can be modified or deleted later and then previous orders are no longer accurate. I'm not sure what the status is offhand of this being worked on, but I don't think it's the responsibility of this patch to solve.

The issues that i face after the new patch is applied :
1) Initially when there is no profile, the checkout page does not show the Add new profile select list.
2) Adding two addresses for payment and shipping creates two profiles. But when we go in checkout page once again and add select add new profile for both payment and shipping information, the continue to review button is unset
3) Also when we select the same previous profiles and click to "Continue review" button in review page it shows only payment information with the first profile and When we click on Edit, one more duplicate profile get's created.

Summary : The profile save and edit are not working accordingly, needs rewrite.

@bmcclure sorry ... you are right, but I have to still confirm the following issue:

1) In the Order edit page/form, the Select & the Edit button on the Profile / Billing Information fieldset don’t work at all.

and add this, that really seems a mayor bug to me:

2) If I remove an Address / Customer Profile previously associated to a placed Order, that Order is not editable anymore and the site breaks on that attempt: exception thrown (and not catched)

This patch is actually working pretty great on a production site for us. I'm attempting to figure out what the difference is between our setup and yours. Are you using the latest dev version of commerce and commerce_shipping?

1. For me, when there is no existing profile created, it shows a profile creation form on the checkout page as it should, which then creates a new profile.
2. I'm not experiencing this one either, but that might be because I'm also using a patch for commerce_shipping which auto-calculates shipping and controls the Continue button.
3. I'm not sure I understand what you mean about this one. For me, when I get to the Review page, it shows whichever profiles I have selected for payment and shipping, and clicking Edit next to either of them goes back to the Order Information page with the same profiles still selected. Could you explain a little more how the behavior differs for you?

Note that currently, commerce_shipping forces the shipping profile to be owned by the anonymous user, which prevents a profile select field from ever showing up for shipping (unless you revert that change with another patch).

@itamair:

#1 seems like a bug that this patch may need to handle.
#2 is a known issue in Commerce unrelated to this patch, that's being handled elsewhere.

I'm actually not sure where the issue is regarding the fact that profiles should not be deletable when they're in use, but there should be an issue like that for every entity type associated with orders, as mentioned in this issue: https://www.drupal.org/node/2842579

tnx @bmcclure ... I confirm that bug is unrelated to this patch, as it happens with the actual core/committed functionalities too

@bmcclure :
2) Even i have added the auto-calculate shipping patch(https://www.drupal.org/node/2849756), yet i face the issue

3) The senario is i have already two profiles in my address-book. When i place my order again, in checkout page i get to select any of the profiles. But if i select new profile for payment and select the old profile in shipping , the review page shows only payment information. And when i click to edit, it goes back to order information, but here one more duplicate profile gets created.

Can you guide me for which patch needs to be applied to revert it ?

Just had a quick chat with @chishah92 in Slack and realized that I'm experiencing the same issue as his scenario #3 above. I just visited my address book and there's a ton of duplicate addresses existing--I just didn't notice because all seems fine while going through checkout.

Any updates on this one ?

I've incorporated all of the changes in the previous patch from czigor here, along with #reuse_profile options added for the ability to show a checkbox that copies another profile, and have been committing a few small changes to this functionality there.

The credit for this profile select functionality still goes to czigor, but as this is an alternate way to get this same patch if you also want to use the "Billing address same as shipping" functionality, and I may continue to make modifications/fixes to it there, I figured I would post it here as well:

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

In reference to my previous message, just wanted to note that I'm in the process of revamping some of how my code in PR 715 works to try and eliminate a couple issues I've been running into (duplicate profiles that keep getting created being the main one, among a couple of logic bugs I introduced when changing things around to support profile reuse). I'll have the PR updated today if anyone else happens to be using it and experiencing any issues.

I've updated PR 715, including refactoring and modifying some of the logic behind the functionality of selecting existing profiles, and reorganizing a lot of code in the element.

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

It still works very similarly to czigor's patch, but supports the latest changes to the commerce 2.x dev branch, and I think it resolves the profile duplication issues.

Looking for feedback on this. Does it work well for others? If so, is there anything more needed in the element for it to be fully functional?

Note: This PR also includes code to resolve a related commerce_shipping issue (https://www.drupal.org/node/2852207)

#bmcclure I am not able to apply https://github.com/drupalcommerce/commerce/pull/715.patch to any actual version of Drupal commerce (both 2.0-beta6 and
2.x-dev).

@itamair: GitHub seems to have some sort of really long term caching or something on PR .patch links, sadly. Several days after I updated the PR, that patch link is still outdated.

I found that using .diff instead of .patch showed me an updated link, but that might just be because that wasn't cached yet so your mileage may vary.

The PR itself applies to the latest version of commerce, it's just that particular patch link that doesn't.

Note to anyone using this patch: https://www.drupal.org/node/2872823 is related and might be affecting this functionality within the payment gateway form profile select element.

I've also updated the PR with a couple of fixes and some refactored code again. Here's a patch, since there seems to be an issue with GitHub returning the latest patch files.

Note that .patch and .diff is not the same thing. .patch is actually a patch-per-commit thingy that can't really be applied and results in strange merge conflicts and so on. .diff always works fine for me and I never have caching issues.

Thanks for clarifying that! That definitely explains my confusion.

@Berdir @bmcclure tnx to both of you ... ;-)

Ok @bmcclure ... tnx!
the "https://github.com/drupalcommerce/commerce/pull/715.diff seem to apply correctly into the "drupal/commerce": "2.x-dev",
BUT ...
I face the following error/exception when I try to edit an existing Order (also if still in the Cart):

InvalidArgumentException: The commerce_profile_select element requires the #default_value property. in Drupal\commerce_order\Element\ProfileSelect::processForm() (line 99 of modules/contrib/commerce/modules/order/src/Element/ProfileSelect.php).

That might happen in this 2 possibile user/administrator scenarios:

A - (quite improbable, but anyway possibile) I try to edit the Order when it is still in the Cart and the User didn't attach any billing info to it yet (at Payment Info Panel);

B - I remove an existing Billing Profile and I try to edit the Order that was previously filled with that profile ... (a real possibile scenario). I understand that Drupal Commerce itself is keeping into the Order the reference to the Customer profile address, but I think this is really risky: Order info (once placed) should be independent by Customer Address Book info, and anyway persistent;

Further more I still experience this other bug (already by me mentioned in some previous comment):

C - Billing Info / Customer Address is not editable from the Order edit back-end (the edit submit button don't work).

@itamair:

Regarding the exception, did you perhaps experience that same exception before using this patch? The #default_value validation was always done in the ProfileSelect element, this patch doesn't change that I don't believe.

Regarding point B above, Commerce should be disallowing the deletion of addresses, especially if they're in use anywhere. Commerce needs to implement a "soft delete" feature that simply hides the address once it's removed but allows it to still be referenced.

Regarding C, I haven't looked into that issue at all yet, have been focused on the customer UX so far. What should the actual behavior be for editing from an admin? Should an admin be able to edit a customer's profile from within the order, affecting all other orders that profile is used, when editing the order? Seems like we either need to fix the behavior of the button on that form, or remove it if it shouldn't be there.

@bmcclure

A - yes ... may be. I remember @Boianz already said there is not a logic to block the deletion of used entities. And this affects all the Drupal Commerce areas (and is a very major vulnerability and problem of the system)

B - ... but IMO Commerce shouldn't even directly reference the user profiles entities into the Order, but just add a detached copy of that (the profile address), so that it might be changed/edited in the Order backend independently (might be needed, after a Customer request ... or whatever), without the consequent update of the original profile, and its instances in different/other Orders ...

C - The Customer address / Billing Info profile Edit button don't work (in my case) in all its recurrences: both the Order edit backend (where it is present) and also in the Order information checkout pane itself ... (just placing the Cart Order)

A - True, it's pretty major in my opinion. Nothing we can do about it in this patch, however I hope that it gets some attention soon.

B - I see what you mean. I can definitely see how it could be useful, but I think it's a larger issue that extends beyond this patch to how orders are structured and processed overall. Perhaps a separate issue should be created to open this up for further discussion. I think the ability to select an existing profile is going to be useful either way, as that copying of the profile to the order could could still happen either way.

C - You're right, I'm noticing the same issue as well. It works fine in the Shipping Information pane for me but fails in the payment information pane. I'm working on some more fixes yet again for this and trying to simplify how complex it's gotten as much as possible, hoping the edit button will work in all contexts once I'm done with that.

I've been playing around with the patch code a lot again today, and I've discovered that, with the recent fix by Berdir, there might be some unnecessary code that was previously used to avoid the issues with the ProfileSelect field.

Moving back to Needs Work, because the new version is going to be simpler and work better, I think. Refactoring, tweaking, and testing, and I'll have a new patch up ASAP tomorrow.

@bmcclure tnx ... yes, I agree that on the B matter we would need a new issue open.
And I just opened it (Protecting Customer/Billing Profiles against changes)
I am minding may be entity revisions, instead of entity reference, would be a good way to go ...

Alright, I think this one is working much better:

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

@bmcclure Thanks for working on this!

We will need tests.

I installed the Patch from #85 and get the following error. On the checkout form there is no form for adding billing information.

TypeError: Argument 1 passed to Drupal\commerce_payment\Entity\PaymentMethod::setBillingProfile() must implement interface Drupal\profile\Entity\ProfileInterface, null given

@eric-haydrich: What version of commerce? Can you possibly post a full stack trace from that error? Thanks!

@bmcclure Here's the stack trace. Current commerce dev-Version with patch 715 from #84 on Drupal 8.3.2.

TypeError: Argument 1 passed to Drupal\commerce_payment\Entity\PaymentMethod::setBillingProfile() must implement interface Drupal\profile\Entity\ProfileInterface, null given, called in [ROOT_PATH]/web/modules/contrib/commerce/modules/payment/src/PluginForm/PaymentMethodAddForm.php on line 112 in Drupal\commerce_payment\Entity\PaymentMethod->setBillingProfile() (line 152 of [ROOT_PATH]/web/modules/contrib/commerce/modules/payment/src/Entity/PaymentMethod.php) #0
[ROOT_PATH]/web/modules/contrib/commerce/modules/payment/src/PluginForm/PaymentMethodAddForm.php(112): Drupal\commerce_payment\Entity\PaymentMethod->setBillingProfile(NULL) #1
[ROOT_PATH]/web/modules/contrib/commerce/modules/payment/src/Element/PaymentGatewayForm.php(118): Drupal\commerce_payment\PluginForm\PaymentMethodAddForm->submitConfigurationForm(Array, Object(Drupal\Core\Form\FormState)) #2 [internal function]: Drupal\commerce_payment\Element\PaymentGatewayForm::submitForm(Array, Object(Drupal\Core\Form\FormState)) #3
[ROOT_PATH]/web/modules/contrib/commerce/src/Element/CommerceElementTrait.php(95): call_user_func_array(Array, Array)#4
[ROOT_PATH]/web/modules/contrib/commerce/src/Element/CommerceElementTrait.php(88): Drupal\commerce_payment\Element\PaymentGatewayForm::executeElementSubmitHandlers(Array, Object(Drupal\Core\Form\FormState)) #5
[ROOT_PATH]/web/modules/contrib/commerce/src/Element/CommerceElementTrait.php(88): Drupal\commerce_payment\Element\PaymentGatewayForm::executeElementSubmitHandlers(Array, Object(Drupal\Core\Form\FormState)) #6
[internal function]: Drupal\commerce_payment\Element\PaymentGatewayForm::executeElementSubmitHandlers(Array, Object(Drupal\Core\Form\FormState)) #7
[ROOT_PATH]/web/core/lib/Drupal/Core/Form/FormValidator.php(83): call_user_func_array(Array, Array) #8
[ROOT_PATH]/web/core/lib/Drupal/Core/Form/FormValidator.php(270): Drupal\Core\Form\FormValidator->executeValidateHandlers(Array, Object(Drupal\Core\Form\FormState)) #9
[ROOT_PATH]/web/core/lib/Drupal/Core/Form/FormValidator.php(119): Drupal\Core\Form\FormValidator->doValidateForm(Array, Object(Drupal\Core\Form\FormState), 'commerce_checko...') #10
[ROOT_PATH]/web/core/lib/Drupal/Core/Form/FormBuilder.php(571): Drupal\Core\Form\FormValidator->validateForm('commerce_checko...', Array, Object(Drupal\Core\Form\FormState)) #11
[ROOT_PATH]/web/core/lib/Drupal/Core/Form/FormBuilder.php(314): Drupal\Core\Form\FormBuilder->processForm('commerce_checko...', Array, Object(Drupal\Core\Form\FormState)) #12
[ROOT_PATH]/web/core/lib/Drupal/Core/Form/FormBuilder.php(212): Drupal\Core\Form\FormBuilder->buildForm('commerce_checko...', Object(Drupal\Core\Form\FormState)) #13
[ROOT_PATH]/web/modules/contrib/commerce/modules/checkout/src/Controller/CheckoutController.php(94): Drupal\Core\Form\FormBuilder->getForm(Object(Drupal\commerce_checkout\Plugin\Commerce\CheckoutFlow\MultistepDefault), 'order_informati...') #14
[internal function]: Drupal\commerce_checkout\Controller\CheckoutController->formPage(Object(Drupal\Core\Routing\RouteMatch)) #15
[ROOT_PATH]/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(123): call_user_func_array(Array, Array) #16
[ROOT_PATH]/web/core/lib/Drupal/Core/Render/Renderer.php(574): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() #17
[ROOT_PATH]/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(124): Drupal\Core\Render\Renderer->executeInRenderContext(Object(Drupal\Core\Render\RenderContext), Object(Closure)) #18
[ROOT_PATH]/web/core/lib/Drupal/Core/EventSubscriber/EarlyRenderingControllerWrapperSubscriber.php(97): Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) #19
[internal function]: Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() #20
[ROOT_PATH]/vendor/symfony/http-kernel/HttpKernel.php(144): call_user_func_array(Object(Closure), Array) #21
[ROOT_PATH]/vendor/symfony/http-kernel/HttpKernel.php(64): Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object(Symfony\Component\HttpFoundation\Request), 1) #22
[ROOT_PATH]/web/core/lib/Drupal/Core/StackMiddleware/Session.php(57): Symfony\Component\HttpKernel\HttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #23
[ROOT_PATH]/web/core/lib/Drupal/Core/StackMiddleware/KernelPreHandle.php(47): Drupal\Core\StackMiddleware\Session->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #24
[ROOT_PATH]/web/core/lib/Drupal/Core/StackMiddleware/ReverseProxyMiddleware.php(47): Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #25
[ROOT_PATH]/web/core/lib/Drupal/Core/StackMiddleware/NegotiationMiddleware.php(50): Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #26
[ROOT_PATH]/vendor/stack/builder/src/Stack/StackedHttpKernel.php(23): Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #27
[ROOT_PATH]/web/core/lib/Drupal/Core/DrupalKernel.php(656): Stack\StackedHttpKernel->handle(Object(Symfony\Component\HttpFoundation\Request), 1, true) #28
[ROOT_PATH]/web/index.php(19): Drupal\Core\DrupalKernel->handle(Object(Symfony\Component\HttpFoundation\Request)) #29
{main}.

I started working on writing just the tests, here they are. I think we need tests for the following:

I. Anonymous
I.1. The profile select should not appear, only the address.
I.2. Submitting the form creates a uid=0 profile.
II. Authenticated without profile
II. 1. No select, only address
II. 2. Submitting the form creates a profile for the user.
III. Authenticated user having 2 profiles already
III. 1. Select appears.
III. 2. Selecting another profile refreshes the displayed profile summary.
III. 2. a. Submitting the form does not change the selected profile.
III. 3. Clicking Edit works properly: the profile summary disappears, a prefilled form appears instead with a 'Return to profile selection without saving' button
III. 3. a. Submitting the form updates the existing profile, does not create a new one.
III. 4. Selecting '+ Enter a new profile' displays an empty profile form. No 'Return to profile selection without saving' button.
III. 4.a. Submitting the form creates a new profile.

We also need to test the same when there are two ProfileSelect form elements in the same form.

The attached patch contains I. and II. and the very beginning of III.

Updated my PR at https://github.com/drupalcommerce/commerce/pull/631/files.

Improvements:
- Has tests
- Uses proper form API (no form_state storage and not depending on pane ids)

Known bugs:
- Clicking "Edit" does not populate form with profile field values.
- Does not create new profiles, always overwrites the last profile.
- When validation fails (because of a wrong zip code for example) the form goes back to the state where it's first loaded.

I have not run tests.

Cool! Test coverage is awesome. I'm anxious to try this out, but it seems like it's broken functionally at the moment. Using the form API more closely seems like a good way to go, though I believe all 3 current known bugs were introduced with this latest patch.

I'll keep using my previous patch for the time being so that the profile select functionality works properly on our site, but I'll be monitoring this issue and will be sure to test any further patches that are at least functionally equivalent to the previous ones.

I'm running with this for a bit. Since maintainer, I can push to czigor's fork on GitHub for the PR. Already found an issue when country code changes, the element mode reverts back to View and not New/Edit.

I've pushed some fixes. More are needed. When you save from edit, the mode gets kicked back to view and all form values are gone

Subscribe

Tried the code in PR posted in comment #94.

When I go to checkout/../order_information i immediately get the following error:

The website encountered an unexpected error. Please try again later.
Recoverable fatal error: Object of class Drupal\profile\Entity\Profile could not be converted to string in Drupal\Core\Entity\ContentEntityStorageBase->buildCacheId() (line 722 of core/lib/Drupal/Core/Entity/ContentEntityStorageBase.php).
Drupal\Core\Entity\ContentEntityStorageBase->buildCacheId(Object) (Line: 614)
Drupal\Core\Entity\ContentEntityStorageBase->getFromPersistentCache(Array) (Line: 396)
Drupal\Core\Entity\Sql\SqlContentEntityStorage->doLoadMultiple(Array) (Line: 242)
Drupal\Core\Entity\EntityStorageBase->loadMultiple(Array) (Line: 212)
Drupal\Core\Entity\EntityStorageBase->load(Object) (Line: 176)
Drupal\commerce_order\Element\ProfileSelect::processForm(Array, Object, Array)
call_user_func_array(Array, Array) (Line: 982)
Drupal\Core\Form\FormBuilder->doBuildForm('commerce_checkout_flow_multistep_default', Array, Object) (Line: 1045)
Drupal\Core\Form\FormBuilder->doBuildForm('commerce_checkout_flow_multistep_default', Array, Object) (Line: 1045)
Drupal\Core\Form\FormBuilder->doBuildForm('commerce_checkout_flow_multistep_default', Array, Object) (Line: 557)
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: 574)
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}()
call_user_func_array(Object, Array) (Line: 144)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 64)
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: 656)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

The error in comment #96 occurs by the commerce_shipping module. Because commerce_shipping uses commerce_profile_select form element, it should be updated to follow the new array structure.

Current commerce_profile_select type in commerce_shipping module:

$pane_form['shipping_profile'] = [
  '#type' => 'commerce_profile_select',
  '#default_value' => $shipping_profile,   // If the shipping profile is empty, it should be null
  '#default_country' => $store->getAddress()->getCountryCode(),
  '#available_countries' => $available_countries,
];

commerce_profile_select type in PR#760 and code snippet is here.

$form['billing_profile'] = [
  '#type' => 'commerce_profile_select',
  '#default_value' => $profile,
  '#default_country' => 'FR',
  '#available_countries' => ['US', 'FR'],
  '#profile_type' => 'customer',
  '#owner_uid' => \Drupal::currentUser()->id(),
];

If PR #760 will be accepted and release in RC2 #2895339: Release Commerce 2.0-rc2, a new issue for working on the shipping profile should also be added into RC1 #2902683: Create a 8.x-2.0-rc1 release.
I can try to work on it.

I enhanced the PR#760 on the commit. And it is ready for review. The discussion is also on the Github PR#760.

@JeroenT and others, johnHuang has a commit on his fork of drupalcommerce/commerce_shipping that makes this work. my composer.json looks like this:

"drupal/commerce": {
                "reuse profiles": "https://patch-diff.githubusercontent.com/raw/drupalcommerce/commerce/pull/760.diff",
                "reuse profiles enhanced": "https://github.com/fliegen/commerce/commit/57c11175d279fe55db9454b4274608195211aeb8.diff"
              },
 "drupal/commerce_shipping": {
                "profile select enhancement": "https://github.com/fliegen/commerce_shipping/commit/797b5ef351851d60b2cb6c1a55837501c2a036a5.diff",
            }

@bojanz, can we bump this issue to major? It seems to me that profile reuse is a requirement of a full release, and therefore an RC, and there's getting to be too much code scattered in different folks' git branches. I think it needs to be reviewed and brought into the master branches so that people can get onto the RCs.

Hi @ransomweaver, thanks for your testing. The commerce_shipping doesn't complete, because the multiple shipment testing in commerce_shipping module doesn't pass.

I have added a patch to this issue: https://www.drupal.org/node/2852207#comment-12250322 "Billing same as Shipping" which gets it working with PR 760 instead of the obsolete PRs 714/715

Related issue for Commerce Shipping: https://www.drupal.org/node/2908683

It would be great if we could add into the mix the ability to override the list of billing and shipping addresses, so as to create a set of addresses for specific users - hook_xxx_alter().

In our case - we're supporting some B2B - where a designated coordinator can set a range of addresses for linked purchasers (eg central office to deliver to a range of their shops, where someone in the shop can do the ordering, but billing goes to central office and goods go to only a pre-set address/list of addresses).

We sort out the registration and approval of the various parties and want to be able to set the appropriate addresses at checkout.

There is a PR in github by @jigish.addweb that solves this issue, and doesn't have the issue that @bojanz is describing. https://github.com/drupalcommerce/commerce/pull/796

This is the .diff pf that PR.

Hi @bojanz, I have no idea how to enable commerce_order_test module, since the drush and Drupal modules page don't find the commerce_order_test module. Could you help me to enable it?

@johnhuang0808 You need to enable the extension_discovery_scan_tests in settings.local.php on your local dev environment to see the test modules.

For anyone who would like to get to 2.0 or the current dev and also have a functioning profile reuse with shipping/billing, here's my solution until this issue has been resolved.

The obstacle to applying PR 760 as a patch is merely that there was a small change made to ProfileSelect to check that the specified default country is actually available. The attached patch reverses that commit so that PR 760 can apply. If this check on the default country is important to you, I suggest making your own patch and putting it on gist to apply after PR 760 has been applied.

Here is some composer.json that puts this all together, including checkbox same as billing and auto-recalculate shipping:

"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"
  }

@ransomweaver wow, this comment is a life saver! Thank you!

@ransomweaver Those patches combined have one issue: If I adnavce in the checkout until the review step and then navigate back to the step where my shipping information pane is, I get the following error:

TypeError: Argument 1 passed to Drupal\commerce_tax\TaxZone::match() must implement interface CommerceGuys\Addressing\AddressInterface, null given, called in /var/www/drupal/public_html/web/modules/contrib/commerce/modules/tax/src/Plugin/Commerce/TaxType/LocalTaxTypeBase.php on line 278 in Drupal\commerce_tax\TaxZone->match() (line 138 of /var/www/drupal/public_html/web/modules/contrib/commerce/modules/tax/src/TaxZone.php) #0 /var/www/drupal/public_html/web/modules/contrib/commerce/modules/tax/src/Plugin/Commerce/TaxType/LocalTaxTypeBase.php(278)

After that the shipping address fields are cleared. The user has to edit the shipping profile and re-enter all information.

I'm still trying to find out what is causing this. Can anyone reproduce this behavior?

I've been struggling with an issue using this patch combination where the shipping fields don't seem to have been saved to the profile by the time shipping is calculated. So, for example, in FedEx, the code $shipment->getShippingProfile()->address->isEmpty() returns TRUE and no rate request is attempted.

Is anyone else running into this? It must be some sort of conflict between either patch versions or commerce and commerce_shipping versions it seems like, but I don't yet know why. I'm on the latest dev version of both currently.

Yes, I have the same issue when moving back in the checkout process. In my case this happens when moving to the login step and choosing the guest checkout option. After that the shipping profile fields are empty and I get the error I mentioned in #114.

Which patch is causing this to happen?

Hi

Please use this Drupal 8 module. I think it will full fill your requirement. This module allows reusing the existing address in the checkout form.

https://www.drupal.org/project/address_checkout

I'm using the patches suggested in #111.

With these patches, "New address" appears to be selected by default.

I think it makes more sense to select the default customer profile address (if the customer has already made an order and input an address) since in many cases, the person probably is using the same billing address/having goods sent to the same place.

@ptmkenney #119 I'm not seeing that. I have the following:

1 - new user creates account prior to entering checkout info page
2 - user enters shipping info and cc card info, billing same as shipping or enters separate billing address
3 - completes order
4 - adds another item to cart and goes to checkout
5 - user lands on checkout info page with a) previous shipping address selected in the "select a profile" dropdown b) previous payment method selected by radio button "visa ending in ...."

I can't make any more fixes to this, as its now a dead end. See @bojanz in #106 for the way forward. This issue is at the top of the commerce roadmap issue list: https://www.drupal.org/project/commerce/issues/2913801

@ransomweaver Ok, it's an issue with my configuration then. I didn't realize your patch was a dead end because the issue was set to "Needs review". I'm adding the new issue as a related issue to make it easier for people who are searching for this to find.

For info, the patches collection from #111 still applied well on commerce 2.2 :-)

#111 looks fine, but everything here breaks the hook_commerce_shipping_methods_alter() since the $shipment in the hook will be a blank shipment, so you can't compare it to the methods in order to custom show/hide it.

Experienced similar issue as described in #123. In a custom shipping method, the shipping profile was not set on the shipment, preventing to make comparisons. Something must be wrong in the ajax request. Didn't find time to explore this issue. I finally removed patchs #111.

@ransomweaver: The patches you mentioned does indeed make it all work for me, with one major problem:

If I add a new field to the profile (CVR field, just a plain text field) it does not get saved properly in the form during checkout if I make modifications to it there, whereas the default profile fields do get saved (when editing an existing profile).

I would like to have a look at solving this myself, and am currently looking into how to do that, but if you (or anyone) know where the problem is likely occuring in code, that would save me some time.

Updating IS and seeing what the difference is between the PR in #108 and the patch in #106.

106 applies, but 108 needs a re-roll. It also looks like the PR in #108 won't work with the current code base based on https://github.com/drupalcommerce/commerce/pull/796#issuecomment-333904322.

So that means we need to figure out the click assignment issue from the early process callback.

I spent a little time looking into this. I was hoping I would be able to move this along, but alas, I cannot. The ajaxRefresh call returns the form and state using the fall through of element state mode = form. Because the form is built prior to calling ajax. We need to return the form as if the element state mode = view. But we don't have a good way to trigger on that because the FormBuilder (around lines 1095) defaults to setting the trigger_element to the first button in the form, even on first paint of the form. When there isn't any button pressing. I tried adding a (hidden) dummy button on the page so the first button is something else so we can trigger on a valid pressed button. But that didn't work either for some reason. I couldn't even get the form to print on refresh.

TLDR; No further progress. But I'm happy to review anyone's work that is able to fix the problem. The patch in #106 works pretty well otherwise.

I wonder if we can use the same approach that is used by commerce_shipping's re-calculate shipping button on the shipping info checkout pane.

• Use a button. Important
• Set a form state flag in the submit or validate handler signaling which element state form mode to use.
• Then re-execute the logic in the element build logic using the form_state flag to determine what form elements to return

The patches still work great for me on Commerce 2.3, except for the issue I described in #114. Somehow the existing profile is lost if an anonymous user navigates back and forth in the checkout process. Can anyone else reproduce this?

Here is an issue that tries fixing the WSOD, but the issue remains: #2925470: Address variable should be optional in TaxZone::match().

Marking as major since the follow-up issue #2910193: Allow reusing profile values from another inline form ("Billing same as shipping") is also major.

The method in #111 no longer works for commerce 8.x-2.4.

Here is the patch from #106 applied to commerce 8.x-2.4

Going to start plugging away at this with my comments from #129 as the start.

There's still an issue with form state getting stale. But otherwise, this is much further along.

This resolved the issue in #135. So now we have a fully functional widget. Next is to fix up tests. If someone gets to that first, great. Un-assigning for now.

Just fixing phpcs findings before I forget about it.

Thanks for this great patch!
Working perfectly for the Payment information.

I tried to use it in combination with commerce_shipping, but the following error occurs:

The website encountered an unexpected error. Please try again later.
TypeError: Argument 1 passed to Drupal\Core\Entity\EntityViewBuilder::view() must implement interface Drupal\Core\Entity\EntityInterface, null given, called in /Users/stijn/websites/test-commerce/www/modules/contrib/commerce/modules/order/src/Element/ProfileSelect.php on line 214 in Drupal\Core\Entity\EntityViewBuilder->view() (line 110 of core/lib/Drupal/Core/Entity/EntityViewBuilder.php).

Maybe this is a commerce_shipping issue. This evening I will try to debug further.

commerce 8.x-2.4
commerce_shipping 8.x-2.0-beta4

I cannot seem to get phantomjs to run and store my user session, so local running of tests are falling on their face. Hopefully the testbot is more merciful. Here's an attempt at getting the first anonymous test to pass.

I fixed the error in #141 by patching the commerce_shipping module. (https://www.drupal.org/project/commerce_shipping/issues/2948954)

Now I can use the functionality for both fields. Only issue I have now is that the AJAX-functionality for editing the profile is only working on the first widget on that page.

So, after some actual attempts to implement the above patch. I think it won't work. See https://twitter.com/lucashedding/status/971083165895970817

Let's see if we can do this another way.

Not sure how helpful the interdiff is going to be. This is an entire new approach by loading the entity add and edit forms in a modal. The UX is mostly OK. Tests are probably not passing yet. But things work and we get around the previous buggy problems.

Nice work Heddn. I've made a few additions

• If no profiles exist, the user is presented with the "add new profile" link by itself. I modified the patch so that it shows the default profile form if no profiles exist.
• I added the 'button' CSS class to make the links prettier

One issue I have found is when editing a profile, the user can choose to delete the profile. After deleting, the redirect breaks and you are shown AJAX command info instead of going back to the checkout page.

One issue I have found is that in checkout, when you already have an existing credit card, then click create new credit card, the add and edit buttons destination parameter is messed up:?destination=/checkout/1/order_information%3Fajax_form%3D1%26_wrapper_format%3Ddrupal_ajax

Changed the AJAX wrapper to wrap the entire element so that the edit button is updated properly when switching profiles. I modified the destination parameter to get the path a different way so that AJAX parameters aren't included.

Here's some more refactoring and accounts for anonymous cart checkout. For anonymous, we cannot really use a select widget as we cannot load a list of previous profiles.

And here's the patch.

The last patch didn't work. I get the following error:

InvalidArgumentException: The commerce_profile_select #profile_type property must be provided. in Drupal\commerce_order\Element\ProfileSelect::validateElementProperties() (Line 90 in root/web/modules/contrib/commerce/modules/order/src/Element/ProfileSelect.php).

@Eric Heydrich -- The reason you are getting that error is because you have something that is depending upon the old ProfileSelect element. If you use the patch in #157, you'll have to patch everything that utilizes the ProfileSelect element...such as the shipping information CheckoutPane (Issue # 2948954)

Hi,

This is my proposed approach for doing the reusable profiles in a way that shouldn't breaking anything, even as a temporary solution until something better comes along.

Basically I'm just adding a select options field to the element with an ajax onChange callback and would see that the fields could be pre-populated with corresponding profiles values, if any of the values were to be changed, a new profile would be created anyway and just in case for easier UX understanding I'd also add a "add new" option to the select list options, which would empty the fields but it shouldn't matter.

The code isn't finished, I still need to implement the changes to the actual form fields. As there seems to be an increasing demand for some sort of solution to this, I'm hoping this could be of any help or a considerable viable temporary solution. If it's of any interest I could finish the rest tomorrow ( I hope )

Best,

Alari

Sorry, I seem to have forgotten to declare a correct root folder for the patch, I'll upload again.

EDIT:
Apparently I don't know how to create a decent patch file :(

@Aluuu

Do this from inside commerce folder:

git diff > my.patch

Re: the continued work for #157, I wonder if we can drop the CRUD operations entirely to add or edit a profile. What I saw on amazon.com was only a select list. It was empty if there were no addresses. Then at the top of the page, there were links to the profile section of amazon to add/edit/delete (manage) profiles. We don't have to go that extreme, but we could copy it spirit.

What if we did the similar. Just print a select list of all profiles, then had another link widget or something to link folks to the profile collection route to manage profiles. This link wouldn't be apart of the select widget at all. But would be listed on the billing and shipping steps of a checkout. If the user is anonymous or doesn't have any profiles already created we could still give them the initial profile form directly on the page. But if they do have profiles, then just display them in the select list. And leave up to the user to find the link on the page to manage profiles if they want to add anything more than add the first/initial profile.

I arrived at this just now when working on a multiple destination shipping solution. The page looks UGLY when I give them a select list /and/ the buttons to manage their profiles. I'd much prefer just a simple select list and links at the top of the page to manage my profiles.

Here's a screenshot of how messy it looks. I want to hide the edit/add buttons. And move them to the top of the page.

@heddn #164 'I wonder if we can drop the CRUD operations entirely to add or edit a profile' I agree this would be a better user experience. Borrowing from Amazon is bound to be a good idea :)

I've added the 'Needs usability review' tag to this issue as I think it would be helpful.

In the meantime if anyone has a little time to move the add/edit buttons higher, and write a patch that would be awesome!

Not sure if dropping it would be a good approach. Maybe we can give 2 options?

Anyway a decision needs to be made at some point, but I often order something online, and I would not want to get redirected away from the checkout to modify my address.

As for the patches: 2844920-156.patch works great, but I found today that the profile type is hardcoded.

This should instead be taken from to profile type field.

I have rerolled te patch on top of latest dev. And I have also removed a hardcoded profile bundle from the widget.

That interdiff doesnt look right.

Here's a quick hide of the operation buttons for billing. It isn't intended for use anywhere yet. Just to get a feel how hard it would be to hide it. It seems pretty easy actually.

Here we fix up the first of the tests. More to come later.

I keep getting these errors:

The website encountered an unexpected error. Please try again later.InvalidArgumentException: The commerce_profile_select element requires the #default_value property. in Drupal\commerce_order\Element\ProfileSelect::processForm() (line 80 of modules/contrib/commerce/modules/order/src/Element/ProfileSelect.php).

Not sure if it's caused by this patch (#171) or by the related issue #2948954: Commerce_profile_select reusable profiles

=> my mistake, solved

And here we are a little closer on tests. I think they are pretty close now. If someone with more FunctionalJavascript experience wanted to look at things, this might be able to wrap up pretty easily.