Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Address field in Drupal 8 #206

Open
miiimooo opened this issue Apr 5, 2019 · 2 comments
Open

Address field in Drupal 8 #206

miiimooo opened this issue Apr 5, 2019 · 2 comments

Comments

@miiimooo
Copy link

miiimooo commented Apr 5, 2019

I'm trying to create a profile entity with an address field like this:

    $this->parseEntityFields('profile', $profile);
    $saved = $this->getDriver()->createEntity('profile', $profile);

And the address field in my feature looks like this:

country: SE - locality: Stockholm - postal_code: 411 16 - thoroughfare: Maria Bangata 4a - given_name: Fridolin - last_name: Hase 

But since upgrading and now using the AddressHandler it breaks with:

Notice: Undefined index: field_overrides in /app/vendor/drupal/drupal-driver/src/Drupal/Driver/Fields/Drupal8/AddressHandler.php line 15

I get another issue when I copy and paste the example in https://github.com/jhedstrom/drupalextension/blob/master/features/field_handlers.feature#L16

Notice: Undefined offset: 0 in /app/vendor/drupal/drupal-driver/src/Drupal/Driver/Fields/Drupal8/AddressHandler.php line 54

Address is v1.4.0 and (v1.6)
Drupal extension v4.0.0beta2

Looking at the source there seems to be a custom address field type just for the tests.

@chrisolof
Copy link

I also hit this issue after upgrading from v1.4.0 => v2.1.1. I had been setting the sub-fields by way of:

| field_a:country_code | field_a:address_line1 | field_a:locality | field_a:administrative_area | field_a:postal_code |

Which, in v2.1.1, produced:

Notice: Undefined offset: 0 in /vendor/drupal/drupal-driver/src/Drupal/Driver/Fields/Drupal8/AddressHandler.php line 54

Looking at the code in AddressHandler.php, it looked like an adjustment from string keys to numeric keys might work, but at the expense of readability/maintainability down the line.

I instead opted for @mdolnik-eelzee's patch in #236, which seems to work well.

@BramDriesen
Copy link

The pull request #240 is the correct way of solving this as discussed in #236

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants