Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.How do you like the idea of dropping per-feed settings and using only the content-type settings?
The current situation can be really confusing for the users.
Do you think it would be bad if you can only alter the content-type settings and not the per-feed settings?
I really need feedback from the users here :)
| Comment | File | Size | Author |
|---|---|---|---|
| #8 | feedapi_remove_per_feed.patch | 17.05 KB | aron novak |
Comments
Comment #1
PeterZ commentedFor me, I'm looking for the idea of doing per-feed publishing. Some feeds are good and I want to autopublish everything. Others are not as good so I don't want to autopublish their items. Either way, I'll review all to confirm, but maybe 12 hours later. But at least I can balance freshness and good/bad content. Right now I think I need to do this with Rules and a SQL query in the PHP if I set default publish settings at the feed level.
Comment #2
aron novakI think your use-case won't hurt if the per-feed configuration of parsers and processors dropped, right? As I see your problem is around how to publish the content. This seems to be a different issue.
Comment #3
jmiccolis commentedHey Aron,
I'd love to simplify the node form and move the parser and processor setting to the content type settings. This idea gets my vote.
Comment #4
ekes commentedI'd love to get rid of a whole load of the per feedapi node configuration options - I tend to hide them from the user anyway. But to emphasize what I understand PeterZ's use case what I'm going to have to look at next is a simple two check box addition to the form:
* Trust HTML on feed items from this feed;
* Trust feed items in this feed not to need moderation.
This is presently best done with a custom add-on feedapi processor though - having tried to do it with the pre-feed setting so far - it's just too confusing: http://drupal.org/node/248912
Comment #5
yhahn commented+1 from me -- this should make the UI much less confusing for users.
Comment #6
Alpha42 commentedI can't speak for anyone else, but if I'm interpreting this correctly, then this is something that (for me atleast) is a must have.
Lets hypothetically say I have one content-type "news", and I'm aggregating "news" from a multitude of sites... my processor (which I'm still working on) is going to need different option settings for each feed depending on the content of the feed and how I need to process them. (Maybe site #1 I want to use their full text feed, but site #2 I want to trim down to ### words or less, my processor has an option "Limit to X words"... so for one feed I leave it blank, but another I might put in "90", and the processor handles that accordingly).
If the per-feed options go away, instead of having one content-type of "news", I'm going to end up with "news-site1", "news-site2", "news-site8492"... a new content-type for every feed that needs different settings? that could get ugly?
Or am I misunderstanding the entire processor method or this issue?
Comment #7
aron novakAlpha42: your use case makes sense. But only because of trimimg down the node length, you don't really need to use FeedAPI. It can be done via nodeapi elegantly. And in this case the lack of per-content-type settings for processors won't affect you anymore.
Comment #8
aron novakHere is a patch.
It works totally fine, except the simpletest has some minor fails. (but i think the tests should be updated)
Comment #9
aron novakIt should be considered for FeedAPI 1.9, needs discussion.
Comment #10
aron novak#201056: Only save per-node settings if different from per-content-type settings or this
Comment #11
aron novakIt won't get into 1.9, too extreme change.
If it would be committed, a new branch should be started.
Comment #12
alex_b commentedI'd even postpone this.