Inherit properties from parent feed node (taxonomy, author, OG, language)

I am also facing this issue and was just going to open an issue on this.

Taxonomy is working right now. Format "Feed node: Taxonomy: Stock Ticker" - replace "Stock Ticker" with whatever your vocabulary name is. With some importer styles (ex. CSV) you cannot see the possible "Sources," so switch to "Common syndication parser" to be able to see all the available "Sources" in the mappings.

Node reference #988856: Feeds mapper for node_reference and user_reference fields does not currently work though, which seems to point to a need to fix this issue #908870: Inherit properties from parent feed node (CCK fields)

Subscribing - in particular to inherit the author. Is there any workaround in the meantime for 7.x?

Hi,

Here's a patch against the latest 7.x-2.x development version of the feeds module. This patch allows the nodes that are created to inherit author and language settings from the parent feed node. It doesn't do taxonomy or OG membership, which I don't think I need for my current project.

-Ian

Subscribe

@ Ian

How hard would it be To add OG audience and taxonomy for nodes imported with feeds?

Would I simply copy your lines of code for author/language and replace with OG and taxonomy?

Also, if you're interested to have fixed language for new entities, you might check out #1247536: Allow users to choose node import language patch in comment #5.

subscribing

Hi,

I am very interested in the evolution of the patch in # 4 that supports taxonomy. Unfortunately, my level of development is not enough to do it alone.
Who can make this change or put me on the way of work to do?

NicoB

I've made some changes from the patch in #4 that should allow selectively inheriting fields from the feeds node.

@Hurukan yes, common fields between the feeds node and target node type can be inherited.

Just tested on the latest release and this patch still work like a charm; can we please see this committed? It's a must for multilingual sites.

Will these patches also import the Organic Group Audience ?

Yes, they would appear to.

I am also interested in the ability to inherit the OG audience. The only items I see available to inherit with the patch in #10 are properties, not fields.

kclarkson, if you are still needing this functionality I actually just figured out how to get what I need within views. I have a block on a group page that displays all feed items relative to feeds.

- My content type for feeds and feed item are both set as a group content type
- I create a "feed" a select my group audience
- Feed items are imported. (feed items do not however have an audience set)

My view

- Working from the "feeds_defaults_feed_items" view included with the Feeds module
- Add a block display
- Add a relationship "Group membership: Node group membership"
- Set the relationship of this to "Owner Feed" (this relationship should already exist)
- Add a contextual filter "OG membership: Group gid"
- Set its relationship to "group membership" (should auto fill)
- Provide default argument "Current OG from context"
- Add fields as desired (e.g. content: title, content: post date, etc)

With this set up I am able to get what I need without the inherit properties patch

@sylense

Thanks for this write up. I will give it a try and report back

I used this patch myself--- works great, exportable by features. perfect.

I have issues with this patch:

• The values should be provided on the mapping page, not directly. Benefits:
  • Not node specific.
  • Field names don't have to be identical.
  • Will benefit things like relationships.
• The only real problem I see with this is, as noted in #2, getting access to these properties is non-obvious for things like the CSV Parser.

We could provide a separate mapping table for inheritance, or we could add the necessary machine-names to the legend so that people would know what to put in there.

Yeah, ideally anything here that can't be currently provided by mapping should be added to mapping; and additional feed node fields would be chief among those things. I don't like this patch as a long term solution but for right now I love using it to tide me over until better options are available.

/Robin

In 7.x it seems the method for mapping from parent feed node -> item is working for taxonomy (the details live in the mapper/taxonomy.inc) and User UID (the details live in plugins/FeedsParser.inc).

On this logic I've quickly knocked together a language patch. I have a nasty feeling I might have done this before, but maybe I didn't post it, so this time I'm publishing immediately without tests etc. just for follow-up.

I think og would be a little more complicated. It'll probably want to look like the taxonomy example more. For fixing in the importer, I'd say the easiest is to have node importers.

Although having a language mapping like that is nice; there are other bugs that would make it somewhat awkward to deal with right now. #1232836: Use proper language instead of 'und'. being the major one (thanks to how feeds works now; imported nodes would end up with their bodies not editable since the language of the body field is set to und rather than the language of the node).

In any case, I like this approach; so keep at it bearing in mind other issues around languages when testing new mappings.

This would be a great way to categorise items generated by feeds - add a taxonomy term to the feed and it will propagate to the feed items. Applying #4 and #10 works really well for taxonomy fields, properties.
This patch allows Feeds to be a true successor of Aggregator. The previous aggregator module allowed each feed to be categorised. The current Feeds module does not allow this functionality. I would love to see this functionality go in to the main module, even without the language element of it if this is not perfect - for the majority of sites the Language is not an issue.

