Feeds module support

Created a patch for this. Should correctly handle all fields inside of the Address field but did not test each piece of it.

Tested for my use-case on 8.x-1.3:

- country_code
- administrative_area
- locality
- postal_code
- address_line1
- address_line2

Adds targets for:

- langcode
- country_code
- administrative_area
- locality
- dependent_locality
- postal_code
- sorting_code
- address_line1
- address_line2
- organization
- given_name
- additional_name
- family_name

delete this comment. mistake click.

+++ b/src/Feeds/Target/Address.php	(date 1519394693000)
@@ -0,0 +1,75 @@
+  /**
+   * {@inheritdoc}
+   */
+  protected function prepareValue($delta, array &$values) {
+    if (isset($values)) {
+      return $values;
+    }
+    else {
+      throw new EmptyFeedException();
+    }
+  }
+
+  /**
+   * {@inheritdoc}
+   */
+  protected function prepareValues(array $values) {
+    $return = [];
+    foreach ($values as $delta => $columns) {
+      try {
+        $this->prepareValue($delta, $columns);
+        $return[] = $columns;
+      }
+      catch (EmptyFeedException $e) {
+        // Nothing wrong here.
+      }
+      catch (TargetValidationException $e) {
+        // Validation failed.
+        drupal_set_message($e->getMessage(), 'error');
+      }
+    }
+
+    return $return;
+  }

I think that the methods prepareValue() and prepareValues() don't have to be repeated here. These methods could just use the implementation that is already available in FieldTargetBase.
Plus there are some issues with TargetValidationException in Feeds: see #2951965: PHP 5.6: Fatal error during import: FormattableMarkup::__toString() must not throw an exception. Changes regarding that exception could make the Feeds implementation for address field incompatible if the prepareValues() method override is kept here.

Has there been any further work on this patch?

I have the patch applied and can set mapping of fields of address, such as first line, second line and city， and so on. But when I import data from a csv source to different taxonomy term with address, no data imported.

Is there any chance to fix this problem?

Here's the patch that was previously submitted, with the adjustments suggested by @MegaChriz. I'm having trouble with the plugin being discovered, however. @MegaChriz, could you provide any feedback on why this might not be working? It seems to work if this target is used inside the Feeds module, but not in the Address module. At least for me.

@tclark62
In my case the provided patch from #8 did not apply. When putting the file manually in address/src/Feeds/Target/Address.php, the address mapper does show up in my case:

Here is a patch that I generated this way:

git clone --branch 8.x-1.x https://git.drupal.org/project/address.git
cd address
git checkout -b feeds_address_target.2882589.9
git add src/Feeds
git commit -m "Feeds support"
git diff 8.x-1.x > ../address-feeds-address-target-2882589-9.patch

