I am attempting to setup multiple feed imports that are attached to a content type. For example: Feed1 (feed1) and Feed2 (feed2) are attached to the content type Import. I have Feeds Tamper installed and then set the specific tamper settings for each import. The first import works. However, the second import of Feed2 does not work properly. It uses setting from Feed1. When I check the feeds_item table I can see that the id column for Feed2 is set to feed1 for all items.
Is it possible to create separate feed importers that are attached to a single content type but can be configured separately? Or, do I have to create separate content types to be attached to for each separate feed importer?
This seems to be a bug.
Comments
Comment #2
megachrizAttaching multiple importers to one content type isn't feature that is supported at the moment. There is already a feature request open to support this: #1127696: Attach multiple importers to one content type (in D7). Therefore I'm closing this as a duplicate. You can of course also use separate content types for each importer. Or you can use your importer on a standalone form in case you only need to import a single source with it.
Comment #3
Coupon Code Swap commentedThanks for the update MegaChriz. I did notice that the standalone form works in this scenario, but it is not a solution because multiple sources need to be added for each importer. Subscribed to the feature request that you linked to.
Comment #4
Coupon Code Swap commentedHi MegaChriz. Sorry to reopen this issue if it is inappropriate. I looked over the thread for #1127696: Attach multiple importers to one content type (in D7) and applied the latest patch. It seems that what is trying to be accomplished there is a bit different than what I am trying to accomplish. I do not want two or more feed import URL fields when adding a new feed. I only want one URL field. What I am trying to achieve is to attach multiple feed importers that have the same fields to a single content type in a way that the separate feeds settings and feeds tamper settings are respected.
It currently is possible to attach multiple feed importers to a single content type. However, it does not perform as expected in that the feed importer settings for subsequently added feed importers revert back to the first feed importer. This is how I would like to set things up:
Content Type: Import (feed importers attached and stored in this content type)
Content Type: Feed (bundle for node processor)
Feed Importer 1: Feed1 (creates nodes in content type Feed with feed and tamper settings for Feed1 and entries stored with id feed1 in feeds_item table)
Feed Importer 2: Feed2 (creates nodes in content type Feed with feed and tamper settings for Feed2 and entries stored with id feed2 in feeds_item table)
It is very close to working this way as it is now. Options are available to import Feed1 and Feed2, each attached to Feed at /import. However, any feed importers added after Feed1 are not stored with the proper ID when importing, they all get stored with ID feed1 and are processed with the settings for that feed importer. Is there a reason why multiple feed importers cannot be attached to a single content type but have their individual settings applied when running the import? Seems like it would be a simple matter of associating correct feed ID when creating a new feed and storing the relevant feed ID in the feeds_item table.
This is why I think this is a bug, because it can be setup this way, but does not function as expected.
Comment #5
megachrizI think I understand the way you see it: you have configured two importers with the same fetcher and attached them to the same content type, so the source form for both importers are equal. When you go to /import you can select the importer to use there, so you expect that the importer you select there leads to an source form for that importer.
In the actual situation though, links of importers that are attached to a content type lead to node/add/[content type]. This results into the Feeds importer context being lost, because its ID is not given within the URL. A fix then could be to include the ID of the importer on the link that is shown at /import. But what should happen then when you navigate to node/add/[content type] directly? Maybe the importer to use should be a selectable field? But then the form should be refreshed as soon as you select a different importer as the importers could possibly have different settings that should result into different source forms. And this behaviour would conflict with the use case from #1127696: Attach multiple importers to one content type (in D7).
An other thing we could do is display an error message as soon as you try to attach a second importer to a content type that already has an importer. (Though the error message should be removed again when #1127696: Attach multiple importers to one content type (in D7) lands.)
In the D8 version of Feeds this problem does not exists, because there importers are no longer being attached to a content type. Instead you create an entity of type "feed" where the importer is the subtype or "bundle". I believe there was an issue to implement it this way for the D7 version as well, but if I remember well this request was declined because it would break existing sites.
The easiest solution would be to ignore the fact that it is possible to configure multiple importers to a content type right now and just use one importer per content type. In this case this issue would be closed as "won't fix".
Thoughts?
Comment #6
Coupon Code Swap commentedThank you for the excellent explanation, I have better understanding of what is going on and why it is problematic. If all the modules needed for the current project I am working on were D8 ready, I would just go with D8. Probably the best approach is to focus development efforts on D8 version and, if it is easy, for the D7 version disallow attaching new feed importers to a content type which already has a feed importer attached to it and provide an error message on form submit to avoid confusion for users who attempt to configure in this way. If that would be too time consuming to patch, perhaps just an informational message at the top of the Basic settings form (e.g. admin/structure/feeds/1/settings) notifying the user that a new content type must be created for each feed importer. Took me a while to figure out what was going on and why it was not working, hours wasted.
Comment #7
megachrizThanks for your thoughts, Coupon Code Swap. An error message it is.
With the attached patch the following form error is shown when trying to attach an importer to a content type that is already in use by an other importer:
"!importer" is a link to the importer main configuration page.
Comment #9
megachrizHm, the tests attachs an importer by default to a content type. This results into errors when two importers are created in a single test.
The attached patch changes a lot of tests. It is silly to first attach an importer to a content type and then, later on, undo that setting. I tracked down all places in the tests where the importer should not be attached to a content typ. In most cases, but not all, I made sure that the attachment to a content type no longer happens first.
I expect some test failures still. Let's see.
Comment #10
megachrizComment #12
megachrizIn FeedsWebTestCase::createImporterConfiguration() "$edit" was already defined. Let's call the third parameter "$settings" instead.
Comment #13
megachrizRelated issue, but for D6: #856136: Enforce only one importer per content type
Comment #14
megachrizComment #15
megachrizI hope that this will make it into the Feeds 7.x-2.0-beta4 release.
Comment #16
internal commentedIf I want to import to same bundle from different feed URL timely, current workaround it to use standalone form option. Right?
Comment #17
megachriz@internal
No, if you want to import multiple sources for which you want Feeds to create the same type of content for, attach the importer to a content type that is different from the content type that you want to create. See also my answers here to learn more about this:
The issue here is about that two (or more) importers cannot be attached to the same content type. When creating a node, the source field for only one importer shows up. The proposed solution is to disallow attaching more than one importer to the same content type. There is also an other proposed solution in #1127696: Attach multiple importers to one content type (in D7), but that one lacks tests and may also still have issues.
Comment #18
internal commentedThanks. Then how about drush? We can specify the file or url parameter to switch sources, and use the same importer.
Comment #19
bluegeek9 commentedUnfortunately, Drupal 7 is End of Life and no longer supported. We strongly encourage you to upgrade to a supported version of Drupal.