Feeds integration: mapper

Mappers for fields or properties provided by a contrib module, should go in that contrib module, so moving this issue to the Multifield issue queue.

I also need this feature at the moment and will try to create .inc for multifield module.

The main question I see is whether to handle fields through the mapper of the subfields type, or to write own mapper, that will handle fields separately from the default behaviour.

I will dive into this and report back.

I'm also looking for this.

I implemented this part of the way... but I'm getting stuck on the last portion of the import -- saving the mapped data to their respective (sub)field's data columns. Currently, I created a multifield_feeds_mapper module with the feeds.inc file defining targets for every relevant Multifield instance, all of their subfields, and all of the subfield's data columns.

If I understand this correctly, Multifield stores its subfields' values as their respective data columns named by a combination of the subfield name and column name.

I'll refactor this module into a patch for Multifield proper as I think it'd more appropriately reside directly in this module... two secs.

The last part -- I think it's a matter of saving the mapped data column values into Multifield in the presave hook afforded by Feeds. I'll give this a go today as well so I'll hopefully be more informed about how Multifield manages its data and how Feeds can hook into that setup.

Looking for the same. Is there a way of using ordinary fields in the place of multi fields for purposes of data import via feeds? or is there at least any known way of dumping data into a multifields field?

@JamesAn could you provide a patch so we have a base to build from? Don't care if it is complete or if it works. It would be good to post here no matter.

This patch is a start to create this functionality. It requires a patch to feeds (and most likely other related feeds mappers). The idea is simply to loop through and have the other feeds mappers generate the required values.

It is at least a start to the conversation.

It may be nice to create settings that you would apply similar to when a user can set guid to unique or taxonomy. I just didn't get there. These settings could help determine how the values get mapped.

The Patch in #7 was broken somehow, so I have rerolled it. No interdiff because I didn't make any changes to the code in the patch.

This makes the multifield visible as a target for Feeds Mapper UI, but does not let me choose which field inside of the multifield to put data into.

Yes your correct. I did not setup the per field configuration. However it does import the fields in the order they were added to multi-field. I have hard coded separators as well. It was mainly a patch so someone can help pick up the load.

The only multifield issue relating to Rules integration was this one: #2499001: Can't load/edit multifield and subfields in Rules referring back to this thread.

If it is the same issue, will the work in this thread allow multifields to be used in Rules? It would be very useful to loop through multifield values and carry out actions with the subfields.

Hi everyone,

Please note that if you are applying the patch in #12, then the 'row weights' of the subfields of the multifield should begin with 0. I tried applying it but the fields were not getting mapped correctly. After analyzing the code for hours, I realized that the comparison is done with '[widget][weight]' against the '$values' array (& arrays always are indexed from 0).

Hope this helps someone.

P.S. dobe, thanx a lot for this patch! :)

Regards,
Supriya Rajgopal

How should i pass the value in CSV ?

I have a multifield with two subfields one is entity id and the other is select list .

So if i want to pass 1 for entity and 1 for list how it should be correct to CSV.

When i try 1,1 or 1|1 i have the following error:

fatal error: Argument 5 passed to text_feeds_set_target() must be of the type array, none given.

Thanks in advance.

Integration with RULES?
With this patch https://www.drupal.org/files/issues/2041531-23-entity-api-support.patch Multifield is active in Rules but can't loop through multifield values and carry out actions with the subfields.

Thanks

Thanks for the patch. It's a good starting point. Could someone please post an example how the CSV file should look like with multifield values?

Thank you very much in advance!

The patch doesn't work anymore. In the latest version line 117 needs a mapping array as argument:

if(function_exists($function)) {
          $return = $function($source, $fake, $subfield, array($subvalues[$delta]), array());
        }

But even if that is fixed the patch doesn't work anymore because no values seem to be set.

Ok I finally created a working solution. Patch attached. Furthermore I replaced the widget weight solution and replaced it by field counter. I think that's more safe as discussed in #16.

I was hoping to find a Feeds solution to Mutlifield and saw this issue, so I took a look at this patch. It looks kind of reasonable, but it's not going to work for my use case.

The problem is that it's assuming that the data is coming in a string like this:
subfield1,subfield2,subfield3|subfield1,subfield2,subfield3|...

This might be OK if the input is CSV, and I may be able to coerce my parsed-XML input into this format, but I have a problem in that one of the subfields has text that may contain commas. So in this patch the string is first exploded on | and then on commas like this:

+      $subvalues = explode(",", $values);

This is not going to work correctly if some of the values contain commas. Normally in CSV you can escape commas by putting a string in quotes, but this patch doesn't allow for it. So, it's too simplistic to work well for my use case.

Also, if you look at what some of the other *feeds_set_target() methods do in the Feeds module, you'll see that they expect the values to come in already as an array -- probably the CSV reader should be taking care of the separation into an array, not assuming this function in the patch should do it?

Hope that makes sense...

I've recently started using multifield for a project, and as I needed to some major importing, this patch is a great help.

However, it does have some shortcomings, in particular as noted by @jhodgdon, so I've done some work on it.

An updated patch is attached, this does the following:

• I've completely re-worked how cardinality is handled. The correct way to do this in feeds is for the mapper to be passed an array, where each element is one occurrence. If you need to import multiple occurrences in one string, then feeds tamper is your friend - the explode function will split a string into elements on any separator you choose. I've therefore completely removed the parsing of "|", and the input is processed as an array.
• I've also allowed for multiple input items to map to the same multifield, each one adding another occurrence (assuming cardinality is high enough). I needed this specifically because of the way my source CSV files are laid out, but it's a nice feature. If you only map one input to a field then it makes no difference.
• The separator between subfield import items is configurable in the mapper list, defaulting to ",". You're not limited to a single character, it can be a string (as per the PHP explode() function).
• Entity reference imports need to be told how to match the entity, so didn't work properly. This is also configurable in the mapper list, the default is "label", or you can use ID, GUID, or URL (the last two being feeds-specific).

I've imported over 1,000 items now without problem.