Scheduled Publishing with Workbench Moderation

PreviousNext recently built the same functionality for a client project using Rules & Rules Scheduler modules.  This proved rather difficult to implement;   Workbench Moderation also allows content with a published revision to have a more recent current revision in a “draft” or “review” state while content editors are working on it, and Rules does not provide sufficient transparency to easily understand & debug a number of tricky edge cases:

• If a content item is scheduled to be published but it already has a published revision, the current revision should become the published revision on the scheduled publishing date.
• The content’s Workbench Moderation history should be clean and easy to audit;  There should only be one log entry per scheduled event.
• Should the (un)publishing-dates act on revisions or nodes?  Should the date-time values be stored per revision or per node?  If revisions, do the published revision's dates preside over the current revision's dates?  Can content that is about to be (un)published still be easily exposed to content managers via the Views module and ordered by the date-time of the scheduled event?
• Should scheduled dates be removed from the content at or after processing?  At exactly which point in the process?  How can an audit trail of executed scheduled (un)publishing be provided?
• If both publish and unpublish scheduled events get executed on the same cron run—perhaps because an editor scheduled them very close together and/or cron has not been running for a while or is not frequent enough—does the content end up being unpublished?  Workbench Moderation calls node_save() content with a published revision in an "asynchronous" drupal_register_shutdown_function()-callback, which makes this a rather difficult edge case to handle.  Additionally;
• Workbench Moderation's node-history table should always be consistent with with the node table;  Only nodes that have node.status = 1 should have a row in workbench_moderation_node_history where published = 1 and vice versa.  And workbench_moderation_node_history should only have one row where current = 1. And that should refer to the most recent revision.
• Should an editor be able to scheduled already-published content to become unpublished for a specified period?  Or only the opposite?
• If content is manually (un)published before a scheduled (un)publishing, are the respective scheduled events ignored on cron?

The list goes on.

For a more recent project we found Scheduler Workbench module much easier to work with than a Rules-based implementation, since all of the functionality is clearly defined in unambiguous code, rather than abstracted through configuration.

PreviousNext contributed several patches to the module to fix some bugs, handle some of the edge cases and generally get the module more stable.  All of these patches have been committed upstream already—thanks William Hurley (whurleyf1)!

Another patch for Scheduler is still in the queue and is required for Scheduler Workbench to function correctly.  See #1660252 “Publishing transitions twice through draft” on drupal.org for more detail.

Another bonus about Scheduler and Scheduler Workbench modules is that it does not require a cron-management module like Elyisia Cron, as you can call Scheduler module's own cron callback without invoking Drupal's full cron.  This is important because calling Drupal’s full cron too frequently causes performance issues, while calling it too infrequently means scheduled (un)publishing events are often “late”.

Scheduler Workbench can also be configured in such a way that it handles content "freshness" requirements.  PreviousNext has found that many Australian government organisations regularly audit their content.  In some cases content should even become unpublished if staff have not been marked the content as reviewed within about one year of it being published.

PreviousNext also implemented a Rules-based solution of content freshness for our client project.  The default review period is set per content type, but the exact expiry date can be overridden on an individual content item’s “review by” date field.  If a content item is not manually updated or “marked as reviewed”, it can be configured to become unpublished and marked as “needs review”, or just marked as “needs review” but left published.  And the default value for this option is configurable per content type.

Scheduler and Scheduler Workbench modules can be configured to implement a significant portion of such “freshness” requirements.