[[I'm putting this here to see if there are some nice solutions / hints / info before I investigate further.]]

If unwanted feed items are pulled and the node is deleted (as it's not wanted) then the item will reappear until it's no longer in the feed. A memory of 'seen items' even deleted ones would be even more cool than the already amazingly cool feature not to duplicate across feeds ;)

Stopping feedapi_node nodeapi:delete from removing the node from its tables obviously solves this. I'm guessing, and will check later if no-one knows, that this is going to have some nasties as queries pull up what nodes are 'available' in a feed and some are gone...

Comments

budda’s picture

budda
Primary language English
Location Cheshire
commented

Just unpublish nodes instead of deleting them - so they still exist in the database.
You could then prune all unpublished nodes over a certain date -- using a custom module or SQL query.

ekes’s picture

ekes commented

Yes I'd already thought of this solution, but we are talking about a lot of feeds that need moderation (they are pulling by keyword/search from youtube, google, etc). It's not nice for the poor admin I'm working with.

It's also counter-intuitive behavior, when it has been seen.

Plus, the data is already in the feedapi_node tables, just don't want it to be in the node table. Only a case of working out that this doesn't cause clashes.

budda’s picture

budda
Primary language English
Location Cheshire
commented

Yeah we're doing exactly the same thing pulling items from youtube by keyword search, and unpublishing the spam/crap items.

If you're going to delete the item anyway, this requires an action. so why not just tick the nodes and select unpublish instead on the content admin page. I don't see how this is any more counter-intuitive?

zoeyoung’s picture

zoeyoung commented

hi there
as the poor admin mentioned above, maybe I can help by explaining how it looks from here..
we are looking to suck a LOT of information from across the web
when i go to moderate the list of items that have come in to the database, inevitably there is a lot of guff.
when I've deleted a whole lot of items, it is frustrating to find then coming in again.
hence ekes' request above.
however if i just leave the guff unpublished, the items hang around in the list of items that have come in on feeds and are waiting to be published - or deleted.. and with so much material in that list for me to manage, the last thing i want is to wade through these lurkers as well every day.
so, I don't know if the solution might be to have another category, neither published (showing on the site), unpublished (because awaiting moderation) nor deleted (and liable to enter the database again.)
maybe this new category could be called something like 'deferred' (we want to know the items exists to avoid duplicating or sucking them again, but otherwise we don't want anything more to do with them.. so items with that category could go to another part of the database where i do not have to think about them on a regular basis any more... )?
cheers for your advice etc!

alex_b’s picture

alex_b commented

Having read this thread I really don't see a reason why you couldn't implement this behavior with node published/unpublished.

Add a moderation bit (in moderation yes/no) to your feed item content type (this can be a simple CCK field or you could use the workflow module).

If your feed item nodes are published by default when they come in:

Build a moderation queue with views module that shows those nodes that are in moderation and are published. Throw away nodes by unpublishing them, keep nodes by removing the moderation bit.

If your feed item nodes are not published by default when they come in:

Build a moderation queue with views module that shows those nodes that are in moderation and not published. Throw away nodes by removing the moderation bit, publish nodes by setting them to published.

You might want to add some shortcut links (like "keep", "dump") to the moderation queue that allow you to do one click actions on the items.

Did this help?

ekes’s picture

ekes commented
Status: Active » Closed (won't fix)

Yes I had considered that and also doing it with workflow and actions.

Looks like this is an individual case. The site never deletes feed node items of value, and is an index and archive of some of the material. So it's pretty big. The options are to delete items that remain unpublished for figure unknown (guess how long they remain in the source feed); or set up feedapi not to ever pull items it already has pulled (deleted or not).

I'll do it on an individual site base.

szy’s picture

szy commented
Title: Stop deleted nodes from reappearing if still in feed when using feedapi_node » Stop deleted nodes from reappearing if still in feed
Version: 5.x-1.x-dev » 6.x-1.x-dev
Component: Code » Code feedapi_node
Issue tags: +FeedAPI

Hi there,

Any other solution for this issue? :]

Mine is to have a temporary node type for feed items. Then, changing it
to a proper type with Nodetype module. I can afford this, because every
appearing feed item needs editing by the editor, before it gets published.

I feel more comfortable keeping spam/ham category on the node type level,
than on published/unpublished level.

Szy.

equinox’s picture

equinox commented

I created a cck field called "Bury" that I add to most of my content types now. Its just a tick box and then all of my views then filter for it. I keep my published/unpublished queue clean for items actually requiring moderation, whereas filtering for IS NOT NULL field_bury creates views sitewide that immediately eliminate any content that should not be visible and prevents the item from reappearing on the next cron run that pulls in that feed.