Allows to use more mapping keys than the RTBC patch #1616680: Handle more mapping keys in Feeds integration
Is shows all field of the referenced content type, but only the field that have a "value" will work (text, number, etc) so other fields, like like those having a "target_id" as a value, wont work.
Yes, this patch needs some work, but I hope it can help some of you.
Here is a quick view of the possibilities it offers :
| Comment | File | Size | Author |
|---|---|---|---|
| moremappingkeys.png | 38.92 KB | guile2912 | |
| entity-reference-feeds-1.0.patch | 6.61 KB | guile2912 |
Comments
Comment #1
argo27 commentedThis would be very helpful for me.. ive been looking for this
but i still have problem patching...
Would it be asking to much if i ask you to send the patche module..
Ive been trying this for a week now but i always got an error.
Comment #2
tripper54 commentedIs this patch against the latest dev? It fails to apply for me.
Comment #3
giorgio79 commentedComment #5
dman commentedFYI, over in Feeds Tamper: String to ID I have put all the hard work over onto views.module to solve. I saw immediately that trying to build support for each field as a lookup would be busy-work.
* Feeds parser produces a value (eg ISBN)
* I send that as an argument to Views (eg select books with field_isbn equal to arg)
* The views lookup returns me the ids of the entity(es) it refers to.
= bang, the imported feed can establish entityreferences to it
All special-cases are possible (including a million I never thought of) through the power of views, and even the UI is tastier that the one shown here. Well, as long as you like feeds_tamper to begin with.
Comment #5.0
dman commentedadd the image
Comment #6
firfin commentedThis use case is adequately filled by either Feeds Tamper: String to ID or simpler cases might even be solved by feeds tamper built-in EFQ finder.