Nodes not publishing after Cron - conflict with Workbench Moderation

Hi rondog469,

You are doing the right thing, and this module should behave in a similar way to D7 from the users perspective. Can you run your test again but before you run cron could you visit admin/content/scheduled and note if your node is showing as scheduled for publishing (and that it is not also scheduled for unpublishing. Then run cron after the publish-time has passed and visit admin/content/scheduled again, to see what it shows.

Secondly, when you edit the node after it has failed to get published, is the 'publish on' date still set, or is it removed?

Thirdly, are you sure this is not a cache problem? The node cache should be cleared when the content is published, but something might be stopping that from working.

By the way, what core verson are you using?

Jonathan

Well, it's a mystery how your site has fixed itself, but at least everything seems to be working correctly now. Thanks for the screen shots.

If you notice it going wrong again then come back and update this issue.

Jonathan

If you're still up for troubleshooting this one, I've got the same issue!

- Set a date to publish the unpublished node and save.
- The node shows up in /admin/content/scheduled with the correct 'Publish On' Date/Time and nothing in the 'Unpublish On' column
- After the time has passed, I run cron.
- Scheduler adds a watchdog entry 'Blog Post: scheduled publishing of [node title]'
- This node disappears entirely from /admin/content/scheduled
- This node is still unpublished and the Scheduled date setting has disappeared

I've tried running cron all around these steps but same results every time.

Setting to "Needs work" since there is no patch to review.

@christiemade, can you perhaps share the modules you have enabled in your project? It could be that there is some kind of interaction happening with another module that prevents the nodes from being published.

Looks like src/SchedulerManager.php:180 sets the publish_on value to NULL for the node that being scheduled, and src/SchedulerManager.php:207 saves the node without this value (to prevent the node from being rescheduled again). However, in scheduler.module:345 there's a node presave hook which checks if the node has the publish_on value set, and if it's not, it sets the node's published status to false (scheduler.module:374). I uploaded a patch which publishes the node before saves it in ScheduleManager, but I have doubts that it's the right place to be. It worked for me on local after running the cron.

I've confirmed it is another module interfering - it is 'Workbench moderation'
I've also confirmed that @herczogzoltan patch in #11 WORKS with Workbench moderation still enabled.
Huzzah!

Great news! Seems like we have a working solution. This could still use a test on our end to ensure that this won't regress in the future.

I'm not sure what the problem is on #3022245: compatibility Workflow and Scheduler but the patch on that issue is making the same change in SchedulerManager() as the patch here, so this might be related. It might also give more information on what is going wrong.

Long standing issue, never commited unfortuantly.
Here is a reroll for 1.2.0, Wir are carrying this patch for moths now in the composer.json of our LIVE systems.

Looks like we need a test here, @pfernssen can you briefly share how should this be tested? I can write some tests in my spare time. :)

I am nudging this thread. I am experiencing the same random issues as described in comment #11.

For reference, my project:
- Drupal 8.7.7
- Acquia Lightning 4.0.4
- PHP 7.2.21

Hi ejanus,

I am experiencing the same random issues as described in comment #11

Is it actually random? It seemed from christiemade in #13 that it is a conflict with Workbench Moderation. Do you have that module installed?

We need a list of steps to reproduce the error from a clean drupal install before we can attempt to fix the code. We can't write tests until we know why the code is wrong, not just that a particular line change fixes it for some circumstances.

jonathan1055, thank you for keeping an eye on this. As soon as I have some time to dig into this more on my end and isolate the steps to reproduce as well as isolate the cause of the particular anomalies, I'm going to come back and provide that feedback.

I did notice we have the Scheduled Updates module installed and applied to one of our content types. Although, it is not used anymore and we will remove it in the future.

We currently use the scheduling provided by the lightning profile as described in their documentation:

The Lightning Scheduler module is a content scheduler component of the Lightning Workflow suite. This collection of modules enables you to extend the Workflows and Content Moderation modules (packaged with Drupal 8 core) to build and customize workflows supporting your organization’s custom content types and publication needs.

