Module Release: SchedulePages

[Torsten Baldes]

I use this module with PW 2.4.4 and ran into the following issue:

When the publish_from field is filled with a date from the past and i unpublish the page, it get's republished with the next lazycron interval.

Is it possible to empty the publish_from field when the page get's unpublished?

Or is there any other way to prevent this?

[teppo]

@tobaco: have you tried setting publish_until to current date -- or any other date between now and publish_from? That should do the trick and is, at least in my opinion, preferable to altering existing values (those could be useful for audit purposes etc.)

[Torsten Baldes]

@teppo

me and my editors using the ProcessPagePublish (http://modules.processwire.com/modules/process-page-publish/) module for quick switching the status. so manually changing the publish_until field is not really an option.

but i just realized, that i could alter this module to change the fields on unpublishing. although this could get quite confusing … 

i have to think about it a bit more …

[ceberlin]

+ 1 for leaving it like it is and not changing values automatically here.

... but maybe add a hint that there is a publishing-field active that would result in a re-publishing (if that hint isn't there already, is it?)

[juhis]

Something strange happened when I updated PW 2.3.0 -> 2.4.0. All pages got unpublished. When I looked to database all pages had these values 1970-01-01 02:00:00 in "field_publish_until" field. This may be something to do with datefield default values in PW 2.4...

[apeisa]

Something like here? https://processwire.com/talk/topic/711-release-schedulepages/?p=54304

[juhis]

Thank you, that fixes the problem and as mentioned PW 2.4 now delete those fields containing 1970's timestamp. Strangely though in PW version 2.3 those pages did not get unpublished but in 2.4 they did. 

[NorbertH]

Anyone tested this whith 2.5?

At least the installer says :

This module does not indicate compatibility with this version of ProcessWire. It may still work, but you may want to check with the module author.

[Martijn Geerts]

@NorbertH, already tried it on 2.5? If not you should do  

[NorbertH]

Just done it , seems to work whitout any problems.

Maybe the author should update the module directory or the dependencies?

[berechar]

Just installed it and it works like pure magic

Just out of interest, I still don't quite grasp the workings of the module and (especially) the LazyCron module.

I schedule a post, say [05.05.2015 @ 15.00] with a lazyCron on [Every hour]. My aim is to publish the post that exact date.

LazyCron is lazy because it is triggered by a pageview of the main website. (or also admin? or both ;-)... )

Does this mean that once you visited the site, you trigger the lazyCron, it runs the Schedule Module,  and then it waits for an hour for the next page-view trigger? Is this hour then on the 'whole hour', or specificly on the first time the site has been viewed.... I don't get it haha.

* btw – do you really need to specify an unpublish-date? I actually never want to unpublish

** btw 2 – is the timing of the cronjob and the scheduled pages based on the clock of the hosting server? So if the hosting is in Country A, but I need to publish in the morning for Country X, I should somehow change the (lazy)cron-job timezone?

Kind regards!!!

[LostKobrakai]

I schedule a post, say [05.05.2015 @ 15.00] with a lazyCron on [Every hour]. My aim is to publish the post that exact date.

That won't work with LazyCron, see below.

LazyCron is lazy because it is triggered by a pageview of the main website. (or also admin? or both ;-)... )

Both.

Does this mean that once you visited the site, you trigger the lazyCron, it runs the Schedule Module,  and then it waits for an hour for the next page-view trigger? Is this hour then on the 'whole hour', or specificly on the first time the site has been viewed.... I don't get it haha.

Exactly. LazyCron does not care about which function you hook to it. On every pageview it reads a file, which holds a timestamp for each available interval you can chose. If the timestamp is older than the interval it updates the timestamp and executes the functions for that interval. So if the timestamp for "1 hour" is older than one hour it will run the function, no matter of which time it is. Therefore it's dependent on when pages are viewed and therefore also changes each time the update happens later than an hour after the last update.

do you really need to specify an unpublish-date

Not if you don't need it.

is the timing of the cronjob and the scheduled pages based on the clock of the hosting server? So if the hosting is in Country A, but I need to publish in the morning for Country X, I should somehow change the (lazy)cron-job timezone?

You specify the timezone that ProcessWire uses throughout the whole system in the config.php in the site folder. 

[berechar]

Ah I see.

So would that mean that when you have a lazyCron set on [Every Hour], there's the maximum possibility that it will be triggered 59 minutes after your chosen time? Thus shortening the interval, [Every 30/15/5 minutes],would make it's activity frequency higher and shortens this gap. With the downside that it's being triggered more often, thus resulting in more 'useless' updates...

