Module Release: SchedulePages

[yellowled]

I just installed this locally to evaluate it. The datepicker only offers the option to set a date, but if I set the date, the datepicker input field is set to "08.08.2012 hh24:08:ss" … and I have a feeling this is not intended behaviour?

[formmailer]

Hi!

I haven't seen this behaviour before. I just tested it and could not reproduce it.

For me the dates shows like on the attached screenshot.

Are you using WAMP/XAMPP locally or are you running a local linux server?

/Jasper

[yellowled]

Are you using WAMP/XAMPP locally or are you running a local linux server?

Local LAMP. Ubuntu 12.04, Apache 2.2.22, PHP 5.3.10, MySQL 5.5.24.

[Frank Vèssia]

After install i got this notice

Notice:Undefined index: cronInterval in/home/public_html/site/modules/SchedulePages.module on line188

[Ralf]

I just installed this locally to evaluate it. The datepicker only offers the option to set a date, but if I set the date, the datepicker input field is set to "08.08.2012 hh24:08:ss" … and I have a feeling this is not intended behaviour?

Hi!

I haven't seen this behaviour before. I just tested it and could not reproduce it.

For me the dates shows like on the attached screenshot.

Are you using WAMP/XAMPP locally or are you running a local linux server?

/Jasper

@ Jasper

i didn´t think that this is a local problem from the LAMP because I can reproduce the problem from yellowled on a server at a ISP.

I thought that the Problem that yellowled and I have is that we CHANGE under SETUP -> fields -> publish_from -> Details -- the "Time Output Format" from 14:20:30 to 14:20 !!

and so i get the SAME Error as yellowled have with the output "15.08.2012 hh24:08:ss"

I change the Time Output Format back to 14:20:30 an ALL works like a charme

Did you have any solution for this??

[apeisa]

There is a bug (probably mine ) in current code.

From line 157: https://github.com/f...ges.module#L157

// Publish pages with a publish_until date > current date
if($p->publish_until > $time) {
 $p->removeStatus(Page::statusUnpublished);
 $p->save();
}

If you have unpublished page where you have set publish_from field, but left publish_until empty, then it won't get published. I think this is the most common scenario, so strange that this hasn't popped earlier. Easy fix though:

// Publish pages with a publish_until date > current date (and publish_until is set)
if ($p->publish_until > 0 && $p->publish_until <= $time) {
 // We keep it unpublished, since publish until is set and valid
} else {
 $p->removeStatus(Page::statusUnpublished);
 $p->save();
}

I know that could be achieved with simple if instead of if else, but I think the logic is simpler to understand that way.

[formmailer]

Thanks, apeisa. I just pushed the bugfix to Github.

@yellowled and Ralf: I'll take a closer look att the datefield issue soon.

/Jasper

[apeisa]

Datefield bug might be unrelated to this module. Pw improved datefields recently and some fields need re saving.

[formmailer]

Datefield bug might be unrelated to this module. Pw improved datefields recently and some fields need re saving.

I know, I am going to test with the latest PW version and see how that's working.

[renobird]

Hi Jasper,

Just installed this module (running 2.2.9) and I get this warning:

