When 'copying' featured is enabled, PHP notice appears which affects recalculation of shipping services

I have just committed a fix for this error in #2415627: Empty default_country causes issues when the field is required. Please retest with tomorrow's -dev version, and I'll tag a new release shortly.

I believe I was running into the same issue. Setting the default country under admin/commerce/customer-profiles/types/billing/fields/commerce_customer_address seems to have fixed the issue for me.

I've the same error :(. Same discussion is also here: https://www.drupal.org/node/2478363

Please try the patch in #2410911: Notice: Undefined index: addressfield in commerce_shipping_recalculate_services_submit(), see if any errors remain.

Hey bojanz,
I've already applied the last patch from #2410911 :( I can reproduce this error

Notice: Undefined index: #default_value in addressfield_standard_country_validate() (Line 602 in /.../all/modules/addressfield/addressfield.module).

if I clear my browser cache and go to checkout and select different countries.

//edit: The address-data is also not copied to the shipping address-data as it should when copying is enabled.. If you continue an error says that the data is missing. But after a page reload the data appears.

@IckZ
Thanks for testing.

I have exactly the same issue.

There is a solution ?

Hello

Somebody have found a solution ?

Thx

Is there any progress on this issue? I've tested several settings and patches but did not solve the problem :(

I have the same issue.
But good news, I think I fixed it for my case.
Notice that I have all the three panes at the same page 'checkout':
-customer_profile_billing
-customer_profile_shipping
-commerce_shipping

In addition to the message "Notice: Undefined index: #default_value in addressfield_standard_country_validate() (line 594 of .../modules/addressfield/addressfield.module)." I've got also strange messages that shipping fields(which are hidden) are required: "Address 1 field is required. ...".

The issue for me was that the commerce_customer_profile form was build not correct.
The commerce_customer_profile_copy_validate() has some logic of copying of profile data. It was not triggered on shipping re-calculation.
Here is my patch. It adds an additional check if form build was triggered by $triggering_element == 'recalculate'.

Notice patch is for Drupal Commerce and not address field. If it helps you too, let's open another issue for the DC module.

Following. I've just updated to 7.1.2 and have the same error from the self-same combination of Commerce modules + checkout pane arrangement as #18. Q.

Another related issue: #2410911: Notice: Undefined index: addressfield in commerce_shipping_recalculate_services_submit().

Fabulous! It fixed the problem for me!

Interesting ... it would be weird to include Commerce Shipping specific code in Drupal Commerce itself, so maybe we need to give modules a hook to use to identify legitimate buttons on the checkout form for copying properly.

I would like to offer an alternative patch.
Looks like the customer profile should be re-calculated on any request if customer profile copy is "On".

re-rolled #23

After #25 error dissapeared (it worked for me).

#25 works for me too! thanks a lot :)

Thx, guys for testing. Updating the status to RTBC.

Patch #25 works for me too! Thank you all!

PS: Updating the Component since this may affect the checkout but it is actually a fix in the customer module.

Patch #25 also works for me!
Thanks!

#25 appears to resolve #2521082: Customer profile copy create empty copy if source validation fail as well

I think the main reason behind the checks performed in the "elseif" condition was to prevent the expensive profile copying logic to run anytime there's an ajax request performed on that page (The order entity would now be saved way more often with the patch).

This patch seems to solve the issue described, but the correct shipping services appear on the pane only if all the required fields from the source pane are filled (and not before).

This is caused by the fact that the validation fails on the source pane causing the source profile not to be saved (which means that when the profile is copied, it gets the last source profile entity that was successfully saved).

IMO we should expand the patch in order to completely skip the profile copying logic when the source profile pane is present on the page and has validation errors (Adding this logic would make sure the order entity is saved only if necessary)...

Additionally, I updated the patch to just use $element['#value']; inside the condition since we're inside an element_validate callback attached to the profile copy checkbox itself.

Great, thanks everyone for your help on this patch. I was able to reproduce the failing scenario on a vanilla install of Commerce 1.x (albeit on PHP 7), though for whatever reason I couldn't get my local env't to actually display the failure notice.

I looked back at the original patch that added this functionality, #1410022: Improve copy address functionality - create a more generic solution, to try to discover any rationale for the multi-conditioned if statement that this patch simplifies, and I couldn't find any. Since the #element_validate handler is going to be invoked every time the form validates, I was worried that simplifying the condition meant we'd now have extra saves we used to not have ... and I confirmed that by adding the coupon Ajax pane to the page.

However, for whatever reason, it's the combination that matters - when I keep the form error checker but not the simplified condition statement, I run back into the original error. Any thoughts on why these things have to go together?

@rszrama: Without the simplified condition statement, the profile copying logic kicks in only when the checkbox is unchecked/checked or when the "continue" button in checkout is clicked.

This means that until you uncheck/check the checkbox again, or submit the form, the profile information that was copied is potentially outdated. (That's likely to happen if you updated your billing profile after you checked the profile copying checkbox).

Not sure if that answers your question or not but I'm happy to discuss this on Slack :).

Good deal. Yeah, I think the idea here is sound - unless a profile copying checkbox is specifically unchecked, we should look to see if copying is enabled any time the #element_validate handler executes and copy if appropriate. This may result in more saves in cases where other Ajax operations trigger form validation on checkout, but it's a trade-off to avoid false errors decreasing conversions.

Committed!