Integrate the new jquery popup calendar from Date module version 2

Integrated with Date Popup module. This means, that Scheduler now depends on Date API, but it also makes Scheduler much more lightweight - no date handling. Also restyles few comments.

Works for me, not sure about timezones (I sometimes don't understand them) - needs testing.

Rerolling, I noticed one typo in update_N() function.

Thanks alot!
What version did you diff against?

I will probably test it tonight.
Anyone thinking that the date-dependency should be optional, like the JSTools_Dep was in release 5?

date may be optional, it's only a matter of one if().

Butalso, date allows to get rid of a lot of code like *strptime() and date validation.

I diffed against 6.x-1.2

subscribing

Really interested in this for our school site too
subscribing

i´ve found a problem in the patch:

Parse error: syntax error, unexpected $end in /var/www/vhosts/piensablogs.com/httpdocs/piensared/sites/all/modules/scheduler/scheduler.install on line 90

simply corrected adding a } at the end of the file.

it doesn´t work on drupal 6. It shows the calendar but doesn´t updates the published state when arrives the date.

If you edit the post, it allways appears the "actual" date and time on the publish on field ¿?¿?

This worked great with the exception of the bug mentioned in #8. I have rerolled the patch and attached it here.

I was testing this patch (comment #10) and noticed that the "Publish on" field works as expected, but the "Unpublish on" time field is off by 5 hrs. If I put in 16:00:00 and save it shows 11:00:00 when I go back to edit. I think the timezone I'm in (Chicago) might be a -5:00 offset from GMT which may or may not be relevant.

This patch works almost perfect. The only problem with it, is the time zone incompatibility, it uses always the GMT (0) for the publish and unpublish date, so after saving the node, if the time zone setting of the site is different from GMT, the publish/unpublish date will be changed.

If anybody could fix this problem, it would be a very usefull feature...

A couple of things:

- How do I erase the time? Is it possible? It should!
- I don't like the idea of scheduler depending on the date.module. It should be optional.
- Please do never change things that have nothing to do with the problem at hand. Especially do not make comments "nicer". It makes it really hard to read the patch. If there is something wrong with the comments file a separate issue with a patch.

it would be great if there wasnt the problem with the timezone.
the new update from today fixes things which i worked around in a very complicated way!
i would be satiesfied if the views integration and the JS-datepicker work fine.

Well, views should work now. I would integrate the jquery patch if it would work. There are still two problems:
(1) the timezone problem (I didn't try it...)
(2) If you set a value in the time field, you can not remove it later.

BTW: What happens if JS is deactivated (can't test it right now)?

Rerolling:

1) Against 6.x-1.3
2) Removed comments patch
3) There is still a problem with timezones. I tried some debugging and I am not sure but I think the problem is in Date module...Again - not sure.

If Javascript is deactivated, you get two simple textfields for date & time.

Unless I've missed something, the core PHP function strtotime() can be used to generate the UNIX DATE requried for the scheduler.

This uses the default Timezone for the server unlike date_convert() which uses UTC.

It will default to 00:00 in the server's timezone if left blank, which I found useful.

So the key lines to change are

$publishtime = date_convert($node->publish_on, DATE_DATETIME, DATE_UNIX);

to

$publishtime = strtotime($node->publish_on);

$unpublishtime = date_convert($node->unpublish_on, DATE_DATETIME, DATE_UNIX);

to

$unpublishtime = strtotime($node->unpublish_on);

You don't want to servers timezone. You want the users timezone!

In my case I want the users to schedule the unpublishing time/date relative to the server's location, not their own. So if they are across the other side of the country and they leave the time field blank (and therefore goes to midnight), I want that to be midnight server time so it's consistent across all users. But that's just for my situation and for scheduler.

But that's a fair enough request. I was mostly concerned with using some timezone handling, where date_convert() from the Date API has no handling for Timezones.

You should be able to specify the timezone that strtotime() uses just before the unpublish time is commited to the db, with date_default_timezone_set() function.

I'll look at this further later this week.