(well actually I'm using a shell script that generates a patch name based on the branch name)

@MegaChriz Do you mind if I ask which versions of both modules are you using? Dev?

@tclark62
I've tested the patch with a fresh install, with all modules (except Feeds) on their latest stable release. For Feeds I used the latest dev (cause I frequently work on that module). I don't think the version of Feeds would matter though: I already got targets provided by other modules showing up at least since Feeds 8.x-1.0-alpha1.

I tested the patch by adding an address field to the content type "article" (thus with the node entity type). I'm not sure if that would matter? In theory, it would not, but I've had experiences in the past where something happened that didn't seem to be logical at first.

Thanks for letting me know. I apologize, it was a complete oddity on my end, I'm sorry! I had multiple sites that had the Address module installed in the root modules directory and in modules/contrib directory due to an oversight of mine. And the one I applied the patch to wasn't the one Drupal was using in both cases...

There are more issues here.
Module address provides "country" and "zone" type of fields.
However these fields are not available for mapping. We need to include these as well.

Let's at least add a handler for the country field.

@Londova, @bojanz
Country (country_code) and zone (administrative_area) are already mappable, but the accepted input for them is limited to their internal 'code'. For countries currently only the two-letter code is accepted, for example "US". When the source would provide "United States" instead, the source would be considered invalid. Same applies for the zone field, which for example needs to be "CA" or "NV" instead of the full zone name.

So the field target's code could be expanded by converting the country and zone names to their respective code. To do this, for the target plugin the following needs to be done:

• The plugin must implement the interface \Drupal\feeds\Plugin\Type\Target\ConfigurableTargetInterface to allow the site builder to specify in which format the countries and zones are provided.
• The method prepareValue() should be overridden to apply the configured conversion to country and zone fields.

I do think this conversion feature is one (very) nice to have, but not strictly a show stopper. What do you think, @bojanz?

@Londova
Oh wait, you were referring to field types "address_country" and "address_zone". Yes, I guess it would be useful to add Feeds target plugins for these two field types as well. They could have the same conversion feature as for the country/zone fields on the field type "address" that I proposed in #16.
Support for these field types could be handled in a follow-up as well in my opinion.

I'm fine with not caring about long-names, codes are fine, I just want to make sure the field type is mappable.

I was able to get the patch in #8 to work by changing the namespace in Address.php
from:
namespace Drupal\address\Feeds\Target;
to:
namespace Drupal\feeds\Feeds\Target;

@derekawalker
Why didn't you take the patch from #9? Also, changing the namespace make no sense. The target plugin should live in the address module and therefore carrying the address namespace. If you have issues with getting the plugin discovered, check if you have accidentally two copies of the address module on your installation. See the last comments on https://drupal.stackexchange.com/questions/276244/custom-feeds-plugin-no...

Thanks for this. Patch #9 worked well for me. I hope you can get this rolled into Address.

Based on #9, I added support for "address_country" mapping. Patch file is attached.

Sorry, wrong patch attached in #22. Correct one is here.

Patch as #23 works perfectly (although the file Address.php was placed in the wrong folder. Once I manually moved it to /src/Feeds/Target/Address.php it worked perfectly). Please commit.

Thanks

F

+++ b/src/Feeds/Target/Address.php
@@ -0,0 +1,45 @@
+ *   field_types = {"address", "address_country"}

We need a separate target plugin for the field type "address_country" because that field type has other properties than the field type "address" has.

See \Drupal\address\Plugin\Field\FieldType\AddressItem::propertyDefinitions() for the properties that the field type "address" has.
See \Drupal\address\Plugin\Field\FieldType\CountryItem::propertyDefinitions() for the properties that the field type "address_country" has.

Explanation for why the field properties need to be listed on the target plugin even though they already known on the field type: for some field types you don't want to provide all properties as mappable (because properties could contain computed information) . In the case of the field types "address" and "address_country" I think it makes sense to provide all properties as mappable.

Thank you! #23 worked for me.

Issue #1
I am in trouble on importing the addresses with "administrative_area" field.
Some errors appear as "field must be blank", while others are "field is not in the right format".
Where I can find the description of the data format for field "administrative_area" for different countries.

Issue #2
If I dissable the "country" in Mapping, no any data will be imported in Address field... (I import the "country" in a separate field).
Is this behavour as intended or it is an error?

If I dissable the "country" in Mapping, no any data will be imported in Address field... (I import the "country" in a separate field).
Is this behavour as intended or it is an error?

An address without a country_code is considered empty, and all of its data is thrown away. It's the only truly required property.

After adding the patch, the same ui screen appear as show by MegaChriz in comment #9.

Do you need to have a CSV file will all 13 subfields?
Can a CSV file been used with only street, postcode and city and of course the country. Do you need to list the country code or the country name? And if the country name, in the source language or English.
The column names in the CSV file, do they need to have specific names. Am I right for example the first source field = Adres : De taalcode
Can then in the CSV file this been source -> "country code" = Adres: De taalcode

Thanks

@Belba
Only the country code property is required to be supplied by the source. The other properties are optional.
The country code needs to be the two-letter country code, not the full name. I assume this is not equal to language codes, as in some countries multiple languages are spoken and some languages are spoken in more than one country.
In #16 I proposed to support country full names as well, but maybe a feature like that should be postponed to a follow-up to make this issue less complex and more likely to get committed/fixed.

@Belba
How you call the column names in the CSV file doesn't matter. Just note that you have to correctly reference them as CSV sources on the Feeds mapping page. The column names are case sensitive in the D8 version of Feeds (they were case insensitive in the D7 version).

patch #23 works for me using the following sub-fields at a csv-import:

• ADDRESS_LINE1
• ADDRESS_LINE2
• ADDRESS_ZIPCODE
• ADDRESS_LOCALITY
• ADDRESS_PROVINCE
• ADDRESS_LOCALITY
• ADDRESS_COUNTRY

I used some DE, GB and EG addresses in the test.
thx.

I was able to use patch #23 with success as well. Thanks!

After installing patch #23, I get a blank page (500) on 'Mapping' and 'Tamper'.
Using 8.x-3.0-alpha5.

Nvm, I had to update some dependencies. That did the trick. Great work!

#23 worked great for me as well, thanks!

I am in trouble on importing addresses with "administrative_area" for country "Russia", getting errors "field is not in the right format".
What is the format for importing "administrative_area" (Russia)? Is there any description? Thanks.

@Londova re: #36 -- I'm not entirely sure, but I think you need to look in the vendor/commerceguys/addressing/resources/subdivision/RU.json file. 'Administrative area' is called 'subdivision' in that vendor library (sort of, long story, not worth complicating this further). The allowed values for the 'administrative area' would be the keys in the 'subdivisions' mapping. E.g. stuff like:

'Altayskiy kray'
'Amurskaya oblast'
...

I think. ;) At least, that's how it works for other countries, so I imagine it would be the same for RU.

