Michael van Laar

Anyone has experiences with substituting the CKEditor JS-part with a newer version? I’d like to try CKEditor 4.5 Beta because it finally allows nested widgets – which could be key for easy creation of some advanced content pieces (like acordions, tabs, etc.) right inside the usual body copy field. But I have not dealt with modifying ProcessWire’s CKEditor module yet.

Thank you! That’s it. I should read the cheat sheet more conscientiously. In combination with adding an additional hook before the $pages->save it works like a charm. Pull request for module version 1.2.1 is already out: https://github.com/formmailer/SchedulePages/pull/9

Hm, I just realize that I can only check if a page is saved as “unpublished”. But I can’t catch that moment when a published page is saved for the first time with the “Unpublished: Not visible on site” checkbox checked, so that the page is now unpublished. Or can I? If I add the rule I thought of (see below), this would mean that saving an unpublished page – whether it has ever been published or not – with a publish_from date which is older than the current timestamp. if ($page->is(Page::statusUnpublished) && $page->template->hasField('publish_from') && $page->publish_from < $currenttime) { $this->session->error($this->_("“Publish From Date” field was cleared because it contained a date which lies in the past. This would have caused the page to be (unintentionally) published resp. re-published on the next Lazy Cron run. Obviously this was not your intention since you chose to only save and not publish the page.")); $page->publish_from = null; $page->save('publish_from'); } As a consequence a user would no longer be able to save a new page as “unpublished” with a publish_from date which lies in the past. Comparison: With the current version of the module this new and unpublished page will be published resp. re-published on the next cron run. With the additional code above the publish_from field is cleared, the page will thus remain unpublished and an error message informs the user about what happend. I think this behavior is more logical than the current one. But it definitely changes the way the module handles publishing dates from the past on unpublished pages. So if some users rely on the present behavior as part of their workflow, they would have a bit of a problem.

OK, I’ll do. This is the typical procedure when I create a website: I consider way too many edge cases ;-)

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.

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

Because I think that this should be a feature of the Shedule Pages module, I forked the module, added an option (so that this feature can be turned on optionally) and made a pull request: https://github.com/formmailer/SchedulePages/pull/8

Works like a charm. I made minimal modifications to make it work without the rest of the Blog Module: https://github.com/MichaelvanLaar/PW-AutofillPublishFromDate My version of the module simply does its job for every page which has a publish_from field which is installed with the Schedule Pages module.

Yes, date/time fields have this option. But since the publish_from field is part of the “Schedule Pages” module, this would result in not being able to save a new article without publishing at all. That’s why I implemented Kongondo’s solution today.

Great advice! Thanks a lot