I couldn't get either patch to apply running Workbench Moderation 8.x-1.5 and Scheduler 8.x-1.1.

I know that Workbench Moderation is deprecated, but, for those like me who haven't been able to allocate time to getting rid of it, I need this patch.

I'm rerolling it against Scheduler 8.x-1.1 in case anyone needs it.

Hello, @all I have shared this patch it is working for me. hope it will work for you guys also

I had been running the patch in #21 with 8.x-1.1 successfully. In my env, though, I have Workbench Moderation but I am using Scheduler on a content type that is NOT using moderation.

When I updated from 8.x-1.1 to 8.x-1.3, scheduled publishing stopped working, but unpublishing _did_ work correctly.

Neither the #21 patch nor the #22 patch solved my issue and so I reverted back to 8.x-1.1 with patch #21.

I don't have time to dig deeply into this right now, but when my time frees up, I'll check back here for developments or to participate in a solution. In any event, I at least wanted to share this info.

We use workbench moderation and workbench moderation actions. We haven't needed to use this patch before, but we were using this patch #3038046: Cater for workbench_moderation_actions module removing node_publish action to support workbench moderation actions with scheduler 1.1.

When we upgraded from scheduler 1.1 to 1.3, all our scheduled publishing functionality stopped working.

I tracked the cause back to this patch #2824038: Node is saved twice.

Adding node->save() back in fixes it for us.

I haven't looked in to why this is happening or whether this only happens with WBM, but I assume it must be working as-is for non-WBM users as I can't find any related issues in the queue.

Longer term, I'm not sure if this is an appropriate fix or whether something else will be needed to ensure it works for WBM users and non-WBM users without doing an extra save. But at least if you use WBM this should get you back up and running on 1.3 for now.

Hi nicrodgers,
Thanks for this. Do you know if removing that extra save in #2824038: Node is saved twice only affected those with WBM Actions? Or it is a problem if you just have WBM? That other issue was started in Nov 2016, but this one was only started June 2018.

If your patch does solve this issue I'd be OK with adding it back, inside the conditional

if ($this->moduleHandler->moduleExists('workbench_moderation_actions'))

which we already have on the next line.

I don't think it's specific to WBMA, but would apply to anyone using WBM. I didn't have much time on the project last week so couldn't confirm either way, so it'd be great if anyone else could clarify.

We upgraded from scheduler 1.1 to 1.3, and now scheduled publishing isn't working.

We're on:

• Drupal 8.9.2
• Scheduler 8.x-1.3
• We are not using workbench.

Here's what I did to test today:

• I created a blog post and scheduled it to publish in 30 mins.
• I ran cron to ensure that the post would publish at the scheduled time.
• The post was listed in the Content > Scheduled. The “publish on” date and time was 08/04/2020 - 12:01.
• I checked at 12:04 and the post did not publish at its scheduled time. It was still listed as unpublished on the “Content > Scheduled” page.
• I cleared the cache, then refreshed the “Content > Scheduled” page and the post was still not published. The “publish on” date and time was still listed as 08/04/2020 - 12:01.

I'm not sure which patch (if any) apply to a site not using workbench, but where scheduler isn't working. Should this be a new issue since it isn't a workbench conflict?

We are not using workbench.

Should this be a new issue since it isn't a workbench conflict?

Given that this issue is all about conflict with Workbench Moderation yes, you'd be better off making a new issue.

@jonathan1055 In answer to your question in #25 I am not using WBMA, just WBM by itself and am getting this same issue on 1.3. The patch from @nicrodgers works for me.

I'm coming back to this since I need to get ready for Drupal 9.

I am using Workbench Moderation (8.x-1.6) but not Workbench Moderation Actions.

I had been running Scheduler 8.x-1.1 with patch #21 only because the subsequent patches were not working.

I just upgraded to Scheduler 1.4. I have a content type which does NOT have workflows enabled for it. While I am getting all the expected alerts and log entries about scheduling happening and scheduled publishing, the content remains unpublished. I've modified my prototype according to the patches; adding the node save and injecting the setPublished, but still doesn't work.