Good luck,
-Derek

Thank You, it works. We need to import data from "subdivisions" (I tried for country Italy as well).

The translation ("subdivisions") into English is very poor , I may contribute to a better translattion.
It may be a better idea to setup for importing the data from "iso_code", while the full English name to include in another field (ex. "label"). In such case any translation update of English version (Label) will not affect the previous imported data.

The translation ("subdivisions") into English is very poor , I may contribute to a better translattion.

All data is provided by Google. You can open an issue with suggestions here: https://github.com/google/libaddressinput/issues
Once accepted upstream, the changes are automatically pulled down into the commerceguys/addressing library, and used by this module.

@bojanz : I believe @Londova is talking about the term "Administrative area", not specific subdivision names in Russia or something. I agree, "Administrative area" makes little sense. However, "subdivision" is generic in the upstream library. In the case of a country, the subdivisions are states/provinces/etc. In the case of a state, the "subdivisions" in those JSON files are the pre-defined options for "Locality" (aka "City").

@Londova: I believe the term "Administrative area" is another gift from some upstream Google library. It's not just a "translation", it's deeply baked into the address.module. Changing it now would probably be a huge pain.

Regardless, we're getting totally off topic for this issue which is about adding feeds support. Let's move any further discussion about "translating" the term "administrative area" to another issue.

So, back to the point here, I agree with @MegaChriz from #25 that patch #23 is the wrong approach for supporting both addresses and country fields. Instead of a single plugin that tries to handle both, we should have separate plugins for each field type, so we can handle each one correctly, without a bunch of conditional logic. These plugins are tiny, and basically only exist to map stuff into field properties, so we don't really gain anything by trying to merge them into a single plugin. If anyone cares about this functionality and wants to help get it into address.module, please split the plugin from #23 along the lines of #25.

Thanks!
-Derek

Sorry fellas, I'm lost now on how to deal with the original issue (mainstream, non-edge usecase)
I've got a bunch of addresses to stuff into a new entity via Feeds.
The address field does not show up as a target in the latest stable Feeds.
What do I do?
Patch with #23?
Hack with #25?
Wish I'd learned how to code?
Thanks in advance for any clues...

@boabjohn
Use the patch from #23. #25 is a suggestion to create a separate target plugin for the "address_country" field - because the fields "address" and "address_country" may need to be handled differently.

Hi,
I would very much like to use feeds to migrate addresses from a Drupal 7 contenttype. Which patch do you suggest to use?
Thanks for this work all you!
Greetings, Martijn

Hi, using patch #23 I got the following error:

PHP Fatal error:  Cannot declare class Drupal\address\Feeds\Target\Address, because the name is already in use in /modules/contrib/feeds/src/Feeds/Target/Address.php on line 45

What could be the problem please?

EDIT2 I found the problem
I had to change the first line
from +namespace Drupal\address\Feeds\Target;;
to +namespace Drupal\feeds\Feeds\Target;

Greetings, Martijn

Sounds like feeds module is already defining a source plugin for addresses? Hrm, just checked out a local copy of feeds and I don't see it. Looks like you've got stale patches in your site that added this plugin to feeds itself?

Hi,
I see this guy needed to do the same . I do not already have a source plugin for address. It didn't work without this change.
Thanks for your quick reply.
greetings, Martijn

Same error as #19 and #45 here.
Without the first line change I got this:
Error: Class 'Drupal\feeds\Feeds\Target\Address' not found in Drupal\feeds\Entity\FeedType->getMappingTargets() (line 304 of [cut..]/modules/feeds/src/Entity/FeedType.php)

