Start using Address 2.x

Initial patch, guessing the Profile module has to be updated too.

Tagged an Address 2.0.0-beta1: https://www.drupal.org/project/address/releases/2.0.0-beta1 →

The adress 2.0 fix is not into the latest release of 2.x.dev

+        AddressField::ADDRESS_LINE3 => ['override' => FieldOverride::HIDDEN],

We should be doing this on the profile address as well, since gateways and shipping methods aren't handling a third address line just yet.

Yes, but this should be done from the profile module no?

The profile module does not add an address field, that's all Commerce.

ahaha, thanks for reminding me that... Not sure if the change I added is correct. We also need an update hook.

With the update hook.

This still needs a stable release before it's committed, completely untested though, just blind changes...

Right, no need to commit until until address 2.0 gets an rc1 at least.
In the meantime the community can help test.

I've just committed another long-discussed issue to address 2.x: ✨ Rename the label of AddressField::ORGANIZATION from "Company" to "Organization" Fixed , Commerce would probably want to ship with an alter hook for the profile address field that sets it back to "Company". Assuming that this isn't a step too far which needs to be reverted. Feedback welcome.

address__address_line3

Is missed when creating a store, the SQL asks for it, but its not in the database.
When manually adding the field, the SQL works.

POST /en/store/add/online HTTP/1.1" 500 585 "http://SERVER/en/store/add/online

Uncaught PHP Exception Drupal\\Core\\Entity\\EntityStorageException: "SQLSTATE[42S22]: [Microsoft][ODBC Driver 18 for SQL Server][SQL Server]Invalid column name 'address__address_line3'.: INSERT INTO [commerce_store_field_data] ([store_id], [type], [langcode], [uid], [name], [mail], [default_currency], [timezone], [address__langcode], [address__country_code], [address__administrative_area], [address__locality], [address__dependent_locality], [address__postal_code], [address__sorting_code], [address__address_line1], [address__address_line2], [address__address_line3], [address__organization], [address__given_name], [address__additional_name], [address__family_name], [is_default], [created], [changed], [default_langcode], [prices_include_tax]) OUTPUT (1) VALUES \n(:db_insert0, :db_insert1, :db_insert2, :db_insert3, :db_insert4, :db_insert5, :db_insert6, :db_insert7, :db_insert8, :db_insert9, :db_insert10, :db_insert11, :db_insert12, :db_insert13, :db_insert14, :db_insert15, :db_insert16, :db_insert17, :db_insert18, :db_insert19, :db_insert20, :db_insert21, :db_insert22, :db_insert23, :db_insert24, :db_insert25, :db_insert26)

address_line3 is also used in the payout flow in two places
My quickfix is to add the field address_address_line3 in both tables but it would be nice if someone created a patch for this doing it the right way with adressfield 2.0 etc.

INSERT INTO [profile__address] ([entity_id], [revision_id], [bundle], [delta], [langcode], [address_langcode], [address_country_code], [address_administrative_area], [address_locality], [address_dependent_locality], [address_postal_code], [address_sorting_code], [address_address_line1], [address_address_line2], [address_address_line3], [address_organization], [address_given_name], [address_additional_name], [address_family_name])

INSERT INTO [profile_revision__address] ([entity_id], [revision_id], [bundle], [delta], [langcode], [address_langcode], [address_country_code], [address_administrative_area], [address_locality], [address_dependent_locality], [address_postal_code], [address_sorting_code], [address_address_line1], [address_address_line2], [address_address_line3], [address_organization], [address_given_name], [address_additional_name], [address_family_name])

@arne_hortell
A line3 column is created automatically by an update hook in the Address module. Assuming you did run update.php, you will need to debug why that code didn't work on your site.

Coming back to this... Is there anything else that has to happen from Commerce?

There might be a few other changes to Address for 2.0.0 that "we" (namely, y'all) should at least test carefully and make sure we didn't break anything. 😅

We also need a #process or an #after_build callback to rename organization to Company (as per #13).

@jsacksick
I've made changes to rename "Organization" back to "Company" by adding the "#after_build" callback.

+++ b/commerce.module	(date 1701430453956)
@@ -219,3 +224,11 @@
+function commerce_core_address_after_build(array $element, FormStateInterface $form_state): array {

We never prefix functions by "commerce_core" (commerce is enough).

Also, we need a comment on top of the function.

Perhaps:

#after_build callback for address fields.

Also the patch doesn't apply.

We should do the alter only for address fields belonging to customer profiles, not for all address fields.

This patch changes the "Organization" label to "Company" only for the address field in a Customer profile.

Fix failed patch

Fix failed patch

Fix failed tests

Here is the patch from the MR changes

The alter and the update function only work on the "customer" profile type. What happens if someone uses a different profile type, for example, a separate one for shipping?

We can maybe duplicate the logic in commerce_shipping, worst case scenario a label just changed... It's not really the end of the world :).

Created 📌 Address 2.x adjustments Active for the commerce_shipping tweak needed.

Actually, perhaps we can handle this from Commerce too, by checking the entity bundle info:
\Drupal::service('entity_type.bundle.info')->getBundleInfo('commerce_order');.
Commerce shipping stuffs there the shipping profile type:
$bundles['commerce_order'][$bundle]['shipping_profile_type'] = $shipping_profile_type_id;

So maybe commerce_field_widget_single_element_form_alter() could check that?

Not sure what to do... Because if we account for other profile types in commerce_field_widget_single_element_form_alter(), we may as well do the same in the update function that was added? Or we leave everything up to commerce_shipping...

Moved the after build callback and the alteration to Commerce order which provides the address field. Additionally, the update hook and the field label override applies to all profile types with an address field.

Address 2.0.0. was tagged, committed this. Thanks everyone!!

Automatically closed - issue fixed for 2 weeks with no activity.

@jsacksick

I can't install dev commerce.

https://git.drupalcode.org/project/commerce/-/blob/8.x-2.x/composer.json...

It looks like the composer hasn't updated. Address dependency should have a beta tag as like patch.

>> composer require 'drupal/commerce:2.x-dev@dev' -W

Your requirements could not be resolved to an installable set of packages.

  Problem 1
    - drupal/commerce[dev-2.x, 2.x-dev] require drupal/address ^2.0 -> found drupal/address[dev-2.x, dev-2.0.x, 2.0.0-beta1, ..., 2.x-dev] but these were not loaded, likely because it conflicts with another require.
    - drupal/commerce 2.x-dev is an alias of drupal/commerce dev-2.x and thus requires it to be installed too.
    - Root composer.json requires drupal/commerce 2.x-dev@dev -> satisfiable by drupal/commerce[2.x-dev (alias of dev-2.x)].

You might check to see if your site has any other modules that require Address 8.x-1.x, on one site I had a conflict with the Salesforce module.

composer why-not drupal/address 2.0.0

Thank you, Damien, yes mine conflicts with the SF module too.