You specify the timezone that ProcessWire uses throughout the whole system in the config.php in the site folder.

great! thank you so much!

[LostKobrakai]

Theoretically it could be the case that the last update (by page-view) is a minute before your publish time. Now with the LazyCron hook set to [Every Hour] the earliest time of publishing would be 59 minutes late, while the latest time is anytime the next page-view comes in. This could even be many hours later on an infrequently used page. Lowering the interval only shortens the first variable, not the second one. There's no 100% guarantee the cron will run in any maximum timeframe. 

Lowering the interval will not result in any more "overhead" as the file with the timestamps will be updated for any interval on each page-view. Each interval is updated independently from each other. It just updates if it's (over)due.

[berechar]

The fact that a lazyCron on [every minute] doesn't produce more overhead then [every hour] is music to my ears Thank you for explanation!

[berechar]

I'm currently finding quite unexpected behaviour with the module, it seems to disable the 'view' option... The button/option simply just vanished...

But when you change the page to [unpublished] and save, you can 'view' it again. But when you publish it again (or publish AND hide) it disables the 'view' option again. So the page seems to become 'corrupt'. When I copy all it's content to a new page and just publish it, everything is fine. I'm running ProcessWire 2.5.3 © 2015, maybe there's an issue?

The only thing what I maybe do differently from the default, is that I've made a page-save-hook which populates the publish_from field with another date field, and appends a timecode (eg. 08:00:00).

I first thought this might be an [user] issue regarding the permissions, but everything worked fine [before] the automatic-publishing.

* * * EDIT 1 * * *

After much debugging, I think I found the answer.

I disabled the page-save-hook which fetched the [date] field and populated the [publish_from] field with an added timestamp (08:00:00). This seemed to 'corrupt' the page, disabling the option to view when published. Conclusion: I think the type of input became a string instead of a date

* * * EDIT 2 * * *

For anyone interested to prevent yourself from headaches, this is how I end up building a working datetime to work with SchedulePages.

$pageDate = date("Y-m-d", $page->getUnformatted("date") );
$publish_from = date( $pageDate . ' 11:00:00');
$this->message( $publish_from );
$page->publish_from = strtotime($publish_from);

[berechar]

I though I had resolved this, but the following happenend.

Everything works fine when the publish_from datetime is set for the current day with a timestamp that yet has to come on the same day.

But, whenever I schedule a page for the following day (so I schedule it before 00:00am), and it needs to be published in the morning, it makes the page corrupt again... not viewable

So weird... I though the strtotime($date) worked...

[LostKobrakai]

Have you tried just disabling your hook and changing the two module's fields to show the time, too?

[formmailer]

Hi!

I just wanted to let you know that I have very little time right now (many projects), but will take a look at the module when I have time again. If you happen to find a solution for your issue, please post it here, so that I can update the module as soon as possible.

//Jasper

[berechar]

I've disabled the hooks (thus reverting to 'manual control'), and everything works with no unexpected behavior. So it definitely has something to do with how I was populating automatically. Should I format the Datetime string differently for the [publish_from] field? No 'Y-m-d hh:mm:ss' ?

[Michael van Laar]

Following this discussion I forked the module and added a new option:

Always use “Publish From Date” field to store publishing timestamp

If the new option is set to “Yes”, the publish_from field is automatically filled with the current timestamp in case a page is published manually. This way the publish_from field always contains a page’s publishing date – even if there was no scheduling via the publish_from field.

This mimics the publish date field behavior of WordPress and is extremely handy if you use the publish_from field in a blog’s front end template.

I made a pull request: https://github.com/formmailer/SchedulePages/pull/8

[formmailer]

Great idea. Thanks!

I just merged the pull request. 

//Jasper

[Michael van Laar]

Just an idea: Shouldn’t the publish_from field be cleared automatucally as soon as an already published page is unpublished manually? If the old publish_from date stays in the field, a manually unpublished page will thus be unintentionally re-published on the next cron run.

[formmailer]

Just an idea: Shouldn’t the publish_from field be cleared automatucally as soon as an already published page is unpublished manually? If the old publish_from date stays in the field, a manually unpublished page will thus be unintentionally re-published on the next cron run.

Makes sense...

To be honest, I am not using the module myself and it has been a while since I wrote it. I don't know when I'll have time to change this.

But of course, feel free to make another pull request if you have time.

//Jasper

[Michael van Laar]

OK, I’ll do.

This is the typical procedure when I create a website: I consider way too many edge cases ;-)