The current behaviour (using the users timezone if user timezones are enabled and using the servers timezone otherwise) should be conserved. If you want to use the servers timezone even if user timezones are enabled you should make this an option and the user should be informed (e.g. via the help text for the date input field).

subscribing

subscribing

subscribing

subscribing

urwen,

Check to see if you have the "Alter published on time" setting enabled in the "workflow" section for the aplicable node type(s). I was having this problem also on a newly-upgraded site, and when I went hunting for a "bug" in the code of Scheduler I found that it was simply this optional setting which I had overlooked. :-)

Kind regards,

Scott ("syscrusher")

Matt, are you still with us? ;-)

subscribing

subscribing

patch above removes _scheduler_strtotime() but leaves references in form_alter

This would basically make Scheduler into a Date API-dependent module, correct? That would be quite useful to me - especially with the nifty popup calendar, as I can't get it to work using JSTools.

Rerolled patch to apply against 6.x-1.3.

Subscribing... Question also: wasn't clear to me: does patch in #31 solve the timezones issue or does that one remain?

Got patch in and did some testing. The date popup works nicely (a beautiful thing!). The fields do allow editing after setting dates & times.

Problems:
1. after setting the time, then saving, the scheduled time changed to five hours earlier. That is, I keyed in 20:00:00 and saved. Then my content view showed it as sched for 16:00:00. Checked the fields and saw that the value had changed to 16:00:00.