Why is this issue here and not in Feeds?
Edit : Scratch that.. A light bulb just turned on over my head and now I know why.

For anyone that is encountering the 'field must be blank' error, check the configuration of the address field that you are trying to import into. If a component is set to 'Hidden', you will get the 'field must be blank' error when attempting to populate it via feeds.

#48 dkatena

for php7.0 and the upper version I was able to get the patch to work by changing the namespace in Address.php
from:
namespace Drupal\address\Feeds\Target;
to:
namespace Drupal\feeds\Feeds\Target;

#23 and #45 works for me with D9 and PHP 7.3.

Although this is discussed as an issue with the Address module, patch #23 (with the namespace edit #45) must be applied in the /modules/contrib/feeds folder, and not /modules/contrib/address. That knowledge would have saved me an hour of frustration.

@poker.ca
I'm not sure where that myth came from. Patch in #23 should just be applied to the Address module. Yes, only if you change the namespace in the patch as in #45 - then it should be applied to the Feeds module. But why would you do that?

@MegaChriz, thanks for the clarification.

#24, #45, #51 and #52 all led me to believe #23 should be applied in modules/contrib/feeds...
Glad to know #23 works in modules/contrib/address without any further edits or moving of files.

Next question: how to get this useful feature adopted into the address module?

If understood #15 till #18 correctly, there also needs to be a FeedsTarget plugin for the field types "address_country" and "address_zone" in order for Feeds integration code to be committed to the Address module.

As #51

I was able to get the patch to work by changing the namespace in Address.php
from:
namespace Drupal\address\Feeds\Target;
to:
namespace Drupal\feeds\Feeds\Target;

I believe that #57 is inadvisable. The namespace should be from the module providing the class.

#23 is working as-is.

Hello,
I'm still facing this issue even if I applied #23. Address fields are not showing in the feed mapping list.

Drupal 8.9.16 and Feeds 8.x-3.0-alpha10

Both the content type containing the address field and the feed were already created before applying the patch. Could it be the problem?
Otherwise, what do you suggest to do?

Thank you

@simon.yeung patches provided in this issue should be applied to the Address module, not the Feeds module. If you apply the patch to the Address module, then the namespace change you did is not needed.

Patch at #57 worked for me. #23 needs that small change identified in #53 and #57.

Can it be committed, please?

Great work, thanks to everyone.

@GrahamShepherd
I think that you tried to apply the patch on the Feeds module instead of on the Address module. If you apply the patch to the Address module, then the namespace change is not needed and #23 should work as is.

Many thanks @MegaChriz.

I understand.

Thanks. I removed the incorrect feeds patch and implemented address patch #23.

Worked fine for me.

Confirming #23 works great! Is putting #25 in a follow-up an option?

Took #23 and #45 to work for me. Tried adding patch to address module only and it didn't work.

#23 works on current dev. Import successful. One update should be for the description for "The top-level administrative subdivision of the country" should also mention the two-letter code. In Drupal 7 you could import full subdivision name but can't here.

...
Address (field_address): The two-letter country code
Address (field_address): The top-level administrative subdivision of the country
...

Maybe:
Address (field_address): The country code (two-letter)
Address (field_address): The top-level administrative subdivision code of the country (two-letter)

#23 patch works for me too:

• drupal/address 1.9.0
• US country, city, state and postal code

Thank you all for the patch!

Can we get this patch committed? RTBC +1

As I wrote at the end of #40:

So, back to the point here, I agree with @MegaChriz from #25 that patch #23 is the wrong approach for supporting both addresses and country fields. Instead of a single plugin that tries to handle both, we should have separate plugins for each field type, so we can handle each one correctly, without a bunch of conditional logic. These plugins are tiny, and basically only exist to map stuff into field properties, so we don't really gain anything by trying to merge them into a single plugin. If anyone cares about this functionality and wants to help get it into address.module, please split the plugin from #23 along the lines of #25.

(emphasis added). Given that no one has done so in the last 2 years, I can't imagine if we split this request to a follow-up that it'll ever happen. If #23 works for your needs, go ahead and use the patch. But I'm not going to be committing it upstream, and I hope my co-maintainers agree. Once we commit it, it becomes our problem to maintain, not yours. I'm saying how the code should be written to make it easier to maintain and keep this functionality officially supported. But if no one wants to make it easier to maintain now, I don't see how they're likely to help later. I don't need this feature or care personally, so I'd only commit it upstream if it's not likely to be a source of trouble, bug reports, and maintenance hassles going forward.

