Closed (fixed)
Project:
FeedAPI
Version:
6.x-1.7-beta1
Component:
Code feedapi (core module)
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
14 Apr 2008 at 19:42 UTC
Updated:
23 Jun 2009 at 15:50 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
Anonymous (not verified) commentedHere's a patch for D6. It's not so complicated is it?
perhaps feedapi should expose triggers to do this kinds of messin' around? or would it be right to rely on existing triggers for nodes?
Comment #2
Anonymous (not verified) commentedComment #3
mustafau commentedUpdated patch. No functional changes.
Do we need an update function for this.
Comment #4
chantra commentedWell, I have yet anoter patch which will the the behaviour as is + add a new secial value:
if promote is_numeric and promote < 0
then set all non promoted items for this feed to promoted.
To be honest, in my use case, I want to promote every items. Or at least leave them as set by my default story/page workflow settings.
I was surprised to see that the behaviour is:
if N > 0: amongst the last N, promote the ones that are not yet.
if N == 0: demote all promoted.
To me 0 would mean do nothing, leave as is.
I am new o this module so I might get it wrong.
Anyow, find attached a patch that will enable the value -1 (actually anything < 0) to promote every items from a feed which is not yet promoted.
Comment #5
Anonymous (not verified) commentedI think the vagaries of this feature and the limitations of "promote to front page" mean that this option should be completely removed.
Normal functioning of a site that depends on "promote to front page" allows all kinds of content types to have piles and piles of nodes that are promoted to front page. The front page is limited to 10 items (or whatever is set in the post settings admin screen). If there are more than 10 items, you get a pager.
If people need something more complicated than this, they should be using Views to control how the front page is constructed.
Comment #6
nick.dap commented+1
On removing this "feature". I just had a hell of a time chasing it down on our production server. All our items were demoted since the setting was set to 0 for all our feeds. Every cron we had our front page essentially wiped out.
I think it has no place in this module. Views and the normal Drupal methods are there for this functionality.
Comment #7
aron novakI know that FeedAPI users cursed the maintainer because of this totally obscure, finally I removed it :)
Comment #8
Anonymous (not verified) commentedNah, we never cursed you. (And I would never!) Thanks!
Comment #9
nick.dap commentedThanks Aron!
Much appreciated. No cursing here, its all part of the feedback loop. ;-P
Comment #11
dunlop commentedSeems like the current workflowpromotion behaviour is a bit wonky, perhaps not a full bug but a serious side effect of the removal of the promotion settings.
I found that the promoted settings for the feed items are inherited from the node type of the feed item and not from the feed itself. This means that you cannot have promotion controlled per feed anymore without having both promoted and not promoted feed item node types.
I can appreciate that there may be new and better ways to accomplish feed item promotion using triggers, but what is the recommended way now?
Comment #12
Anonymous (not verified) commenteddunlop:
open a new issue. i think your problem is worth discussing, but it's not a bug and this issue is closed. There is no inheritance of node status fields like promoted, published nor comments or anything like that advertised, so you might propose it as a feature request.
Comment #13
jcamfield commentedI have to admit, I liked this setting, as I could provide a mix of feed items for the home page and throttle noisier feeds. I find it convoluted if not downright impossible to emulate this in views (select the n most recent items from these x feeds (or y different content types) - you can select the n most recent across them all, but not (as far as I can tell) the top n from each (which might be 5 months old from one content type/feed, and 5 minutes old for another that has hundreds of posts in the past 5 months)
Not re-opening, because clearly the db call is onerous, but I would posit that there needs to be a way to throttle feeds on a per-feed basis, not just a content-type basis. I'll look in to using workflow for this and report back if I can get it working to my satisfaction (if anyone's already gone through this, tips would be appreciated)