[4.x]: Customised address fields not taking effect in Addresses::formatAddress()

rob-baker-ar commented 1 year ago

What happened?

Description

Related to https://github.com/craftcms/cms/discussions/11788, the issue here is that customisations applied to address fields for different countries do not take effect in the return value of craft\services\Addresses::formatAddress().

Steps to reproduce

Customise the address field using the events described here https://github.com/craftcms/cms/discussions/11788
Add an address using those fields
Look at the output of craft\services\Addresses::formatAddress() when called with the relevant address.

craft\services\Addresses::formatAddress() is used by the core commerce plugin to show addresses on the order detail screen in the CMS. Note that when choosing to edit the order / address, the expected fields are shown on the edit form.

Expected behavior

The address fields as defined / modified in the events here https://github.com/craftcms/cms/discussions/11788 should take effect when getting a formatted address from the address service.

Actual behavior

The fields defined to be in effect are not shown (i.e. functionality reverts to a state that would occur if there were no events modifying address fields in effect at all.)

Craft CMS version

4.3.7.1

PHP version

8.1

Operating system and version

N/A

Database type and version

MySQL 5.5.5 (mariadb Ver 15.1 Distrib 10.6.7-MariaDB)

Image driver and version

No response

Installed plugins and versions

Asset Rev 7.0.0
CP Field Inspect 1.4.4
Craft Commerce 4.2.5.1
Digital Download 2.2.1
Digital Products 3.2.0
Minify 4.0.0-beta.2
Navigation 2.0.16
PayPal Checkout for Craft Commerce 2.1.1
Redactor 3.0.3
SEOmatic 4.0.19
Stripe for Craft Commerce 3.1.0
Wordsmith 4.2.0

rob-baker-ar commented 1 year ago

It looks like craft\services\Addresses::formatAddress() is used in a couple of places (at time of writing):

When displaying an address in the control panel (craft\helpers\Cp::addressCardHtml())
In the Twig addressFilter filter (craft\web\twig\Extension::getFilters())

brianjhanson commented 1 year ago

Thanks for reaching out! This issue is because the core address format from the underlying library doesn't include the administrativeArea.

Default GB Format

%givenName %familyName
%organization
%addressLine1
%addressLine2
%locality
%postalCode

The good news is you can create a custom formatter and customize the display to whatever you need on the front end of things.

rob-baker-ar commented 1 year ago

@brianjhanson This is good news - thanks for the doc referral.

But, it seems, there is no way to inject a custom formatter for the address displayed as a result of the HTML produced by craft\helpers\Cp::addressCardHtml(). This causes (in this particular case) the order detail screen of the core Commerce plugin to not be able to use a custom formatter. I realise this might be an issue to raise in the Commerce plugin, however:

craft\helpers\Cp::addressCardHtml() already accepts a $config array. It would be pretty easy to have an optional addressFormatter key in that config array - is that possible? That would allow plugins or other code (like Commerce in this case) to display addresses with any custom defined formatter in the CP.

Thinking on, it may also need an event to hook into, something like DEFINE_ADDRESS_FORMATTER, but the above is a step along the way.

brianjhanson commented 1 year ago

@rob-baker-ar can you create a new discussion/feature request for that?

We currently offload the formatting to the Commerceguys Addresssing library, which gets their formatting data from Google. We could potentially add the ability to customize the default format in the CP, but we'd need a bit more interest surrounding it for the effort to be worthwhile.

rob-baker-ar commented 1 year ago

Over here: https://github.com/craftcms/cms/discussions/12673

As mentioned in another related issue, the Commerce Guys library is great for formatting addresses in a commerce context but when an address is used outside of this context, it sometimes confuses users when, for example - the library removes a field it deems unnecessary but our business rules state it should be present.

brianjhanson commented 1 year ago

Thank you! It's worth noting if you really need full control, there's nothing stopping you from creating a custom CP page displaying the data how you need it. I'm guessing that's a bit more work than you were hoping for, but it would be a way around this for your use case. You could also hook into the cp.users.edit.content hook and add a tab with data according to your format.

craftcms / cms