Thanks/sorry,
-Derek

@dww, thanks, I will try rewrite code and resubmit patch.

The patch from #2882589-23: Feeds module support split up into two feeds targets.

To make it complete, adding a zone target.

Hi, I just tried to implement #75 in a Drupal 9.3.2 site and I was getting the error:

Error: Class 'Drupal\feeds\Feeds\Target\AddressCountry' not found in Drupal\feeds\Entity\FeedType->getMappingTargets() (line 305 of modules/contrib/feeds/src/Entity/FeedType.php).

To fix this, I had to apply the change from #57 to all three files in the #75 patch.

from:
namespace Drupal\<strong>address</strong>\Feeds\Target;
to
namespace Drupal\<strong>feeds</strong>\Feeds\Target;

Could you double check #75 and consider making this change to the files

@rex.barkdoll
If you apply the patch to the Address module instead of on the Feeds module, then it should work.

Visually, #75 looks great. I don't want to add Feeds as a test dependency for Address, and I don't think we need automated test coverage of this, so all this really needs is some manual testing to confirm it's working for the folks who want it.

HyperNit:

+++ b/src/Feeds/Target/Address.php
@@ -0,0 +1,41 @@
+ * Defines a address field mapper.

Whoops, all these should be "Defines an address ..." I can fix that on commit, but if someone is rerolling this for any other reason and wants to fix the 3 comments, yay.

Thanks,
-Derek

This didn't really seem to need a "reroll" but I did open a fresh MR to help irinaz, and applied the grammar nits while I was at it.

@bradjones1, thanks a lot!

Sorry, @MegaChriz, I was putting the patch in the wrong module. Putting it in address seems to work fine.

We will be testing with CSV file with columns for address 1, address 2, city, state, country, zip. We also could use one of files in Feeds module test https://git.drupalcode.org/project/feeds/-/raw/8.x-3.x/tests/resources/c...

#75 works for me.

Works for me

Works for me

Hallo I patched succefully the module on Drupal 9.3.3, Address 8.x-1.10, Feeds 8.x-3.0-alpha11 but I do not get the Address targets in Feeds, it is a taxonomy feed.
EDIT: seems to be working after clearing the cache several times

Thanks everyone, and sorry for the delays! Gave this a final look. Seems there's been plenty of manual testing, so removing that. Committed to 8.x-1.x branch. This should go out in the next release.

#75 works but is not importing just mapping.

@tatewacky, I suspect that import issues might be happening in feeds module. I will check asap.

Example of mapping

Following this issue. Mapping works, importing not yet. @irinaz have you had the opportunity to check?

Patch #75 works for me using Drupal 9.4.1, Address 8.x-1.10, Feeds 8.x-3.0-beta1 on 1st and 2nd address lines, postal code, city fields for both mapping and importing.
Thanks

Patch #75 works for me using Drupal 9.4.2, Address 8.x-1.10, Feeds 8.x-3.0-beta1 on country field.

Also following this issue - Mapping is working - but not importing, has anyone solved this issue? Drupal 9.4.6, Address 8.x-1.11, Feeds 8.x-3.0-beta2

Confirmed patch #75 is working. Mapping and importing is working. It did not import without a Country code. Drupal 9.4.6, Address 8.x-1.11, Feeds 8.x-3.0-beta2

I will add this issue for testing at BADCamp sprints on Oct 6 - please join is if you can. Any contribution is appreciated!

I have the same problem as 4x3. The fields are mapped but not imported. I'm using Drupal 9.4.8, Address 8.x-1.11, Feeds 8.x-3.0-beta2.
Patch # 75 is of course installed.

I am getting a white screen error after the patch. I'm using Drupal 9.4.8, Address 8.x-1.11, Feeds 8.x-3.0-beta2.

Error: Class "Drupal\feeds\Feeds\Target\Address" not found in Drupal\feeds\Entity\FeedType->getMappingTargets() (line 305 of modules/contrib/feeds/src/Entity/FeedType.php).

@cbwiedel, I believe that patch should be included in release from Aug 2022, so you should not be adding patch.

@Katarzyna_Starzynska. @4x3, @djschoone, I am opening issue https://www.drupal.org/project/feeds/issues/3321312 in feed module.