I can assign more than one feed to a content type by setting the 'Attach to content type:' to the same content type for two different feeds. However, when I go to create my node, I only see one textfield to enter in the feed URL. I should see two.

My use case: I'm using the project.module to detail projects that I maintain on Drupal.org and I want to attach a few feeds to the node. The CVS commit history, release history, issue queue etc. So, when I go to create a new project node I should see textfields for each associated feed, allowing me to associate all the feeds with the project (I'm using the data storage backend).

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

alex_b’s picture

This problem needs to be addressed. It also occurs e. g. when you're copying an importer configuration. The configuration just keeps being attached to the same content type.

mrfelton’s picture

@alex_b: Are you suggesting that it should not allow you to attach more than one feed to a node? I hope not, as that is exactly what I want to be able to do!

mrfelton’s picture

Status: Active » Needs review
FileSize
7.25 KB

Attached is a patch that allows multiple feeds to be associated with a single content type. The permissions stuff could probably do with a little work, as currently permission to import a single feed associated with a node allows all feeds associated with that node to be imported.

Thoughts?

mcaudy’s picture

subscribing

Renee S’s picture

Worked for me!

mrfelton’s picture

Oh yeah, works... another problem with it though. The feed textfields on the node create/edit form are not labelled, so you have to guess which one applies to which feed for now!

alex_b’s picture

Title: Can attach more than one feed to a content type, but only one feed functions. » Attach multiple importers to one content type

I'm warming up to this. Need to have a better look though.

mrfelton’s picture

great! I'd love to see this, or some variation on this get committed. It's working really well for me, save the couple of issues I have already outlined in this thread.

funkmasterjones’s picture

Not to make the problem bigger but...

isn't this really 2 separate issues

FEATURE: choice of importers for a single content type
SOLUTION: add select box beside URL field in feed node to select what importer to use
Pros: easy logical interface, allows easy changing of importers, doesn't bog down ui if there are many importers
Cons: only 1 feed per feed node

FEATURE: allow mulitple feeds for a single feed node
SOLUTION: (along with above feature) add a button to add a new feed to the feed list in the feed node
Pros: multiple feeds from SAME or DIFFERENT importers
Cons: may need to change some core code, writing code for dynamic UIs is yucky!

I believe this the most elegant and flexible approach.
- mrfeltons problem of project history (multiple importers) is solved
- can create a "Yahoo News" node where multiple feeds (National, World, Politics, ....) using the same importer can be aggregated under 1 feed node

Thoughts?

cwaring’s picture

I would be interested In this functionality, to me It's very logical grouping feed importers under a single content type. Especially for aggregation purposes, also it's easier to explain to my site administrators as they have a consistent approach to set-up new feeds.

Has any decision/progress been made here?

hbu’s picture

count me in into interested folks.

hbu’s picture

the patch from #3 doesn't match with the latest releases.

alex_b’s picture

Status: Needs review » Needs work