I'll continue to poke at this to see if I can find a solution.

similar to #30, I'm not using the WBMA, just WBM, and had the issue of nodes, remaining unpublished. Saving the node similar to patch #24 works but I had to create a new patch for Scheduler 8.x-1.4.

Drupal 8.9.17
Scheduler 8.x-1.4
workbench_moderation 8.x-1.6

This might actually be an upstream issue in workbench_moderation after all. I'm using the patch over in this issue queue https://www.drupal.org/project/workbench_moderation/issues/3238576

The wrong action plugin was being loaded. So when you were trying to publish a node, the unpublish_action was loaded, hence it was unpublished! That probably makes patch #24 redundant? I'm using that patch too but don't have time to test getting rid of right now.

Thanks @achap for linking to that issue, it looks like a definite typo and could well be the cause of our problem.

I was not intending to commit either patch #24 or #31 here as neither of those felt the right thing to do in Scheduler.

If anyone else following this thread could test the patch on #3238576: Unpublishing content instead of publishing it and report back, that would be helpful.

I have commented on #3238576: Unpublishing content instead of publishing it again, as that bug does contribute to the problems reported here. The situation is complicated by the fact that (1) some users have Workbench Moderation only, whilst others also have Workbench Moderation Actions, and (2) the outcome of scheduling moderated nodes is different from non-moderated nodes.

Workbench Moderation is installed but not Workbench Moderation Actions

Non-moderated nodes should get published by Scheduler but they are not. This is due to the bug in the above issue. The scheduled publish_on date is removed, so it appears that the node has been processed, but the status remains unpublished.

Non-moderated nodes can be scheduled for unpublishing and this works fine, because the bug did not change the unpublish action.

Moderated nodes will not get processed by Scheduler at all because they are explicitly skipped via WBM Plugin/Action/ModerationOptOutPublishNode::execute and similarly for unpublishing. To schedule moderated nodes you need install WBMA ...

Both Workbench Moderation and Workbench Moderation Actions are installed

Non-moderated nodes are not being processed by Scheduler because WBMA exits out of the StateChange::execute early if the isModerated flag is false. Nothing is done, but the date remains on the node and the publishing is attempted again and again on each cron run. In the past, if non-moderated nodes were being processed ok by Scheduler then it was due to the quirk of having the extra save, which has now been removed between Scheduler 8.x-1.1 and 1.3.

