SCHEDULE PAGES not for PW3?

[saschapi]

Hi guys,

I'm looking for the not so uncommon functionality to publish (or "un-hide") pages on a specific date and time. I did not notice till now, but this functionality seems to be missing from the core.
Scheduled pages seems to do just that but is not supported for PW3... Is there really no module or function that publishes pages in the future? I know that I need to setup a cron job or use lazy cron, but I'm wondering if I miss something? :)

Cheers Sascha

[elabx]

Hi @saschapi! I'm not aware of a module that enables this along with lazyCron but you could try placing something like this under site/ready.php

$wire->addHook('LazyCron::everyDay', function($e){
    $posts = $this->pages->find('status=unpublished, template=post');
    
    foreach($posts as $post){
        if($post->schedule_publish_date <= time()){
            $post->of(false);
            $post->status([]);
            $post->save();
        }
    }
}); 

The page template you want to publish, would have a schedule_publish_date field, where you can set a publish date and time. 

[3fingers]

Even though not officialy supported by PW3 I've used this module in the past successfully:

https://processwire.com/talk/topic/711-release-schedulepages/

[teppo]

Another SchedulePages user here. Works just fine for PW3 ?

[Zeka]

Same here.

[elabx]

So I'm the looser coding my hook on every site ?

[dotnetic]

You could also do this with a simple page selector, which would be the simplest solution:

So all your pages have the status Published, but will not be shown, because the event_start field is lower than the today date.

$events = $pages->find("template=event, sort=event_start, event_start>=today");

The hook from @elabx is really overkill and modifies the page, which is not needed.

[teppo]

59 minutes ago, Jens Martsch - dotnetic said:

The hook from @elabx is really overkill and modifies the page, which is not needed.

To be fair publishing (or un-publishing) pages at set time vs. just listing pages based on a datetime field are two different use cases. In some cases the distinction may not matter, but in others it will — i.e. when something really shouldn't be viewable before a predefined date/time ?

[dotnetic]

I think my answer solves the problem, that the topic poster wanted to solve. Sometimes you have to think outside the box, and I think he just wanted to know how to not show pages that have a publish date in the future. What first comes into mind is: Leave the page unpublished until the date is actual. 

That you can tackle this problem differently may not be obvious. But you are right @teppo that there might be other use cases, for example if the page url should not be reachable at all, then the published or unpublished status would be the right thing to do.

[Robin S]

1 hour ago, teppo said:

In some cases the distinction may not matter, but in others it will — i.e. when something really shouldn't be viewable before a predefined date/time

For 90% of these kinds of cases I do it like @Jens Martsch - dotnetic suggested, and in the template of the page (event, news item, etc) I have:

// Throw 404 if item is future-dated
if(!$user->isLoggedin() && $page->getUnformatted('date_1') > time()) throw new Wire404Exception();

But on a complex site where the pages might be queried from many selectors in many different places then unpublishing is the way to go.

[teppo]

That works as well!

Main reasons I don't (practically) ever use this approach have already been mentioned here: I'd have to block access on template level (may need to do that on a lot of places), search features and highlight lists etc. all have to be aware of this, and so on and so forth. Potentially having multiple developers work on the site doesn't really help either. At some point you're very likely to show publicly something you didn't intend to.

Want to schedule pages? install SchedulePages. Need more scheduled content? Add two fields to the template. Easy as it gets ?

Also, as a general rule if thumb, I try to do as little permission/access checking myself as possible. Sure, in this case it's probably not a big deal, but... ?

"ProcessWire — there's more than one way to do it" ✌

[saschapi]

Hi guys,

thanks for the great input. I will have a look at the plugin, but I guess @elabx solution would be more flexible in my case.

This might be the way to go! ?

Cheers Sascha

 

[Violet]

I'm coming in late to this discussion sorry. A huge thank you to @Christophe for bringing this thread to my attention. I had a strong need for the Schedule Pages module but was hesitant to use it on my PW 3.x site as the documentation was unclear whether it is compatible for 3.x. But the comments above from @3fingers, @teppo, and @Zeka seemed encouraging about the safety of using Schedule Pages on a 3.x site.

So finally I decided to install it on one of my 3.x sites and I can attest it worked perfectly! Be aware that my test case is a simple one: my site GoodKidsClothes.com doesn't have anything unusual about it from a development perspective - it's a blog that has been going for several years and has a decent amount of content, but there's nothing complex. It displays articles I've written. Extra details about my experience installing and testing Schedule Pages are shown below.

Firstly I do want to point out that the manual solution of clicking the publish button on the page on the correct day is technically do-able, but is not ideal in many situations, and certainly not in the situation where I would use it. On those occasions, which fortunately are not frequent, this has entailed me getting up at 3am to press the "Publish" button (explanation below). So yes, it's do-able, but not ideal.

Here is the real-life use-case I'm talking about: a brand I am promoting wants my article to come out as early as possible on day x. This means timezone has an effect. "As early as possible on day x" for a U.S. brand really means 3:01 a.m. US Eastern Time (= 12:01am US Pacific time) on day x. I cannot just publish the minute it turns to the next day here on Eastern Time because that is still the day before on Pacific Time. For brands that have time-sensitive news and deals, I am not allowed to leak it the day before, even if I'm in another time zone than the leak. A breach in trust like that is serious and would result in the brand severing any relationship with my site.

So it's not just the day, but also the time, that is critical here. I can attest that Schedule Pages works fine on all counts. When I installed the SchedulePages module, it did come up with a warning:

However, I carried on with the install and it all went fine and the module worked perfectly. A huge thank you to all of those who posted above, and especially the people I mentioned personally in my comment here, as it inspired me to try the SchedulePages module. You've all literally saved me from a 3am wakeup next week for a post that needs to be scheduled ??? I'm sure all the other solutions people mentioned would have worked fine too, but I like to use modules to limit the amount of custom coding I need to add on my own.

A couple of points to note about SchedulePages (besides what others have said):

• For first-time users, while the date picker is straightforward, the time entry part of it to schedule the post might be a little bit confusing. It certainly took me a few tries to work it out. The default time on the field says something like hh:24:11:ss , but basically you should just enter whatever 24-hour time you want like this: 14:34 (I didn't worry about adding seconds, and it just set seconds to zero).
• For others such as myself who have time-critical needs, SchedulePages seems to take it from timezone of the site (site/config.php ?), which is what you'd typically want, and not from the server time. I tested out the module using same-day and next-day scheduling. My server time is US Central Time, and my site is in US Eastern Time according to site/config.php. Based on setting my LazyCron to 5 min intervals and testing my schedule pages publication times, it looks like the time is being taken from my site time (US Eastern), which is exactly what I want, and not from my server time (US Central time).