Fix support for Address module v2.0

Merge requested and ready for review. My first merge request was done by accident to the wrong branch. Branch 3367781- is the intended branch.

Hi, the patch works fine. Thank you!

Merge patch works great. New release please!

No sorry! I don't get this issue in the described use case ...
First of all I don't get why you are mentioning the Address Formatter and then pointing to the AdressService Service: those are very different things in Drupal terminology.

But btw ...
I can set an Address Field properties and set required as optional some fields (let's say Country, Address 1 and Locality, and Postal Code),
and there is no kind of error in the AddressService->addressArrayToGeoString method if I omit some of them. It simply generates the consequent Address string with the input values and try to Geocode on the basis of it.
So, for instance, if I just input:
Address 1: Fifth Avenue
Country: United States
it will generate this

$value = [
  'country_code' => 'US',
  'langcode' => NULL,
  'address_line1' => 'Fifth Avenue',
  'locality' => '',
  'administrative_area' => '',
  'postal_code' => '',
  'given_name' => NULL,
  'additional_name' => NULL,
  'family_name' => NULL,
  'organization' => NULL,
  'address_line2' => NULL,
  'sorting_code' => NULL,
  'dependent_locality' => NULL,
]

And then generate the following CommerceGuys\Addressing\Address $address object:

{
   'countryCode' => 'US',
   'administrativeArea' => '',
   'locality' => '',
   'dependentLocality' => NULL,
   'postalCode' => '',
   'sortingCode' => '',
   'addressLine1' => 'Fifth Avenue',
   'addressLine2' => NULL,
   'organization' => '',
   'givenName' => '',
   'additionalName' => '',
   'familyName' => '',
   'locale' => 'und',
}

and finally the following $address_string = "Fifth Avenue US"
and consequently try to Geocode for it ...

Indeed I don't see any of the issue that you reported ... and I am consequently not going to merge this MR, unless you feel to provide more evidence and better explanation of any real general issue on this use case (and not only very specific to kind of your custom implementation).

Geocoder 8.x-4.15
This release killed the functionality on 2 different sites.

Editing any field in the address causes the error below and the WSOD.

TypeError: CommerceGuys\Addressing\Address::withDependentLocality(): Argument #1 ($dependentLocality) must be of type string, null given, called in /home/customer/www/mysite.com/public_html/modules/contrib/geocoder/modules/geocoder_address/src/AddressService.php on line 135 in CommerceGuys\Addressing\Address->withDependentLocality() (line 228 of /home/customer/www/mysite.com/public_html/vendor/commerceguys/addressing/src/Address.php).

Ok ... in doubts it could be related to my PHP version I gave another try to this, and run the last reported use case (so a Geocoding on an Address field with only Country, City and Province fields.) on PHP 8.2 and Drupal v. 10.1.6 and Geocoder 8.x-4.15 ... and all goes very smooth to me.

For instance this Address:
City: Marzabotto
Province: Bologna
Country: Italy

becomes this $value:

array (
  'langcode' => NULL,
  'country_code' => 'IT',
  'administrative_area' => 'BO',
  'locality' => 'Marzabotto',
  'dependent_locality' => NULL,
  'postal_code' => NULL,
  'sorting_code' => NULL,
  'address_line1' => NULL,
  'address_line2' => NULL,
  'organization' => NULL,
  'given_name' => NULL,
  'additional_name' => NULL,
  'family_name' => NULL,
)

in the same AddressService->addressArrayToGeoString method
and is correctly geocoded in the target Geofield wtithout any errors ...

Indeed I still don't see any evidence of a general bug on this and don't feel to merge anything from here, in the 8.x-4.x branch.

Anyway ... I really experience some bugs or issues in his specific Drupal instance is still able to apply the related patch generated by this MR.

I will accept this as Open and general bug only when evidence of a general reproductivity of it will be provided.

OK, found the problem and is not geocoder.

On further examination, I realize that the error message
TypeError: CommerceGuys\Addressing\Address::withDependentLocality(): Argument #1 ($dependentLocality) must be of type string, null given, called in /home/customer/www/mysite.com/public_html/modules/contrib/geocoder/modules/geocoder_address/src/AddressService.php on line 135 in CommerceGuys\Addressing\Address->withDependentLocality() (line 228 of /home/customer/www/mysite.com/public_html/vendor/commerceguys/addressing/src/Address.php).
Is deceiving, I really thought that it was a geocoder issue.

On these sites I had this version of the Address module installed 2.0.0-beta3 released 1 December 2023.

On the site where I had this error message

TypeError: CommerceGuys\Addressing\Address::withPostalCode(): Argument #1 ($postalCode) must be of type string, null given, called in /home/customer/www/myothersite.ca/public_html/modules/contrib/geocoder/modules/geocoder_address/src/AddressService.php on line 133 in CommerceGuys\Addressing\Address->withPostalCode() (line 247 of /home/customer/www/myothersite.ca/public_html/vendor/commerceguys/addressing/src/Address.php).

I rolled address back to Address 8.x-1.12 released 21 May 2023
The error went away, no problem.

So, it seems that my specific problem is with this Address 2.0.0-beta3 released 1 December 2023.

Sorry for the noise and thanks for your time.

You can't pass NULL to a method expecting a string.

The reason why not everyone is seeing the same error is because typehints were added in Address 2.x and commerceguys/addressing 2.x, so only people using the latest code get the crash.

So, AddressService needs some $value ?? '' love.

Thanks

thanks @bojanz ... this finally makes more sense to me
Added as reference the Address module issue ...
Going to run a final review and merge this MR asap, and deploy a new release.

Thanks everybody for the great contribution (and for pushing me) here.
MR merged in both 3.x and 4.x branch, all will be part of next Geocoder releases.

I look forward to this release and can help test.

Thanks @dadderley ... new Geocoder releases deployed.
But everything already tested before of it, in this MR ...
(Review and test/qa should happen before the new release deploy, but feel free to double check all working fine on this side now).

Looking good so far.

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