So I'm guessing it's still converting to UT. Not sure what it was doing earlier. If it matters, my server is set to Central Daylight Time (at least, that's what "date" command says when I do it from shell).

2. The time format is 24hr even though format in my Drupal settings is 12hr

Thanks for testing. I will have a look at the timezone issue this weekend.

Here's another patch that rolled up with the fixes for part of the timezone problem. It'll now have the UTC time in the database. I still found there was a small problem with what it displays after you've saved it. I'm pretty sure it's in the way scheduler_form_alter() doesn't use the user's timezone. E.g it uses the timezone specified in the site settings instead of the user's timezone.

Shouldn't take too long to fix the rest of it when using this patch as a starting point.

Ok... I figured I might as well try fix it myself. Here's the patch I ended up with. It seems to work.

Thanks alot. I will test it tonight (CET).

subscribing

Applied patch in #36 to 6x-1.3. This is working well. Made my day!
So what are the chances of it going into a new release (after others test also I assume)?

Well, I wanted to test it last sunday, but my test server died. The new server will be up and running by next sunday. I hope we can roll out this patch next week. Thanks for testing!

Eric

There are still timezone issues with this patch. I will review it more closely on thursday night.

@ Eric - thanks for your work on this issue - I'm a satisfied user of Scheduler, and this will make me even more so!

Yeah. Same here.
I'm not seeing any time zone issues though... but I haven't really been pounding it.

Hi,

When I implemented the patch from #36 I get

* warning: timezone_open() [function.timezone-open]: Unknown or bad timezone () in /public_html/test/modules/date/date_api.module on line 1162.
* warning: date_create() expects parameter 2 to be DateTimeZone, boolean given in /public_html/test/modules/date/date_api.module on line 1162.
* warning: date_format() expects parameter 1 to be DateTime, boolean given in /public_html/test/modules/date/date_api.module on line 1190.
* The entered publication date is invalid.

I have checked that the timezone is set and it still gives me this error.

I tried implementing the patch from #35 but it would not actually schedule the posts.

subscribing

subscribing...

subscribing...

I believe I fixed all the timezone problems. Patch is attached.

There are still other problems:

• If any other date format than "Y-m-d H:i:s" is used, the defaults for the input fields will always be the current time (when previewing or editing). This is not acceptable. I will talk to the date module people about this.
• date_convert() does not signal invalid dates. It always returns the current time when encountering invalid values. Thats why I can not reliably detect errors. The user would need to check every single scheduled node after submitting, if the values were OK. Not acceptable.
• Why do we need the 'date_text' input widget? What's the difference to textfield?

When reviewing/testing: Keep in mind that scheduler stores timestamps in UTC time (as does drupal). Input and output is always in the users configured timezone or in drupals configured timezone if user configurable timezone are disabled. The servers operating system timezone does not (should not) matter at all.

I am sorry. Patch in #48 is broken. New one is attached...

#49 patch fails

(Stripping trailing CRs from patch.)
patching file scheduler.module
Hunk #1 succeeded at 66 (offset -14 lines).
Hunk #2 FAILED at 89.
Hunk #3 FAILED at 97.
Hunk #4 succeeded at 149 (offset -67 lines).
Hunk #5 succeeded at 196 with fuzz 2 (offset -38 lines).
Hunk #6 FAILED at 231.
3 out of 6 hunks FAILED -- saving rejects to file scheduler.module.rej

currently reviewing...

ahh sorry, applied successfully. Code had another patch applied to it previously.

I applied the patch (from #49), and then the "Scheduling options" section on the node create/edit form was empty (the fieldset will collapse and open, but inside, nothing appears. Patch applied okay (all the hunks applied successfully), and I applied it to the current 6.x 1.3 release.

Please see the attached picture for what I am now seeing on the node add/edit form.

(Stripping trailing CRs from patch.)
patching file scheduler.module
Hunk #1 succeeded at 66 (offset -14 lines).
Hunk #2 succeeded at 89 (offset -14 lines).
Hunk #3 succeeded at 97 (offset -14 lines).
Hunk #4 succeeded at 158 (offset -58 lines).
Hunk #5 succeeded at 176 (offset -58 lines).
Hunk #6 succeeded at 211 (offset -58 lines).

Hmm....?

subscribing

The patch in #35 is still working fine for me. I'm not sure what timezone issues it's supposed to have. Hope to get a chance soon to back it up and try #49.
@52, any chance you're using other form-related modules? I've seen form fields disappear like that before but it was a css issue.

Subscribing

Patch #49 works for me, did not encounter timezone problem also.

Patch applied to scheduler-6.x-1.3

$ patch -N -p0 <../scheduler6_date_0.patch
(Stripping trailing CRs from patch.)
patching file scheduler.module
Hunk #1 succeeded at 66 (offset -14 lines).
Hunk #2 succeeded at 89 (offset -14 lines).
Hunk #3 succeeded at 97 (offset -14 lines).
Hunk #4 succeeded at 158 (offset -58 lines).
Hunk #5 succeeded at 176 (offset -58 lines).
Hunk #6 succeeded at 211 (offset -58 lines).

Publish works as expected. Unpublish didn't.

I don't know if this is possible with the pop-up calendar, but I wish it highlighted the current date.

UPDATED: I got the last bit by adding to my style sheet:

table.ui-datepicker tbody td.ui-datepicker-today a {
...
}

I hate sounding like I don't know what I'm doing, but I don't know what I'm doing.
I thought I had everything installed that's needed for this to work, but I get no popup calendar on either Scheduler fields. I have Scheduler, calendar, date, jquery update, jstools, event, and more. Could I ask what needs to be activated, and where in the admin section any changes need to be done? I'm using Scheduler on several different node types, as well as Events.
Thanks.

This is work in progress and therefore not released yet. There are still issues that need to be resolved.

That's fine. I just swear that I remember using it already somewhere.

I'm using it. So far it's working... and very nice.

You were probaply using the Drupal5 version.

I might have been using D5. I was testing a site a while ago using that.

One question though. When the test version is working, is there an admin setting to activate it, or does it just do it automatically?

subscribing

subscribing

Is there a patch for 6.x-1.5?

subscribing

I've re-rolled the patch against 6.x-1.x-dev (it also applies cleanly against 6.x-1.5). It works with all the different time formats I've tried, but it might be possible to find a format that breaks. We're now using the date module's configurable formats, so they should ostensibly all be supported.

As for the reason for using date_text instead of just date_popup outright – it leaves the minimum requirements for using scheduler at date_api. For date_popup, that module is required as well as date_timezone, and it might cause problems for someone using a different version of jQuery UI in his theme. It seems like a good compromise to me :)

Sweetness! Applied to 6.x-1.5, worked fine, but the first hunk failed (the one defining the module's dependency on Date API).

Works beautifully, makes things a whole lot easier, date-selection-wise!

Hmm... now having some trouble: If I try to set a scheduled publishing time later this morning, it throws an error "publish date must be set in the future" (something to that effect). Also, it isn't saving the scheduled publish date on a few of the nodes (it seems random to me).

After enabling date_api (2.3) and scheduler (1.5 patched with #69) I have major issues. Please note this is without enabling date_popup.

When creating/editing a node, if I leave both scheduling options empty I get the following errors when I save:

warning: preg_match() expects parameter 2 to be string, array given in ****\sites\all\modules\date\date_api.module on line 1170.
warning: preg_match() expects parameter 2 to be string, array given in ****\sites\all\modules\date\date_api.module on line 1170.
warning: preg_match() expects parameter 2 to be string, array given in ****\sites\all\modules\date\date_api.module on line 1170.
warning: preg_match() expects parameter 2 to be string, array given in ****\sites\all\modules\date\date_api.module on line 1170.

The node is saved, but when I go back to edit it, both fields are populated with the unix epoch (1970-01-01 00:00).

For completions sake, when I leave 'publish on' empty and set the 'unpublish on' in the future, the changes are saved (with the following errors) and the 'publish on' is set to unix epoch.

warning: preg_match() expects parameter 2 to be string, array given in ****\sites\all\modules\date\date_api.module on line 1170.
warning: preg_match() expects parameter 2 to be string, array given in ****\sites\all\modules\date\date_api.module on line 1170.

When I set the 'publish on' date to the future and leave the 'unpublish on' empty, the changes are not saved, the 'unpublish on' is left blank but outlined in red, and I get the following errors:

warning: preg_match() expects parameter 2 to be string, array given in ****\sites\all\modules\date\date_api.module on line 1170.
The 'unpublish on' date must be later than the 'publish on' date.

Finally, if I set both fields to future values it stops complaining and seems to work.

Once I enabled the date_popup there are no more preg_match() errors, but similarly to geerlingguy in #71, the times must be set at least 4 hours in the future in order to take. This leads me to believe there is still a timezone bug.

The node is only published once the saved time is reached, as opposed to the saved time -4 hours (if that makes any sense...)

This patch builds on the previous ones and applies against the latest DRUPAL-6--1 branch, which might not match 6.x-1.5.

This version uses date_popup as the dependency for the module, rather than just date_api to fix #72 and #73.

It also resolves the time zone issues experienced in the recent versions of the upgrade like #71 observed that used date_convert() from the date API to convert the string to a unix timestamp. date_convert() doesn't return a local time, whereas time() does. Since the cron uses time() to base its publishing decisions, the saved times to (un)publish also need to use localized times, which is what strtotime() does. I don't know all the history behind all the extra strtotime() overhead that appears to be in there now, but it appears to be unnecessary now, along with the time zone adjustment that was done separately.

It also removes some 5.x things like hook_help() for the modules page, and update_sql() functions that have schema api alternatives. If that makes the patch too dirty, I'll roll those separately I guess, but only if I have to.

Okay, I've tried the patch out. It works perfectly, even with rather weird date formats like "13 Aug 2009 12:25" and "08/13/2009 12:25PM".

Excellent work, thanks – I have a site where I'm using this :)

The next question is whether this should use jquery ui's datepicker directly instead of date's date_popup.

Well, you could argue that the datepicker form element should rightfully be implemented in jQuery UI and only be inherited by date and scheduler. That might be a noble pursuit, but for now I'm satisfied that the datepicker has a user friendly interface :)

If date_popup is required anyway, there's no point in having it check module_exists(), so this removes that check and just defaults to the date_popup fapi type. I considered jquery ui, but the date_popup fapi type provides formatting help that would otherwise have to be re-implemented here, so I'm all about re-using something someone else already maintains.

This version removes things related to the admin settings page that no longer exist through this patch.

- removes administer scheduler permission
- removes translations for the menu item's strings

This patch is getting huge and there are a lot of people subscribed who would probably have an easier time testing it if it was committed to 6.x-dev so they can get it from a snapshot. Can we discuss what's needed to do that?

RE: patch @ #79 -- Patched against 6.x-1.x dev -- Works great, but on one of my sites, if the fields have dates in them already set, they show up blank when editing the node. Without the patch using the latest release 1.5, pub and unpublish dates works fine (but no date popup).. Hmm.

Date conversion problem? Or perhaps unrelated...

Anyone else experiencing this?

I guess I'm not much help with #80 since I'm patching this to get it working for a site that is not already using scheduler (so I don't have existing 1.5 times to test against unless I go generate some). The patch doesn't change the storage format of the timestamps - the database schema is the same.

I'm not sure what you're trying to say about no date popup in 1.5. jstools has no jcalendar module in 6.x anymore for it to work, which is why this issue is open.

Two things:

1. After patch #78 the publishing fields which are edited, show up blank as techninja says --#80.

2. After patch the follow message appears all the time in my site: warning: call_user_func_array() [function.call-user-func-array]: First argument is expected to be a valid callback, 'scheduler_cron_access' was given in C:\wamp\www\teamleaders\includes\menu.inc on line 452. This is the code corresponding to that line:

menu.inc
=======
451 else {
452 $item['access'] = call_user_func_array($callback, $arguments);
453 }

Fields are blank on editing... !! :-(

For #80 and #82, since you're upgrading from previous versions, did you make sure you enabled the date_popup module before you saw that editing existing nodes showed blank values?

Here comes a patch with a new approach. It does exactly the same thing as the D5 version. It uses the jQuery date popup if the date_popup module is installed. Otherwise it uses plain old text fields. Thats all. All the date formatting and date conversion functions stay in place. No forced dependencies on the date modules.
I tested it and the only glitch seems to be, that the example text below the date and time input fields of data_popup use the servers OS time zone and not the configured drupal time zone or the users time zone (if configured). This has been taken care of: #550548: Date/Time example text does not respect the time zone.

Please test thoroughly. Its about time to get this issue resolved...

Cheers,
Eric

The whole problem with trying to provide user facing dates that match their time zone is that the first query of the cron job selects nodes for publishing based on time(), which IIRC returns the server time zone, irrespective of what the site configuration says the time zone is on the Drupal side or where the user is.

If you're going to adjust the descriptions for the user or for the main Drupal timezone setting, you have to adjust the cron query to not use just time(), which will break all the expectations for backwards compatibility and all the years people have used scheduler in production.

time() returns UTC times:

int time(void)
Returns the current time measured in the number of seconds since the Unix Epoch (January 1 1970 00:00:00 GMT).

Exactly. If you store times based on an offset, doesn't the cron need to have the same offset, not just UTC 100% of the time?

All times are stored as UTC times. Earlier version of scheduler would store the user supplied local time and the time zone. But this resulted in all kinds of "funny" time zone issues, as you can imagine. Now scheduler computes the UTC time from the user supplied time and the time zone. It is always good practice to store numerical values in a standardized unit and compute the display value depending on the users preference (e.g. store UTC and display Asia/Tokyo, store Kelvin and display Fahrenheit, store meters and display inches etc.).

Hey everyone, if you all haven't heard.. Eric Schaefer, is the man!

Eric's patch from #84 applied to 6.x-1.x-dev version of Schedule, works amazingly and simply
...Do note I have yet to test against issues regarding timezone differences as my problem site's granularity only cares about days, not hours and minutes.

Once again, a round of applause for Eric.

Patch from #84 also works against 6.x-1.5. Thanks Eric!

Come on people. There are at least 3426.5 subscribers to this issue. I won't commit this change if I don't get some feedback on the function and stability of it. Do you need a patched version for download?

Works for me. The times are all working according to the timezone, which is fine with me (not sure what the desired zone relationship is intended to be). The date_popup description displays the local time, I set local time, and the server stores local time so that it publishes on local time. Date popups came up and time highlighted correctly.

Works for me too.

OK, here we go: http://drupal.org/cvs?commit=255576

This should be in tomorrows dev-release. I want to look through the other date issue (#314212: A better way to enter dates.), before rolling an official release. If you want it now, go with the next dev release...

Thanks everybody,
Eric

Awesome, and thank you!

Thanks for the work on this. Working great for me..