Running Drupal 5.16.
I'm using FeedAPI_Node to create Book nodes for feed items as they come in. I want to initially set all ingested nodes to not be published, and then let my users review the nodes, publish the ones they want to keep, then run a cleanup batch to clear out unpublished nodes after a certain time.
The issue is that when FeedAPI updates existing nodes, it overwrites the "published" status of the existing Book nodes, setting it to 1. I don't want to make the change in the Book content type, because it's a type that users also use to manually create Book nodes. It seems we need to add a check in FeedAPI to not overwrite the node->status if there's already a setting there, no?
Seems like in line 260 of feedapi_node.module, we could do a quick node load if isset($feed_item->nid) and use the current status, and/or leave out that whole part to just use the node's current settings.
BTW this is a problem in the version 6 of FeedAPI as well.
I'll look into putting together a little patch for incorporation.
Craig
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | 418854_keep_node_options.patch | 4.83 KB | aron novak |
| #4 | feedapi_node-418854.patch | 1.68 KB | stormsweeper |
Comments
Comment #1
aron novakedit: well, you're right.
If you can post a patch, it would be fine.
Comment #2
stormsweeper commentedI had worked on a patch for this as I had also encountered it, but now I'm not appearing to get the issue using 6.x-1.6 - weird. The patch I made is simple enough - I added a bit inside the update hook to get the status, promoted, and sticky flags, and then in the save function I had it use that if available, or fall back to the default node options.
Comment #3
stormsweeper commentedAh, just hacked in soem bits to make it always refresh a feed. Patch coming shortly.
Comment #4
stormsweeper commentedPatch attached fixes this issue for 6.x (rolled against DRUPAL-6--1). There is no configuration, it will just take the existing values for status, promote, and sticky from the extant node, otherwise it fails back to using the content type defaults. No tests included for this use case, however.
Comment #5
kafka93 commentedJust tested this and it works great for me on D6. Thanks!
Comment #6
aron novakI re-rolled the patch, also extended with a simpletest.
Comment #7
aron novakstormsweeper, kafka93: Can you confirm that the patch of #6 solves the problem?
I'm in doubt that the issue really exists, because if you apply only the test part of the patch to the DRUPAL-6--1, the test is successful. That's why it would be great to see a manual confirmation.
Comment #8
stormsweeper commentedI'll take a look again. As I posted before, it seems to not be happening for me in 1.16, although I have also opted to instead use a "flag" for this kind of workflow. I will try to scare up some time this weekend to test.
Comment #9
aron novakFYI: from the patch at #6 i committed the test part of the patch. This is still really useful. On the other hand I really count on feedbacks that can confirm that this is a non-existing issue in DRUPAL-6--1. Then i can close this ticket.
Comment #10
stormsweeper commentedConfirming that I don't have this issue in 1.6 currently. I'm using a clean checkout and have feedapui, feedapi_node, and feedapi_inherit enabled.
Comment #11
aron novakGood, 6.x.1x-dev is not affected.