Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.We're using WM on a busy site that results in a view including nodes in the results that are actually in draft mode because of a time delay between the two calls to node_save().
| Comment | File | Size | Author |
|---|---|---|---|
| #4 | 2376819--workbench_moderation-race-03.patch | 2.34 KB | drupalninja99 |
Comments
Comment #1
DamienMcKennaThere have been many issues created to deal with symptoms of this problem, e.g. #1807460: Field collection doesn't play nice with workbench moderation (patch), #1452016: Incompatibilities with Migrate module, etc, etc.
Even Workbench Moderation 2, which uses State Machine v3, again seems to use the two-node_save approach: #2312445: node_save() called twice, thus invoking hook_node_update() twice
I suggest changing over to using Drafty's approach of bundling both modifications in the one entity update action.
Comment #2
drupalninja99 CreditAttribution: drupalninja99 commentedAttaching a patch that moves the publishing of existing revisions from workbench_moderation_moderate to the shutdown function workbench_moderation_store. This doesn't solve the race condition but prevents some of the side effects from the limbo state that workbench moderate produces. Having unpublishing logic in workbench_moderation_moderate means that sometimes views would pull a node that has a status of 1 but with revisions of status = 0. This patch prevents that from happening. I have yet to see any new side effects introduced by this patch.
If you do pull a node while it is in 'limbo state' you will either get the previously published revision (if publishing a draft) or you would get an unpublished node if saving a draft (not ideal). This patch still needs more testing to ensure that it doesn't cause new regressions.
Comment #3
DamienMcKennaI've opened a new issue to deal with the partial rewrite of using Drafty: #2376839: Rewrite to use the new Drafty module
Comment #4
drupalninja99 CreditAttribution: drupalninja99 commentedHere's a patch that works better
Comment #5
DamienMcKennaCan you please remove the first chunk as it's unrelated? Thanks.
Comment #6
DamienMcKennaThis won't fix the issue, it's a core architecture flaw of needing to rely upon the drupal_register_shutdown_function().
Bumping this to Major as it has undesired results, inc content being made viewable that should not be.
Comment #7
DavidSabine CreditAttribution: DavidSabine commentedHi all,
I've submitted an issue which I believe represents a fatal design flaw in Drupal which manifests in the bug identified in this thread. The root cause of this issue, I believe, is not within Workbench but that Drupal considered "published" state to be boolean (true/false) whereas visibility of any piece of content should instead be a matter of "audience" (that is, "who" gets to see said content and under which conditions).
https://www.drupal.org/node/2437937
Comment #8
DamienMcKenna@DavidSabine: I'd go so far as to say that no, the editorial creation process, as handled by WM, Revisioning, etc, is different to its visibility state, as handled by the 'status' option and node_access-based extensions, thus the race condition is a flaw in the editorial creation process and not Drupal core. While yes, it could be argued that the node status could/should be replaceable, that's what node_access provides you with.
Comment #9
agentrickardUsing Drafty as proposed in #2376839: Rewrite to use the new Drafty module solves this race condition.
Comment #10
DamienMcKennaThis was solved in #2376839: Rewrite to use the new Drafty module.