Node Save causing new revision of published node to remain as draft [#2592863]

I have been saving nodes programatically during a cron run (using the cron Queue API). Every once-in-awhile after creating a new revision, the new revision remains as a draft even though it should have been published. We have set our current default state to Draft on every new revision.

While I was using version 1.3 I had to add the below code to my script in order for workbench moderation to actually publish the node after the new revision was created.

node_save($node);
if ($node->status == 1) {
  workbench_moderation_moderate($node, 'published');
}

After upgrading to 1.4 I understand that is now no longer necessary so now I just call node_save and don't explicitly call workbench_moderation_moderate().

However, even after the upgrade, certain nodes sometimes still don't publish correctly. The problem is that it is pseudo-random. Sometimes during a cron run node 1234 won't be published, but then the next time I test it, 1234 published fine, but 2345 didn't. But then if I test it a third time, 1234 wasn't published again. If I reduce the number of nodes to be processed on each cron run, there are less nodes that remain as a draft. If I increase the number processed, more nodes don't get published. That makes me think some kind of race condition is happening.

It's difficult for me to step through because when I use a debugger the problem never occurs. If I use print statements, the status it switched sometime between workbench_moderation_node_presave and workbench_moderation_node_data.

I think the crux of it is that $node->status seems to be getting set to 0, when it should be set to 1. I don't want to blow away any changes which might be in a draft so I use $node->status to make sure that it is set to published. Any ideas what could be happening?

Comments

Comment #1

14 October 2015 at 20:01

neuquen created an issue. See original summary.

Comment #2

neuquen CreditAttribution: neuquen commented 14 October 2015 at 20:03

Title:

Node Save causing published node to remain as draft

» Node Save causing new revision of published node to remain as draft

Comment #3

neuquen CreditAttribution: neuquen commented 14 October 2015 at 20:06

Issue summary:

View changes

Comment #4

neuquen CreditAttribution: neuquen commented 14 October 2015 at 22:32

Issue summary:

View changes

Comment #5

darol100 CreditAttribution: darol100 as a volunteer and commented 10 February 2017 at 09:06

Same issue here. =/

Comment #6

geoffreyr CreditAttribution: geoffreyr commented 14 February 2017 at 22:59

I've been hearing from our users that this same issue is occuring, but under 7.x-3.0. Going to keep tabs on this in the hope it sheds some light on the situation.

Comment #7

darol100 CreditAttribution: darol100 as a volunteer and commented 22 February 2017 at 15:32

I ended up configuring the workbench moderation after the node is created it. Similar to this code:

// Prepare the node values
    $node = new stdClass;
    $node->type = 'best_content_type_ever';
    $node->title = 'best title ever';
    $node->language = 'en';
    $node->uid = $user->uid;
    $node->promote = 1;

// Save Node
 node_save($node);

// Configure workbench moderation
 workbench_moderation_moderate($node, 'published');
 $node->workbench_access = array($my_custom_workbench_access);
 node_save($node);

Comment #8

neuquen CreditAttribution: neuquen commented 22 February 2017 at 15:50

In the end, because I got no response, I decided to take matters into my own hands and create a separate cron job which fixed the node status if any inconsistencies were found. I first checked (with a SQL query) to see if the node status, revision status and workbench moderation status were different. All three should either be 1 (published) or 0 (unpublished). If the script found any that were inconsistent, I changed (with another SQL query) the revision status and workbench moderation status to match the node status. We did so because we found that in most cases the node status was correct and the other one or two values were incorrect.

I think part of the problem is that in the workbench moderation module something is be changed in the shutdown function. I haven't looked at the code in awhile so I'm not certain how it works today, but that could be part of the problem.

Comment #9

agentrickard

he/him

English

Georgia (US)

CreditAttribution: agentrickard at Palantir.net commented 24 February 2017 at 18:05

The 1.x branch is deprecated because of this very issue. You should upgrade to 7.x-3.0.

See https://www.drupal.org/node/2824455

Comment #10

neuquen CreditAttribution: neuquen commented 1 March 2017 at 16:27

@agentrickard

@geoffreyr in comment #6 said users were still seeing the issue in 7.x-3.0.

Comment #11

Nigel Cunningham

Geelong

CreditAttribution: Nigel Cunningham commented 2 March 2017 at 04:49

Reporting that this issue was seen after upgrading a bunch of modules including taking this one from 1.4 to 3.0. $node->vid seems to not be updated. I'll see if I can reproduce and debug the issue and provide a patch.