Closed (fixed)
Project:
Scheduler
Version:
5.x-1.4
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
26 Jun 2007 at 16:45 UTC
Updated:
6 Oct 2007 at 14:06 UTC
From http://drupal.org/project/comments/add/153379
1) Issue: scheduler does not work when both "published on" and "unpublished on" are filled.
Solution: Scheduler delete the whole record from "Scheduler" table once the node was published even though "unpublished has values. In function scheduler_cron(), i changed from "== 0" to "<0":
//if this node is not to be unpublished, then we can delete the record
if ($node->unpublish_on < 0) {
db_query('DELETE FROM {scheduler} WHERE nid = %d', $node->nid);
}
Comments
Comment #1
AjK commentedHaving looked at this. If a node is not to be unpublished it's value is set to zero. Hence, when publishing we detect this (==0) and delete accordingly. So I fail to see how <0 should work, as an unpublish time is NEVER less then zero. This would result in cruft being left in the database long after it's needed.
If I'm wrong (yes, I posted original but that was a fork off another issue) then maybe the original submitter would elucidate the real problem they are having.
Comment #2
socki commentedI've seen the same problem, and have had to put my own patch into it. The problem is that if someone creates a node, and sets a d/t for it to be published, as well a time that it should come down... say in the case of syndicated content which has only an allocated lifetime, the current module will only do the publishing, then it will never see the unpublish_on time and hence delete the record from the database.
I agree that the suggested fix of using the '<' probably would not work either.
In the original code:
Unpublish_on is not available to a node. In the nodeapi function, it is called 'unpublished' and even then, I believe I was having in issue with that.. maybe module weights? In any case, I added a line just under the first while loop to trap the unpublished date, and then changed the if condition mentioned above to use it:
And all is well again. Ultimately a cleaner solution would be to not reuse the same $node variable for both table/query data as well as node data because at the very least, it is misleading.
Comment #3
AjK commented