Moderated nodes are processed ok via Scheduler, and these do not need the extra save because the WBMA execute does a $entity->save() as expected. (There may be a problem with permissions not being set for anonymous during cron, and had to temporarily allow anon user all of the moderation transition permissions, but that's a separate issue.)

The problem with non-moderated nodes requiring the extra save() when WMBA is installed can be worked out, I'm sure, either in Scheduler or in WBMA code.

[Note: all the testing above was on the Scheduler 8.x-1.x-dev branch. The 2.x branch may have slightly different outcomes .. that needs testing next]

@jonathan1055 Thanks for looking into it. I have some automated tests setup for the project I'm working on to test scheduled functionality for both a moderated and non-moderate node and found exactly the same thing as you. Also on the 8.x-1.x-dev branch

I tested removing patch #24 and keeping the workbench_moderation patch and it did indeed break the scheduled publishing/unpublishing functionality on moderated nodes. Non-moderated nodes that were scheduled were still working until I installed the WBMA module to try and get moderated node scheduling working. Now neither works :P I didn't have time to dig too deep into it but it did indeed seem to be permissions related for scheduling moderated nodes with WBMA.

Moderated nodes will not get processed by Scheduler at all because they are explicitly skipped via WBM Plugin/Action/ModerationOptOutPublishNode::execute and similarly for unpublishing. To schedule moderated nodes you need install WBMA ...

Would it be feasible to get scheduling for moderated nodes working with just WBM? Ideally I wouldn't want to install another a module.

Happy to help with a patch(s) but not really sure in which direction to start or what needs to be fixed where.

Thanks achap, good to hear that our testing and deductions match up.

The issue of non-moderated content not being processed properly by Scheduler when WBMA is installed should be fairly simple to fix, in either that module or in Scheduler. If need be, I can add an extra $node->save() just when WBMA is installed (but there may be a more elegant way to solve it).

In Scheduler I can probably also fix the workbench_moderation bug, using our own hook_action_info_alter(). The WBM issue was created 8 months ago and there does not appear to be very active support/maintainership.

Would it be feasible to get scheduling for moderated nodes working with just WBM? Ideally I wouldn't want to install another a module.

In Drupal 7.x we had the Scheduler Workbench Integration project, and for the new Content Moderation available in core 8.2+ we have the fully-featured Scheduler Content Moderation Integration module. It would be a lot of work to replicate all the SCMI functionality for Workbench Moderation, which by definition will have an ever-decreasing user base. However I agree that it is not great to leave it in the currently broken state. When you want to schedule moderated nodes, what exactly is the scenario you are dealing with? I'm not certain exactly what WBMA intends to do when scheduling moderated nodes, although clearly it is meant to cope, because there are issues and comments talking about Scheduler. Adding the required permissions to the anon user for cron makes me think it's not been tried much for moderated nodes.

The use case is we have nodes that our content team still want to go through approval process and publish manually but that also need to be able to be scheduled. I actually built my own integration for scheduler and workbench_moderation since there was none in D8. It acts on the PRE_UNPUBLISH, PRE_PUBLISH and STATE_TRANSITION events and syncs up the appropriate moderation states and correctly publishes/unpublishes moderated nodes.

I guess the double save from patch #24 was allowing the events to fire but now it never fires due to Plugin/Action/ModerationOptOutPublishNode::execute

So if there was a way to get the above events to fire without installing WBMA that would be ideal

Thanks for the info @achap. I have worked out fixes for the two problems I stated in #36, and this needs to be done in Scheduler 2.x first, but I will port them back to 1.x also.

Your own custom Workbench Moderation integration using the Scheduler events sounds excellent. I think we should be able to devise a way to make that work and get round the OptOut problem. You could implement hook_scheduler_publish_action() to do your work and include a node->save() then it would not matter if the OptOut caused the action processig to be skipped. Anyway, I am sure it can be done, but first I want to get the fixes in for the two problems above.

Step 1 adds test coverage to check scheduled publishing and unpublishing when Workbench Moderation is also installed. This only tests non-moderated nodes so far. The test should fail, highlighting the error reported in #3238576: Unpublishing content instead of publishing it

The test in #39 failed because I had not added workbench_moderation as a test dependency. Latest test should fail in the expected way, that is, node not published after cron.

Step 2 done - we have passing tests, showing that Scheduler can fix the Workbench Moderation bug and we are not reliant on that module getting the commit.

Step 3 - add test coverage for when Workbench Moderation Actions is also installed. This took a while, because I had to investigate and fix
#3281948: state_change__node__archived:configuration missing schema in functional tests to allow the test to run. This test will fail, demonstrating the scheduler problem found above.

As expected, we get

Drupal\Tests\scheduler\Functional\SchedulerWorkbenchModerationTest:: testWorkbenchModerationWithWorkbenchModerationActions
The node should be published after cron
Failed asserting that false is true.

Step 4 - The solution to this is that for non-moderated entities we want to skip the workbench_moderation_actions custom action. This will mean that we fall through to the old way of processing, because the core action will have been removed. But that is fine, as we already cater for it, and do $entity->setPublished()->save() if the action does not exist.

@achap I'm going to commit the two fixes to each branch as this is a good step forward in allowing Workbench Moderation and Workbench Moderation Actions to be installed and not cause failures for non-moderated content.

Then we can work on the problem of moderated content.

Awesome @jonathan1055! I've just tested the 1.x-dev branch with your commits and it fixes my issues with non-moderatable entities i.e. my test passes. I uninstalled workbench_moderation_actions since I didn't want to install another module and implemented the hooks as suggested to fix my tests for moderatable entities. In case anyone needs the same I did this:

/**
 * Implements hook_scheduler_publish_action().
 */
function dnsw_scheduler_workbench_integration_scheduler_publish_action(
  NodeInterface $node
) {
  /** @var \Drupal\workbench_moderation\ModerationInformationInterface $moderation_info */
  $moderation_info = \Drupal::service('workbench_moderation.moderation_information');
  if ($moderation_info->isModeratableEntity($node)) {
    $node->save();
  }
}

/**
 * Implements hook_scheduler_unpublish_action().
 */
function dnsw_scheduler_workbench_integration_scheduler_unpublish_action(
  NodeInterface $node
) {
  /** @var \Drupal\workbench_moderation\ModerationInformationInterface $moderation_info */
  $moderation_info = \Drupal::service('workbench_moderation.moderation_information');
  if ($moderation_info->isModeratableEntity($node)) {
    $node->save();
  }
}

Thanks!

So to wrap this up and summarise the situation:

Non-moderated nodes

Non-moderated nodes are now procesed correctly by Scheduler in both situations, that is when Workbench Moderation is installed and Workbench Moderation Actions both is and is not installed.

Moderated nodes

Moderated nodes are not processed by Scheduler, because they are explicitly skipped by the Workbench Moderation opt out.
To get round this, Workbench Moderation Actions was developed, and if WBMA is enabled then the moderated nodes are correctly processed by WBMA and scheduling works as expected.

If the site admin wants to have Scheduler and Workbench Moderation installed but not does not want to install Workbench Moderation Actions then they can solve the problem by implementing the two scheduler hooks in a similar way to the example provided by achap above. You may also need to implement an events subscriber to react to the scheduler pre_publish and pre_unpublish events and the workbench moderation state_transition event.

Following the commits above, and given that there are two solutions for resolving the conflict for moderated nodes, I'm going to mark this as fixed. The audience for Workbench Moderation is reducing, now that Core has Content Moderation. Scheduler has the fully functioning addon Scheduler Content Moderation Integration, which also now caters for any entity type supported by a Scheduler plugin.

Thanks everyone for sticking around and helping with this.

I don't have Workbench Moderation installed, but I do have Workbench and Workbench Access. Our scheduling does not work and this issue is the closest I've been able to find to our own issue. Are Workbench and Workbench Access related to Workbench Moderation in any way? Is it the same family of modules?

I solved this issue by installing the module https://www.drupal.org/project/advanced_scheduler, and implementing a custom hook:

/**
 * Implements hook_action_info_alter().
 */
function module_name_action_info_alter(&$definitions)
{

  // Scheduler module does not work with the workbench moderation module, because scheduler calls the publish_action and unpublish_action plugins
  // which are overwritten by workbench_moderation module (lookat workbench_moderation_action_info_alter)
  // Prevent/revert the overwrite with the below code, since advanced_scheduler module is capable of publish/unpublish moderated content.
  if (isset($definitions['node_publish_action']['class']) && $definitions['node_publish_action']['class'] == ModerationOptOutPublishNode::class) {
    $definitions['node_publish_action']['class'] = PublishAction::class;
  }
  if (isset($definitions['node_unpublish_action']['class']) && $definitions['node_unpublish_action']['class'] == ModerationOptOutUnpublishNode::class) {
    $definitions['node_unpublish_action']['class'] = UnpublishAction::class;
  }

  if (isset($definitions['entity:publish_action:node']['class']) && $definitions['entity:publish_action:node']['class'] == ModerationOptOutPublishNode::class) {
    $definitions['entity:publish_action:node']['class'] = PublishAction::class;
  }
  if (isset($definitions['entity:unpublish_action:node']['class']) && $definitions['entity:unpublish_action:node']['class'] == ModerationOptOutUnpublishNode::class) {
    $definitions['entity:publish_action:node']['class'] = UnpublishAction::class;
  }
}

You may need to modify module weight, so above hook runs after workbench_moderation_action_info_alter