Warning: preg_match() [function.preg-match]: Compilation failed: unrecognized character after (?< at offset 6 in /x/xxxx/xxxx/xxxxx/wire/modules/Fieldtype/FieldtypeDatetime.module on line 175

Does this hook into the FieldtypeDatetime.module somehow?

I'm not sure what was going on there. I uninstalled/reinstalled both modules and the warning is gone.

[formmailer]

Renobird,

I don't know what happened either, but yes, this module relies on the DatetimeFieldtype.

/Jasper

[renobird]

Thanks Jasper,

Gremlins I guess. All seems well now.

[apeisa]

I found one bug with this module. I have set the cron to run every minute. I had only one page where I have managed publish settings. Then I started to see this error message on any admin page every now and them (I would assume that it would occur once a minute):

Page saved, but not published. Change publish until setting if you want to publish this now.

I'm not sure, but shouldn't this problem go away if we could restrict afterSave() method to run only when saving page through admin?

[teppo]

@formmailer: it's a bit late to say this, but thanks for making this module -- it has been very useful!

Also wanted to mention that we've been running this in current dev branch (future 2.3) on couple of sites for quite a while now without any problems, so I'm pretty confident you could already add 2.3 to "compatibility" field at modules page.

[formmailer]

Hi Teppo!

It's great to hear that this module is useful.

I haven't had time to develop new sites or projects during the past few months, so I haven't been able to test the module in the development branch myself.

I am happy that it works there as well. Thank you for letting me know.

And thanks for the suggestion you submitted via Github, it has been merged now.

/Jasper

[ceberlin]

Hi Formmailer, very useful module.

I just want to mention that some of us have problem with it under PW 2.3.1 DEV.

See this thread:

http://processwire.com/talk/topic/3768-processwire-231-dev-branch/page-2

What happend to me: Out of the blue the module was unpublishing every single page on my system which had a template with your scheduer fields.

Also Ryan found an issue, see his comment #36 in the mentioned thread.

[formmailer]

Hi Ceberlin!

I am sorry to hear that you are having troubles with the module.

I haven't been able to test it with the development branch myself, but will definately look into this and let you know when it's fixed.

//Jasper

[ceberlin]

Hi Jasper, no worries... I like the module and need much, what it does, and I am positive that this  issue can be fixed.

To answer your question: The fields were in there but since our website is only a few weeks old, those fields were still mostly empty (no content, also no default content).

Server Time problems? Provider says "no" - but who knows. There domain uses the cloudflare service, so this might play a role.

[formmailer]

I don't see how the Cloudflare could be a part in this. I use them myself and they are just serving cached information, so that should not be a problem.

The only thing I can think of right now in order to pin point the exact time and is to add some logging to the module. Just to log the exact time when pages get (un)published and hopefully why.

I'll try to fix this later today or tomorrow and let you know when you can try it.

[Pete]

There is already a log module for Processwire in the directory that will help - can't remember the name at the moment (on my mobile) but it logs admin actions or page alterations or something.

It created a LOT of logs in conjunction with this module - dozens of pages where it published and unpublished pages. I hope I still have the logs, if not I'll reinstall both modules and let you know as I've been having this issue too.

[formmailer]

There is already a log module for Processwire in the directory that will help - can't remember the name at the moment (on my mobile) but it logs admin actions or page alterations or something.

It created a LOT of logs in conjunction with this module - dozens of pages where it published and unpublished pages. I hope I still have the logs, if not I'll reinstall both modules and let you know as I've been having this issue too.

Thanks! Was just looking into that module.

[formmailer]

I just uploaded a new version with logging and a fix for the issue Ryan described.

@ceberlin and Pete

I hope you can install this version this version with logging enabled (logging can be enabled in the module configuration).

Every automatic (un)publication will be logged in the /assets/logs/messages.txt file, with timestamps for the publish_from and publish_until fields and the timestamp of the event itself.

If the problem still exists, we can take a look at the logfile.

/Jasper

[Pete]

Thanks - I'll make a note to reactivate it tomorrow with the new version

[ceberlin]

Hi Jasper, great, I will download the update. Is there a way to collect the logs but stop the execution?

Right now I don't want the module to be active as my client would not tolerate this before the problem is found.

What to I need to comment out to have the logs saved but the unpublishing not executed?

(Or maybe that would be a cool add-on for the prefs. Do not actually publish/unpublish but send an email reminder instead.)

Some more thoughts on this:

1. Empty fields.

Maybe the code needs a revision for this.

Pages where the unsubscription field is empty should never be executed, not even with weird time() results. But that is what happend here.

Maybe the empty field can be something else than 0 so that $p->publish_until > 0 might not work in all cases (if it was NEVER set) ?

2. time() / $time

Assumed that the Provider is correct when saying that the server time here is "always correct" and thoroughly checked...

The effect happened not completely out of the blue but when I worked on a panel that displays a word clock with local times (a html5 canvas) on the contact page.

Maybe fiddling with php 5.3 timezones calculations came in the way for the module?

Somewhere during development a side effect could have happend. For example:

I used date_default_timezone_set() a lot to calculate local times for each clock. And I used a variable $time for that localized time, which you used as well a a global variable for the individual page. (I am now using $time1 and no trouble so far.)

[formmailer]

Yes, commenting out the 2 save lines will work.

I'll take an extra look at the empty fields.

Time zone settings are quite important for this module, but would only cause to publish/unpublish pages at the wrong time, but not more than 27 hours off (GMT-12 all the way to GMT+14 + possibly DST)

As for the $time variable, that could be an issue. I'll change the variable name to something more unique in the next update.

Update: uploaded a new version where:

1. $time has been replaced with $currenttime

2. Added language support for the whole module.

/Jasper

Edited July 31, 2013 by formmailer