Using Workbench Access/Moderation, Scheduler does not unpublish.

I had the same problem. The current unpublish function does only change the state.

To solve this problem, I added the following function to scheduler_workbench.module :

function _scheduler_workbench_scheduler_pre_unpublish(&$node)
{
    if ($state = variable_get('scheduler_unpublish_moderation_state_' . $node->type, FALSE)) 
    {
        //If there's no published revision, skip
        if (isset($node->workbench_moderation['published'])) 
        {
            //Remove published flag from history and node revision
            db_update('workbench_moderation_node_history')
                    ->condition('hid', $node->workbench_moderation['published']->hid)
                    ->fields(array('published' => 0))
                    ->execute();

            db_update('node_revision')
                    ->condition('nid', $node->nid)
                    ->fields(array('status' => 0))
                    ->execute();

            //Remove the published revision for workbench_moderation_moderate
            //to skip workbench_moderation_store shutdown callback
            unset($node->workbench_moderation['published']);
            
            //Prevents creating new revision
            $node->revision = 0;
            
            workbench_moderation_moderate($node, $state);
            
            //Force workbench to update live revision
            $node->workbench_moderation['updating_live_revision'] = TRUE;
        }
    }
}

And removed the _scheduler_workbench_scheduler_unpublish which is useless.

EDIT : It would be good to add a condition with the following code :
variable_get('scheduler_unpublish_revision_' . $node->type, 0)

in order to take into consideration the "create new revision" option during unpublishing.

Patch based on how workbench_moderation's form unpublished the live revision

The patch...

Fixed means the patch has been committed. Please see th Issue queue handbox about status and priorities (linked to below the said fields on the comment form)

I can confirm that this issue exists and that patch #3 fixes it.

Patch #3 fixes this issue. Thanks.

Yes, the patch in #3 also worked for me. I tested it using "Create a new revision on unpublishing" checked and unchecked. It worked for both! Thank you.

If you publish and unpublish a node in the same cron job this does not work.

Setting node->revision to 0 is hacky because in reality revision = 1;

New patch attached. Works with both "Create a new revision on unpublishing"/"Create a new revision on publishing" checked and unchecked.

Key thing is to remove workbnech_moderation_store() call that workbench_moderation_moderate() and workbench_moderation_node_update() adds to drupal_register_shutdown_function(). What this does is resave the published node at the end of the page load. (took me forever to figure this one out).

Code is much cleaner I believe as we let node save all on its own (no pre stuff) then make the changes to workbench_moderation.

Other note: The variable get if state was defaulting to FALSE when it should be to workbench_moderation default publish/unpublish states.

Forgot to change state to needs review

Maybe this is related to #1436260: Saving nodes outside Workbench Moderation leads to incorrect state transitions (e.g., "needs review" appearing as published)? That issue solves a bug in Workbench Moderation which caused problems with publication states. It's been quite some time ago so I might be mistaken on this.

I read through #1436260 and it would appear that it would help, but it does not. Attached is a screenshot of using workbench_moderation with patch #74 and no patch to scheduler_workbench. Used latest dev version of Scheduler too.

Tested:

1. unpublished node with the same publish and unpublish date set, with "Create new revision" (Test 17)
2. published node with unpublish date set, with "Create new revision" (Test 18)
3. unpublished node with the same publish and unpublish date set, without "Create new revision" (Test 19)
4. published node with unpublish date set, without "Create new revision" (Test 20)

Found one more problem. After the node is published, in _scheduler_workbnech_scheduler_publish() we call workbench_moderation_moderate(). This sets the published node's node revision status to 0. It plans to set it back to 1 on shutdown. We unset shutdown so we have to do it manually.

#14 Works great, thanks.

I agree. #14 is unpublishing my nodes correctly.

I spent a couple hours working with this patch and scheduled publication of moderated nodes, and it looks like, while this patch does help with unpublishing, it breaks the ability to have nodes published via scheduler correctly. Workbench needs to run it's magic in shutdown to get nodes published correctly, and this patch removes Workbench's ability to do so...

To be more specific, this is a little more 'edge case', but here's the process that fails with this patch:

• A scheduled node is published during cron run
• Using rules or custom code, other nodes related to the scheduled node are also manually published through workbench
• The initial node is, in fact, published, but none of the other nodes are, since the shutdown function for workbench was removed

@geerlingguy, its been a few months since I looked at this, but this should still be accomplish with rules. node_save() gets fire on the correct node, then you should be able to hook into that.

in the shutdown, node_save gets run a second time on the same node, just to save it as the live revision. The re-save in shutdown is an ugly workaround, and should never have ever been implemented. It breaks multiple of other contribs. In the future it is probably going to be taken out.

Currently patch works, so I think I can RTBC.

I respectfully disagree :)

in the shutdown, node_save gets run a second time on the same node, just to save it as the live revision. The re-save in shutdown is an ugly workaround, and should never have ever been implemented. It breaks multiple of other contribs. In the future it is probably going to be taken out.

We shouldn't build patches based on hopes/wishes—currently workbench does the re-save, and yes, it is terrible, ugly, and the cause of hundreds of wasted developer hours per month. And AFAICT, the shutdown function is going to remain for some time (is there an issue stating otherwise?), and if we break the (sad, annoying, but necessary) normal way Workbench Moderation works in this patch, it still needs work so it won't do that.

I've done a lot more testing over the weekend, and the patch breaks my use case, which is publishing related workbench-enabled content when a particular workbench-enabled node is published via scheduler. It works fine without this patch (which does seem to help with unpublishing, don't get me wrong!), but with this patch applied, workbench leaves all the related nodes (which are published using something like workbench_moderation_moderate($node, 'published');) in an inconsistent state, since the shutdown function doesn't finish publishing them.

And if you still think it's fine as-is, needs review would still be more appropriate, as I think we need more people to test this patch and make sure it doesn't break other workflows (plus, no RTBCing own patches ;-).

One other, slightly unrelated note: I'm getting the following errors when this patch is applied when publishing multiple nodes as per the test conditions above:

Illegal offset type in unset scheduler_workbench.module:213

@geerlingguy what rules are you using?

This is custom code; just adding in hook_node_update():

• If the node is of xyz type and is now published (e.g. $node->workbench_moderation_state_new === 'published'), find all related nodes.
• For each related node, if it's unpublished, publish it too: workbench_moderation_moderate($node, 'published');

Without this patch, all the related nodes are published when scheduler publishes a node that has nodes related to it. With the patch, the related nodes are half-published. They get status set to 1 in the node table, and they're published according to Workbench Moderation, but the latest record in node_revision is still set to 0.

Therefore, when the node is loaded by Drupal, $node->status is 0, meaning the nodes are inaccessible to users without admin privileges, don't show in views with the 'published: true' filter, etc.

Full example:

/**
 * Implements hook_node_update().
 */
function mymodule_node_update($node) {
  if ($node->type == 'xyz' && ($node->workbench_moderation_state_new === 'published')) {
    $wrapper = entity_metadata_wrapper('node', $node);
    $referenced_nids = $wrapper->field_node_reference->raw();
    foreach ($referenced_nids as $nid) {
      $referenced_node = node_load($nid);
      workbench_moderation_moderate($referenced_node, 'published');
    }
  }
}

There is a problem with the patch

  $callbacks = &drupal_register_shutdown_function();
  foreach($callbacks as $callback) {
    if ($callback['callback'] == 'workbench_moderation_store') {
      unset($callbacks[$callback]);

Here unset($callbacks[$callback]); will not work in case $callback is a array, and the will lead to the error:

Illegal offset type in unset scheduler_workbench.module:213

So, I think workbench_moderation_store was still being called in shutdown.

I think how it should be is

  $callbacks = &drupal_register_shutdown_function();
  foreach($callbacks as $key => $callback) {
    if ($callback['callback'] == 'workbench_moderation_store') {
      unset($callbacks[$key]);

I am having a very similar issue, see https://www.drupal.org/node/2652434.

We have been running the patch in #14 successfully for about two years.

The problems reported in #19 and #23 are not yet addressed. This patch still needs work.

Here is a re-roll that includes the change suggested in #23. It does not address the issue rasied in #19.