Closed (fixed)
Project:
Scheduler
Version:
6.x-1.2
Component:
Code
Priority:
Critical
Category:
Bug report
Assigned:
Reporter:
Created:
13 Aug 2008 at 13:55 UTC
Updated:
18 Nov 2008 at 18:01 UTC
Jump to comment: Most recent file
Whatever date / time I put in the "publish on:" field, when I click on Preview the value has changed to "1970-01-01 01:33:29".
Accordingly, if I "save" instead of "preview", it is published immediateyl because the scheduled date is in the past.
I've tested this with the simplest case. An out-of-the-box Drupal 6.3 install. Add the Scheduler module. Change no other settings except to enable (un-)publishing for nodes of type Story. Create Content -> Story. Put "Test" in title and body, put "2009-01-01" in the "Publish On: " field and click "Preview".
Can anyone else reproduce this?
| Comment | File | Size | Author |
|---|---|---|---|
| #16 | scheduler.zip | 13.47 KB | eric-alexander schaefer |
| #14 | scheduler.module.patch | 1.93 KB | eric-alexander schaefer |
Comments
Comment #1
jamesoakleyjust changed the title to something a little more useful
Comment #2
jamesoakleyGot a bit further at tracking this bug down. It seems to be to do with the way the supplied date/time is parsed.
If you put "18 September 2008", the value changes to 1970-01-01 01:00:18. My time zone is GMT+1, so it's 18 seconds after zero time (1970-01-01 01:00:00 in my zone). It's parsed the "18", and made that the number of seconds after zero that it stores.
If I put "2009-01-01 06:45:00" as my value, it turns into 1970-01-01 01:33:29, as described above. Now I know that it's storing the number of seconds after 1am on 1st Jan 1970, I convert 33 minutes and 29 seconds into seconds. ... 2009 seconds! So it's parsed the 2009 bit.
If I put 20090101, it turns it into 20 million, 90 thousand and 101 second after 1am on 1st Jan 1970.
What I think it's doing is not parsing at all. I don't think my input is going into
strtotime. I think it's doing a best guess at casting my input into a 32-bit integer, and then storing that value.In case it helps anyone reproduce this: I'm using PHP5.2.5
Comment #3
eric-alexander schaefer commentedCan you post the date format from /admin/settings/scheduler, please.
Comment #4
jamesoakleyI'm using the default. Y-m-d H:i:s
Doing a bit of debugging, it looks to me like the
case 'presave':section never gets entered.Under the case statement, I've put
$node->publish_on = 1229904000;(should be near abouts 1st Jan 2009), then commented out everything else until thebreak;statement. It doesn't change the behaviour I've described. (It should give every node a scheduled publish date whether I want one or not).I always click "Preview" not "Save", because all that "Save" does is make the node publish immediately, but I can't see what "publish on" date made it do that.
Comment #5
jamesoakleyComment #6
jamesoakleyDoes anybody else get the same problem? My setup seems so typical that I'm really surprised that the problem isn't more widely reported.
Comment #7
jamesoakleyComment #8
jamesoakleyOK. Done some further tests. It seems this is actually two issues. One is a bug. One may be a "by design" feature, or may be a bug - only the module author can tell us that.
Probably related to this, I think the validate hook is not being invoked. If I put misformatted dates in the text boxes, or if I enter an unpublish date that is before a publish date, I don't get any error triggered.
I can see that this could be by design. I wonder if it's a bug instead, because I used to use 5.x-1.8, and then I was allowed to enter a date with no time, or a date and time that doesn't specify the number of seconds, and the module would be lenient with me.
Marked back from "critical" to "normal", because (now I understand the module's behaviour) I can work around it.
Comment #9
eric-alexander schaefer commentedJames,
I will be working on all open issues this week. Things have been quite busy...
Eric
Comment #10
eric-alexander schaefer commentedWith #8 I can reproduce the behaviour. Thanks, James. I still consider it critical. Stay tuned.
Comment #11
eric-alexander schaefer commentedI know now why the date vanishes and the validation is not running, but if I fix it, it breaks something else. :-(
I need to dig a little deeper into nodeapi...
Comment #12
eric-alexander schaefer commentedhttp://drupal.org/cvs?commit=150522
Comment #13
eric-alexander schaefer commentedOk, it is still not perfect. It keeps the values if the node is brand new. If the node was already saved and edited again, it still looses the values.
Comment #14
eric-alexander schaefer commentedOK, I got it.
James could you please verify it. I checked it in (http://drupal.org/cvs?commit=150598) and also attached a patch in case you cannot use cvs.
Comment #15
jamesoakleySorry I can't access this.
I tried the cvs link first, to try and download the complete .module file. All I got was an HTML rendering of the diff from the previous version. I guess that's because I haven't got a CVS account.
I tried to browse through CVS contributions to download the latest version, but when I get to the Scheduler module (http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/scheduler) there's nothing there. I'm afraid I'm showing my ignorance of how to navigate the Drupal CVS - I must be looking in the wrong place.
So, final attempt, I downloaded the .patch file, and applied it to the 6.x-1.2 .module file. But "2 out of 2 hunks FAILED" was the result - so I guess the .patch file presupposes some other changes such that the 6.x-1.2 .module file is too different for patch.exe to handle.
Any chance you could post the current version of scheduler.module here (or correct my ignorance on how to browse through cvs.drupal.org?
Comment #16
eric-alexander schaefer commentedHere's the complete current state. I don't want to make a release until all the changes are verified...
Comment #17
jamesoakleyWorks fine for me.
Thanks Eric
Comment #18
eric-alexander schaefer commentedFixed in 6.x-1.3