Flagging this for review as there has been no activity on this thread since June. Please consider including this despite the flaws in the language part of it - don't throw the baby out with the bathwater!

Hi,
After a lot of searching, and coming from the D6 thread on this issue, it would be really great to have the parent language functionality working, as work arounds look quite tricky.
Including it would provide some solutions as opposed to being able do nothing at all.
Thanks.

The patch described in #10 works perfectly functionally. However, the patch cannot be applied directly; I think this is due to newer versions of Feeds. After manually adding two lines, everything works fine.

Just one addition: if you add a field in a content type, this field shows up once you have saved the settings of the node processor.

Same as the patch from #23 except that this one was created against 7.x-2.0-alpha7.

Attaching the patch in comment #10 rerolled against 7.x-1.0-alpha7.

I've reattached @ Jeffrey C's patch, only re-naming it for 7.x-2.0-alpha7.

It cleanly applied against my latest dev, the "1.0" appears to have been a typo.

Yep. Thanks.

I've applied the patch from #32 to the alpha8 version, and even though the terminal doesn't show me any failures, the form element that allows for choosing a field to inherit doesn't show up when creating and saving a new importer (of for existing importers).

I tested it on alpha7, that seems to work fine.

Is someone able to get this great functionality working in a patch for alpha8 so that it can be part of the first beta?

I wish I was competent enough as a programmer to do so - this really is an important feature of feeds, enabling both mapping of content from the feed source and from the parent node without having to use feeds_tamper to set all nodes created by that importer.

Pretty please!

First attempt at applying to alpha8

Oops, second attempt

Previous patch broke the interface. This fixes.

I tested #40 against the latest dev. The default node options such as language and status seem to become available for inheritance, but taxonomy fields do not.

Doh! Nevermind, forgot to add the field to the "to be imported" node type.

Seems to work great! Thanks!!!!

See #21.

Patch in #40 covers the common use case (parent feed node field -> child feed item field) - very simply.

As I recall the flexibility of mapping field -> field was complex; are there that many cases where the field names from parent feed node -> feed item node need to have different fields?

Not using Feeds for CSV import, what is the nature of the difference for parent node field value inheritance? The fields available in the CSV don't seem to matter, as this is just cloning values to the child feed item node to be add with whatever other field values from CSV?

After 8 hours of trying to accomplish this I finally found this patch. THANK YOU.

PLEASE GET THIS IN CORE!

@ngreenup
If you'd like to see this added to Feeds, please help improve the patch by fixing the issues noted in #21.

I submitted it to another retest because it failed for me on the latest DEV, specifically on the plugins/FeedsNodeProcessor.inc file. I'll look at the patch in more detail tomorrow to see if I can fix the error.

I also notice that this patch doesn't work for the Organic Group Audience assigned to the Feed Node.

EDIT**
Nevermind, I didn't see the added field on the Node Settings configuration, I was looking in the Field Mapping trying to find the og_audience in the feed node source.

Thanks!

Reroll

The field is not accessible. I think there is a CSS issue. .

can entityreferences be added? If i add an entity reference to an importer, I would like it to be copied to every feed item.

Differences compared with the previous patches:
- different variable names and descriptions.
- Inherited properties should be set on node update not just on node create, that is why I chose to override the FeedsProcessor::map() method.

My cents about how I image a better solution for this feature request:

My patch and the previous ones try to solve in the easy way, but I think this could be implemented in a much better way. Unfortunately this ideal implementation probably require some API changes as well. In my opinion, the best solution for this would allow a user to map feed node's properties (as sources) to different target properties on this UI component.

I think this solution requires to replace the implementation of FeedsParser:getMappingSource() with sth similar to FeedsProcessor:getHookTargets(), which allows modules to dynamically expose targets, therefore a user could see similar options in "Select a source" field than on the "Select a target" fields. If we would like to go with this implementation, then it might be useful to depend on entity.module somehow and leverage information returned by entity_get_property_info() (getter and setter callback, etc).

This was the short version of my idea about how this feature request's ideal solution should work.

@mxr576
I think your proposal is more or less the same as the proposal from #21.

By the way, there is already a hook available to add extra sources: hook_feeds_parser_sources_alter(). See my example from #2840767: How can an entityreference on the feed importer node (not feed item) be inherited? for how this could work for an entityreference field.

Feeds Entity can ship the proposed solution that I've described in #54, so it not just allows to inherit properties from the source node, but it also allows to map inherited properties to different destination targets.

I think this issue can be closed if all you agree with me.

looks ideal but I haven't tried it

Tried the patch from #54 and I can select the field from the parent node that I need when I configure the new setting this patch introduces. However, the (text)field I selected does not show up as a possible source.