Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.One of my users has discovered that, if he omits the time part of the publish date, the field is apparently not parsed correctly. On subsequent viewing, the field shows a time on 1969-12-31 and the item has been published. The intention of omitting the time is to publish at midnight, and this was the behavior with previous versions of the module.
Curiously, the parsing appears to work OK, even with the time omitted, when the user is an administrator.
It might be argued that the time part should always be supplied, but it was very helpful that it defaulted to midnight where omitted.
| Comment | File | Size | Author |
|---|---|---|---|
| #3 | scheduler-module-236841-3.patch | 4.55 KB | skiminki |
| #1 | scheduler.module.patch | 13.11 KB | wulff |
Comments
Comment #1
wulff commentedAFAICT this is a general problem when submitting new nodes which use the scheduler. I can reproduce it like this (using scheduler and JStools):
This error seems to occur because of the
if (isset($node->nid) && $node->nid) {check in nodeapi. When submitting a new node, the nid isn't set which means the submit handler is not run.Please test the attached patch which fixed the problem for me. (The patch also removes some trailing whitespace - the interesting part starts on line 102.)
Comment #2
sumici commentedI have most likely the same problem. Module works only with already existing node. If the new node is submitted with Publish on and/or Unpublish on filled, the date turns to 1969 (for me actually 1970, as I am at +1 zone). It has the following consequence: if both dates are set, then when cron runs, the node is published and unpublished at the same time.
Wulff, your patch is rejected: "Hunk #8 FAILED at 165." It seems to be for different version then 5.x-1.12 (the attached file name is scheduler.module_6.patch).
Minor problem: Timecheck reports identical UTC and local time, while date and date -u prints correct different dates.
Comment #3
skiminki commentedI concur that this problem occurs when setting publishing datetime for a new node. The problem is indeed that the unsaved node does not have nid at nodeapi/submit (as pointed out in comment #1).
The attached patch removes $node->nid presence checks from view/submit operations in nodeapi, as nid is not required there. This also fixes this issue - at least for me. Please consider reviewing and applying the patch. The patch is against current DRUPAL-5 CVS branch.
Comment #4
idflorin commentedTested on C'est chic and seems to be working. I'll be back if I have problems.
forgot to say I've applied just the scheduler-module-236841-3.patch
Comment #5
bjacob commentedI've applied your patch but now it seams that I can't edit the scheduled times. I've tried to change the publish_on and unpublish_on dates but no way! The changes are not stored. I've also applied this patch: http://drupal.org/node/230836#comment-797718. Is this somehow related?
Comment #6
skiminki commentedThese two are somewhat related. I couldn't reproduce your problem with these two patches (scheduler-module-230836-7.patch, scheduler-module-236841-3.patch) applied against Scheduler 5.x.-1.12.
Are your publish/unpublish timestamp formats like 2008-04-18 19:10:57 or are you using the javascript calendar?
Does this problem apply also to new nodes? I ask this because I had a situation where scheduler had set the node created timestamp before 1970-01-01 (negative unix timestamp) and Drupal refused to save the node before I manually corrected that directly to the database into node table.
Comment #7
skiminki commentedApplied scheduler-module-236841-3.patch to CVS. http://drupal.org/cvs?commit=112670
Comment #8
skiminki commentedIn 5.x-1.13.