Needs work (#12)

Echoing #9's analysis I am also not sure whether the patch #3 will address the use case described initially. mrfelton: Looking at your use case, it's almost like you'd like to attach multiple feed subscriptions to a node - not multiple importers, correct?

The patch in #3 handles multiple importers on a feed. This is in itself only consequential from what is found in Feeds atm - Feeds allows us to attach multiple importers to a content type but then doesn't handle it. This doesn't make much sense use case wise in my mind, but it's a solid way of dealing with collisions between importers (not straightforward as importers can be exported to code and merely enabling one can cause a collision).

Now as for attaching multiple feed subscriptions to a node, I am very much in favor of NOT allowing that and instead using node references or similar approaches to relate multiple subscriptions (represented each by a feed node) to another entity (a project node in mrfelton's example).

Drupal 7's field API may sway my opinion though.

So now, what's actionable?

- I'd accept a patch that allows multiple importers per feed node (much along the lines of #3).
- I'd love to table a multiple feed subscriptions per node discussion at least to Drupal 7.

Thoughts?

mrfelton’s picture

alex_b: Myintent was to be able to attach multiple feeds to a single node - which my patch allowed me to do. I will admit that when I wrote the patch (and now also) I really had/have no idea about the internals of the feeds module - I just needed to get the job done and it seems pretty easy (and seemed to make sense) to allow multiple importers to be associated with a single content type - so that is what I did.

In fact, thinking about it - I think they did need to be different importers, since each of the feeds had a completely different structure, different data table, with different views integration requirements.

Your idea of using nodereference fields to link multiple single feed nodes to another node is sound, and would probably allow me to achieve the same thing that my original patch allowed me to do - though in a slightly more round about way. But, even so, I still think it would would be desirable, and better in many ways to be able to attach multiple feeds to a single node - and ideally these feeds should be able to come from independent sources. I can have multiple filefields, multiple nodereference fields - why not multiple fields?! I know - feeds are not CCK fields (perhaps they should be?!)

alex_b’s picture

feeds are not CCK fields (perhaps they should be?!)

Yeah, I'm warming up to this approach. BUT: not in D6, as it locks us into nodes, right now, I have two running sites where I attach importers to users. Hence, I'd love to revisit this issue for D7.

Related: #702734: Rename FeedsSource->feed_nid to FeedsSource->sid and FeedsImporter->id to FeedsImporter->name

smithmilner’s picture

Any possibly of #3's patch getting done for Feeds 6.x-1.0-beta1, I've been trying myself getting my butt whooped.

patcon’s picture

Just wanted to say thanks to alex for being so open about this! Another maintainer might easily have been more close-minded

To give an example of use-cases where this would help:
I use feeds as a data importer to populate simple database tables from CSV files. I need to upload 2 separate files to each node (school_results.csv and student_results.csv). Each file populates an appropriate table with annual data. Having the ability to attach multiple feeds to a node is, for me, the equivalent of allowing two different filefields for getting data into the system.

Given that Feeds is working more and more as a data import tool, I suspect others will have very similar needs :)

dhcole’s picture

Here's another use-case I just ran into, FWIW.

I have an xml file with multiple elements (cities, states, counties, etc). Each element has a subelement with the id of the larger element to which it belongs:

<city id="1">
  <name>Trenton</name>
  <state_id>3</state_id>
</city>
<state id="3">
  <name>New Jersey</name>
</state>

I'd like to get the data from each element into a table (e.g. table of all of the states, table of all of the cities, etc). I was thinking I could make a feed importer for each element, using the data processor, so a table is created for element, and attach both the "city" and "state" feed importers to the same content type, called something generic like data feed. However, I just end up with the fields for one of the feed importers, not both.

brycesenz’s picture

subscribing. I would love this functionality.

patcon’s picture

I need it for next week, so I'm going to take a stab at updating this. I'll post it afterwards, even if I haven't had time to clean it up :)

NicolasH’s picture

subscribe

mErilainen’s picture

+1 for this
I want also to bring different feeds to Fast feed content type, but I need to configure different importers depending on the feed's content.

sime’s picture

subscribe

trueheehoo’s picture

+1 for this

netw3rker’s picture

+1 for needing this. I can think of numerous examples where this would be important. Think of a sports team site where various information is broken down into a variety of feeds related to a team like so:

feed 1: all teams
feed 2: all players (by team)
feed 3: all games (by team)

it would make a lot of sense to create a feed that imports teams, and 2 feeds that attach to team nodes and import their respective data for just that team.

This was critical for a project I'm working on, so I got it running. Try the below patch and let me know if it helps. Also it does introduce one new feature to the FeedsProcessor class: a "weight" field. this is used to help users ensure that one feed runs before another feed, which is quite possible.

Hope this helps!
-Chris

PS: this is my first patch using Git, so i'm not 100% sure it'll work as advertised.

patcon’s picture

Thanks netw3rker! I personally fell through on this when I found a way around needing it, but I'll try to give this a shot for testing in the next week

Again, thanks!

johnv’s picture

subscribe.

Renee S’s picture

Which version does this get applied to? It didn't go on cleanly for me, but I think it's just some small differences.

netw3rker’s picture

@reinette, This should apply to the beta 10 release. I did some work for some other issues with feeds, so the patch might be slightly off from the current version too, but only by a tiny bit.

-Chris

Agileware’s picture

Argh!

retolist’s picture

subscribe

johnv’s picture

@netw3rker, your patch#25 is very different from mrfelton's patch#3. Is the result the same, or is your goal a different one.

Crossposting: issue #1047894: Behavior when fields/columns are not in import file: do not clear field, but leave field untouched. might be an alternative for simple cases of this issue: Create 1 importer, and Create 3 files/feeds with only a subset of the mapped fields. ATM this doesn't work, since non-existent columns are cleared in FeedsProcessor.inc.
EDIT: You can now find the patch in the issue.

netw3rker’s picture

The approach is different but as far as i can tell, the same result. the primary goal was to allow 2 feeds to be attached to the same content type/node and processed sequentially based on a weight given to it.

-Chris

johnv’s picture

@netw3rker, I'd love to use the weights, if only for keeping the list of importers better organized.
Since your patch contains 2 objectives, would you mind splitting the patch in 2, and posting the weights again in another issue?
Then both parts can be addressed/fixed separately. I am reluctant to use the other part of the patch, to avoid later upgrade issues with this issue.

netw3rker’s picture

i can, though i think they are part of the same objective. without weights, you essentially wind up with a race condition between multiple feeds attached to a node. that becomes a problem when the first feed imports referential data that the 2nd feed needs.

At any rate, I'll part that out over the weekend for you.
-Chris

blackdog’s picture

So, just to understand:

If I need to create two importers (for different mappers, or different content types to create), I can't use the same Content type (Feed) to create them?

johnv’s picture

Correct. If you create two importers, Feeds maintains two lists of GUIDs. So, if you try to import/amend the same entity with each of the importers, you end up with 2 entities in Drupal.

XiaN Vizjereij’s picture

Subscribing

johnv’s picture

Version: 6.x-1.x-dev » 7.x-2.x-dev

I just encountered http://drupal.org/project/feeds_node_multisource. (for Drupal 6)
Sounds like the same approach as netw3rker's #25/#33 .
For the record: I'm working on D7-projects.

johnv’s picture

@netw3rker, I tried to port your patch to D7 feeds, but changes are too big... If you ever have a D7-version at hand, I'd be happy to test it.

milesw’s picture

Version: 7.x-2.x-dev » 6.x-1.x-dev

@johnv
Just because you're working on D7 doesn't mean you should change the issue version. :)

mrfelton’s picture

Status: Needs work » Needs review
FileSize
16.07 KB

Here is an updated version of the patch against last 6.x-1.x code in git. Same as before, but includes the weight field as per netw3rker's patch. It also sets the title of each of the feed feelds on the node form to the title of the feed, so that you can tell which textfield is for which feed.

mrfelton’s picture

There was a problem with the previous patch. Please use this one instead.

7wonders’s picture

just an fyi - i have opened a feature request for this for d7 - http://drupal.org/node/1127696

johnv’s picture

The following project (only D6 right now) seems to do the very thing. Am I right?
http://drupal.org/project/feeds_node_multisource

milesw’s picture

@johnv: Nah, they're different, but I can certainly understand the confusion. :)

Feeds Multisource is about having multiple feeds affecting the same set of nodes.

This issue is about having multiple importers attached to the same source (url, file, etc.).

johnv’s picture

Title: Attach multiple importers to one content type » Attach multiple importers to one content type (in D6)

Changing title to differ between #634462 and #1127696.

EthanT’s picture

Has anyone had any trouble with this patch and the xpathparser module? I've applied the patch in #45 to various versions of feeds 6, and I'm getting these errors everytime I try to import feed content:

warning: array_keys() [function.array-keys]: The first argument should be an array in /home/allstarf/public_html/sites/all/modules/feeds_xpathparser/FeedsXPathParser.inc on line 30.
warning: array_filter() [function.array-filter]: The first argument should be an array in /home/allstarf/public_html/sites/all/modules/feeds_xpathparser/FeedsXPathParser.inc on line 50.

mrfelton’s picture

Here is a version of the patch that applies cleanly against the latest code in git.

What are we waiting for to get this patch committed? It's getting a little tiresome having to keep regenerating the patch so that I can build my platforms successfully.

mrfelton’s picture

And here is one that drush make can actually apply. I don't know why the previous one didn't work. It apples with git apply, but drush seems to want to use patch -p0 to apply it instead. This one works when using patch -p0

Status: Needs review » Needs work

The last submitted patch, 634462-feeds-multiple-feeds-per-node.patch, failed testing.

XiaN Vizjereij’s picture

Status: Needs work » Needs review

What is holding that back?

anonymous07’s picture

subscribe

leewoodman’s picture

Version: 6.x-1.x-dev » 7.x-2.x-dev

subscribe

Les Lim’s picture

Version: 7.x-2.x-dev » 6.x-1.x-dev

Reverting version.

Issue for Drupal 7 is here: #1127696: Attach multiple importers to one content type (in D7)

Also note that "subscribe" posts are no longer necessary. Use the "Follow" button at the top of the post.

asb’s picture

Running the patch from #49 against feeds-6.x-1.0-beta11:

# git apply 634462-feeds-multiple-feeds-per-node.patch 
error: patch failed: feeds.module:239
error: feeds.module: patch does not apply

Running the patch from #49 against feeds-6.x-1.x-dev:

# git apply 634462-feeds-multiple-feeds-per-node.patch 
error: patch failed: feeds.module:239
error: feeds.module: patch does not apply

Has anyone had success to apply the patch recently???

asb’s picture

Priority: Normal » Major
Status: Needs review » Needs work
twistor’s picture

Issue summary: View changes
Status: Needs work » Closed (outdated)