This behaviour was noted when testing an upgrade from 7.x-1.4 to 7.x-3.0 per the security update: https://www.drupal.org/node/2824455

As well as the behaviour already detailed in this issue: https://www.drupal.org/node/2824607, I am experiencing the following behaviour:

1: When a node (created prior to the Workbench Moderation 7.x-3.0 update) has a published revision and a more-recent unpublished (e.g. Draft/Needs Review) revision, any changes to the revision state of the more-recent revision changes the published revision to unpublished, leaving no published revisions of the node.

2: When a node (created after the Workbench Moderation 7.x-3.0 update) has a published revision and a more-recent unpublished revision, any changes to the revision state (even if not to published state) marks that more recent revision as the published version.

Note - the site I am working with has 4 revision states: Draft, Ready for Review, Ready to Publish, Published

I have attached screenshots which better demonstrate the issues I am experiencing.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

baronmunchowsen created an issue. See original summary.

baronmunchowsen’s picture

baronmunchowsen’s picture

Version: 7.x-3.x-dev » 7.x-3.0
das-peter’s picture

The creation of an "excess" revision is normal when using Drafty. It's required to maintain data consistency - avoid the Information Disclosure issue.
You might to check out this patch which allows to clean-up deprecated old revisions #2579205: Delete redundant revisions

Regarding the published state this looks like a bug. As far as I understand after the update the revision with the highest id is basically always the published revision.
Looks like this needs further investigation.

baronmunchowsen’s picture

I'd say that if I read:

update the revision with the highest id is basically always the published revision

correctly - this is a massive issue that fundamentally impacts workbench moderation - the ability to have more-recent un-published revisions of content is a core requirement of such a module, no?

das-peter’s picture

the ability to have more-recent un-published revisions of content is a core requirement of such a module, no?

A higher id doesn't mean newer content.
The higher id is automatically created by saving a "forward revision" of the published revision, so your newer revision in terms of content is still there, still unpublished and still ready to edit.
This "forward revision" behaviour causes the "excess" revisions.
No problem here - at least not with that ;)

baronmunchowsen’s picture

I've taken some time to look into this further.
With a clean Drupal install the issues are not reproducible.

It seems like that the node becoming unpublished is limited to content which had pending revisions while the update from 1.4 to 3.0 was implemented. Once the update was implemented, and nodes thereafter the un-publishing phenomenon could not be replicated I found. Therefore, if it's possible to ensure that all content has no pending revisions prior to updating the module, this may help.

Regarding the second issue - this may be tied to the revisioning module. Disabling revisioning removes the experienced behaviour. I need to look into it further to understand why.

Arono974’s picture

Hello,

Is it possible to downgrade 3.0 to 1.4 ?

Best regards,

dbielke1986’s picture

Is it possible to downgrade 3.0 to 1.4 ?

Yes - we did this already. There were too many strange behaviours.
You need to copy the workbench moderation 1.4 to your directory and deactivate/&deinstall the drafty modul after that.

Now our system has an consistent state again.

kcolwell’s picture

I hate to be useless, and complaining, but does anyone have any ideas on how to get workbench moderation 3.0 working as expected?

cdesautels’s picture

I'm experiencing the same problem.

  1. Create a new node, save it in Draft state. Result: A current revision. Unpublished and editable
  2. Publish the draft. Result: Still one revision, but published
  3. Now the trouble starts. Create new draft save in draft state. Result: Revision is saved straight to publish state. Previous revision is now an inactive draft. There is no editable current draft.

From this point on, there are no current drafts. No way to create and save changes in a draft state. Bascally making Workbench moderation useless. I have to go back to 1.x and live with the security flaw.

dbielke1986’s picture

@#11

From this point on, there are no current drafts. No way to create and save changes in a draft state. Bascally making Workbench moderation useless. I have to go back to 1.x and live with the security flaw.

:-D
Great - this is one of the mentionend issues in our system. We found out that this is related to an additional (flag) field on our content type. We are using a flag field "published (exceptionally)" to get all nodes which were not run the defined workflow (draft -> needs review -> published).

On every node we tried to create a new draft (and the node is flagged) we get the same behavior you have described.
If the same node is unflagged the creation of a draft works fine.

Maybe cou can validate this reason on your system too.

BR

JosephAM’s picture

Also having a similar issue on my sites. Released the upgrade yesterday, now pages are disappearing as this loses track of published revisions.

Matroschker’s picture

The same behavior in my system. The system is not really usable in this situation.

cdesautels’s picture

In response to JD_1. I don't really understand the scenario you're describing. What is this"Flag field"? Is this from some contrib module?

Anyways, the nodes in question on my system have nothing special about them. Just basic content types using standard fields and Workbench 3.x doesn't retain any current revision for editing.

hannes_bln’s picture

@#11 - exactly the same here: this issue is rendering the module unusable... :(

camerongreen’s picture

Same issue, causing a lot of problems for our content production team.

They have a "workaround", which isn't a fix, but just trying to stop it breaking everything. They take the content from the draft, they save it into a text file. They then go into the moderation panel, find the last fully published version and they revert to that. Then they overwrite that with the content from the draft, and create a new draft and that "seems" to work, but they have published any of these drafts yet so caveat emptor.

gluebox’s picture

RE possible "workarounds", rules might be one way to go. I hit snags in my workbench rules after this update. I have some moderation state changes that were (are) borked.

This patch has set my rules back in shape. (crosses fingers.)
https://www.drupal.org/node/2476489#comment-10668102

Maybe knowing about this patch will help others.

shabana.navas’s picture

I am having the exact same issue. I've got a lot of sites that use workbench moderation and we've got lots of different moderation states on these sites. For example, a node can go from draft->published->in_processing (still should be published)->completed (still should be published)->archived (still should be published). And we have code that does this stuff programmatically. So, a user can come in and put the node in the 'completed' state if it is in the 'in_processing' state. And that was working all fine.

Now, with the new update, there is a published version and a draft version is created as well which is in 'completed' state. I don't need this draft version. Hoping someone can point me in the right direction to fix this issue. Thanks.

shabana.navas’s picture

Priority: Normal » Major
therobyouknow’s picture

#11 same for me:

3. Now the trouble starts. Create new draft save in draft state. Result: Revision is saved straight to publish state. Previous revision is now an inactive draft. There is no editable current draft.

When I originally tested Workbench 3.0 I hadn't initially seen these problems on one piece of content BUT after reports of issues, my further testing showed the problem described in #11

Also...

Is it possible to downgrade 3.0 to 1.4 ?

Yes - we did this already. There were too many strange behaviours.
You need to copy the workbench moderation 1.4 to your directory and deactivate/&deinstall the drafty modul after that.

Now our system has an consistent state again.

It's encouraging to learn that some folks have reverted to 1.4, apparently without issue. I would like to do this but wondered if there were new database table structures created when upgrading to 3.0 which wouldn't be compatible with going back to 1.4. Apparently not it would appear if folks have been successful. Comments?

therobyouknow’s picture

Updating on downgrading:

#8 :

Is it possible to downgrade 3.0 to 1.4 ?

Yes it is- I have successfully downgraded to Workbench 1.4 by exactly following the instructions in #9:

Yes - we did this already.
You need to copy the workbench moderation 1.4 to your directory and deactivate/&deinstall the drafty modul after that.

To be more precise: the copying of Workbench moderation 1.4 to the modules/contrib folder that I did completely overwrites Workbench Moderation 3.0 so that no files from Workbench 3.0 are present. Only the files from Workbench 1.4.

After following these steps, the Workbench functionality that went missing when upgrading to 3.0 is now restored:
- Creating New Drafts and then saving them and they remain unpublished. The existing published revision remains published. In Workbench 3.0 Drafts went live (incorrect)
- Editing drafts is available again

philipbawn’s picture

therobyouknow in your post (#22) you say you copied workbench moderation 1.4 to the modules/contrib folder replacing workbench moderation 3.0 entirely., then deactivated and deinstalled the drafty module. does this mean that de-installing the drafty module undoes the database schema change (a column renamed) which was involved in the upgrade to workbench moderation 3? Please confirm if downgrading from 3.0 to 1.4 results in the schema changing back to the way it was, or if it remains the same but things keep working?

therobyouknow’s picture

philipbawn:

therobyouknow in your post (#22) you say you copied workbench moderation 1.4 to the modules/contrib folder replacing workbench moderation moderation 3.0 entirely., then deactivated and deinstalled the drafty module. does this mean that de-installing the drafty module undoes the database schema change (a column renamed) which was involved in the upgrade to workbench moderation 3? Please confirm if downgrading from 3.0 to 1.4 results in the schema changing back to the way it was, or if it remains the same but things keep working?

I haven't looked at the schema (yet) to compare the differences between before and after. However, as stated in my steps from my previous comment, downgrading from workbench moderation 3.0 to 1.4 does restore the publishing workflow to how it was (if you were originally on 1.4).

So the outcome needed (i.e. to restore the functionality) is definitely possible, regardless of if the schema is back to the way it was. In other words, without information as to what has happened in the schema, the functionality can be restored.

Even though the downgrade worked, I am curious about the changes to the schema, before and after, to develop an understanding of the upgrade and what part the schema change played in affecting the functionality for this issue to be raised.

When/if a newer 3.x version of Workbench is released, call it say 3.2, that resolves this issue (i.e. same functionality as 1.4), a question would be: what are the options for:

  • those who downgraded to 1.4 - can they re-upgrade to 3.2 without being affected by any previous upgrade/downgrade
  • those who remain at 3.0 - can they upgrade to 3.2 and have the same functionality as 1.4
justin.green’s picture

We see the same behavior and with a recent upgrade and successfully downgraded to 1.4 as 3.0 was not usable.

Arono974’s picture

Thanks JD_1, actually 2 months i have downgrade to 1.4 and all is fine.

smustgrave’s picture

FileSize
35.65 KB

When looking through the code I found the following.

  // If this revision is to be published, the new moderation record should be
  // the only one flagged 'published' in {workbench_moderation_node_history}.
  // Also applies in the case where we unpublish a live revision.
  if ($new_revision->published || !$node->status) {
    $query = db_update('workbench_moderation_node_history')
      ->condition('nid', $node->nid)
      ->fields(array('published' => 0))
      ->execute();
  }

And I was wondering if someone could further explain? If you look at the picture I added, when I change the current revision 195792 to any other moderation state, the published revision becomes unpublished. This issue affects about 50 pages for us and just wondering why we need the code above?

smustgrave’s picture

Actually take my previous comment back, after digging into the code I found a potential bug with core not workbench moderation. In node.module line 1151 if you change drupal_write_record('node', $node, 'nid'); to drupal_write_record('node', $node, array('nid', 'vid')); It seems to fix the issue I mentioned.

smustgrave’s picture

This is the patch I made that seems to fix the issue I mentioned in #27. If this can get tested with no negatives I'll submit to Drupal core to be added.

hass’s picture

Status: Active » Needs review

Status: Needs review » Needs work

The last submitted patch, 29: node-unpublished-2824725-29.patch, failed testing.

smustgrave’s picture

This is my first time patching core. Not sure if I got the diff lines correct. I removed docroot from it. Sorry.

smustgrave’s picture

Just wondering if anyone has had a chance to look at the patch and offer any feedback? Believe the change could work for this issue.

Tess Bakker’s picture

Status: Needs work » Postponed
Related issues: +#2832600: CI error on tests, because of old test module

Patch in #2832600: CI error on tests, because of old test module needs to be committed first, until then, every test will fail.

smustgrave’s picture

Now that the issue above is resolved can we test the patch again?

Tess Bakker’s picture

Tests still not working, it's now waiting for #2468907: Refactor tests to remove dependencies. We're almost there.

smustgrave’s picture

Maybe I put this in the wrong queue. My patch was for core node module. I put it here because it seemed to solve the issue being reported. See my comments from #29 and #32

Tess Bakker’s picture

Status: Postponed » Active
hass’s picture

Status: Active » Needs review
hass’s picture

Status: Needs review » Active
kholloway’s picture

In my case (which might help others) there is a configuration setting that can cause this also:

Problem:
When a Draft of a Published node is created the current Published version gets set to unpublished.

Resolution:
Verify the settings of the new "Default revision" State option that was added to the "States" config for each of your States /admin/structure/workbench-moderation/states. In my case the "Draft" State was checked as "Default revision" which I guess would overwrite the published default State when a new Draft was created. Unchecked that box solved it the issue. Review all your other States to ensure this setting is correct.

I couldn't find any documentation about the "Default revision" check box but my understanding is that when this is checked content that enters into this revision state will automatically become the current revision (so it would overwrite the previous current revision). You'll probably want this checked only on States you expect to replace the current one (like Published, Archived, Unpublished, etc). States like "Draft" and "Needs Review" for example you'll want to make sure this setting is NOT checked.

Mingsong’s picture

This issue could be fixed by installing the drafty module (https://www.drupal.org/project/drafty) which is required module by Workbench Moderation 7.x-3.0

See the workbench_moderation.info file at line 23:

dependencies[] = drafty

If you upgrade Workbench Moderation from old version to 3.0, Drupal would allow the Workbench Moderation module working without installing drafty module. But that would cause some strange issues like this one.

After install drafty module and clear all cache, those problems should be fixed.

sri@re’s picture

@mingsong , i have tested (in simplytest.me)drafty new release 7.x-1.0 beta 4 and workbench moderation 3.0.forward revision

Still getting forward revisions while save it in draft and in needs review.Kindly check.

hass’s picture

Version: 7.x-3.0 » 7.x-3.x-dev
Mingsong’s picture

Hi sri@re,

Did you clear the cache after installing the modules?

Is the issue you are facing same as the following two,

1: When a node (which was created prior to workbench moderation update to 7.x-3.0) has a published revision and a more-recent unpublished (e.g. Draft/Needs Review) revision, any changes to the revision state of the more-recent revision changes the published revision to unpublished, leaving no published revisions of the node.

2: When a node (created post workbench moderation update to 7.x-3.0) has a published revision and a more-recent unpublished revision, any changes to the revision state (even if not to published state) marks that more recent revision as the published version.

Or it is different issue you just found?

I have tested these modules on my sites, I couldn't reproduce those issues.

sri@re’s picture

HI mingsong,

I have not tested in my developer site .Its a drupal online testing website (simplytest.me).I just install latest version of two modules and tested.Can you please try both modules in simplytest.me site and start doing draft and needs_review in it?

jbaum_13’s picture

I am experiencing similar issues.

It is changing the time stamp for the published version to match the current revision timestamp but it is not publishing that revision automatically.

It is however not ordering the revisions the same as before where the highest number was the most recent revision and now it is showing the most recent revision underneath the published version with a lower revision number.

The "node-unpublished" class is also no longer being applied when you click view draft on the node as well.

I updated workbench_moderation and installed and enabled the drafty module, updating the database and clearing the cache and the issue still persists.

Mingsong’s picture

Hi @jlandbaum,

The issue you reported is caused by another Drafty module issue (https://www.drupal.org/node/2730265).

The reason why the updated time changed is that the Drafty module restores a new publish revision after we update the moderation state for a node.

See line 243 in drafty.module

/**
* Publish revisions previously set with setRevisionToBePublished().
*/
public function restorePublishedRevisions() {
....

Mingsong’s picture

I created another issue report (https://www.drupal.org/node/2872097) for the time stamp issue as it is different issue from what we discuss here.

I also upload a patch (https://www.drupal.org/node/2872097#comment-12051716) to fix it.

Mingsong’s picture

The "node-unpublished' class missing issue reported at #47 is not the one we discuss here.

I create another issue report for it (https://www.drupal.org/node/2872232) and uploaded a patch (https://www.drupal.org/node/2872232#comment-12052491) to fix it.

beckydev’s picture

Issue summary: View changes

Updating incorrect module reference from "Webform" to "Workbench Moderation".

Hemant Kumar’s picture

Does anyone have solution for the issue described in #12? Flag field is causing problem when saving the draft.

Hemant Kumar’s picture

Solution for issue described in #12. That is when we add additional flag in the node form and check it, draft revision is not created when we save the page.

Adding this drupal_static_reset('drafty_recursion_level'); in the drafty_entity_presave function solves the problem.

function drafty_entity_presave($entity, $type) {

  drupal_static_reset('drafty_recursion_level');
  
  $recursion_level = &drupal_static('drafty_recursion_level', 0);
  if (!$recursion_level && !drafty_entity_is_new($entity, $type) && !empty($entity->is_draft_revision)) {
    // Since this is a draft revision, after saving we want the current,
    // published revision to remain in place in the base entity table and
    // field_data_*() tables. Set the revision to publish once the draft entity
    // has been written to the database.
    list($id) = entity_extract_ids($type, $entity);
    $vid = drafty()->getPublishedRevisionId($type, $id);
    drafty()->setRevisionToBePublished($type, $id, $vid);
  }
  $recursion_level++;
}
Siavash’s picture

I have yet to investigate why exactly, but the issue here seems to be caused by the fact that the draft revision of the node isn't set to status = 1 in the database. When updating from Workbench 1.4 to 3.x using drafty, old content can be fixed by setting their draft node revision to have status 1.

This brings up the question of why the draft needs to be set to published for edits to work with WB3.x and drafty.

Siavash’s picture

I was finally able to resolve this issue. First I had to patch drafty with: https://www.drupal.org/node/2730265#comment-12080994
(This issue seemed to be having issues with field_collections, but not using field collections it isn't an issue for us)

Next, I had to modify workbench_moderation to fix the case where we are editing a draft and leaving it as draft and also editing a draft when no published revisions exists with with the drafty patch mentioned above.

This solved this problem of old nodes unpublishing when we edit their draft and also solved #50 issue of the draft not having unpublished class/status in the database.

Siavash’s picture

Status: Active » Needs review

Status: Needs review » Needs work

The last submitted patch, 55: workbench_moderation-3.x-2824725.patch, failed testing. View results

Siavash’s picture

Re-uploading new patch file from #55 with fix to be reviewed again. (had wrong path)

Siavash’s picture

Status: Needs work » Needs review

Status: Needs review » Needs work

The last submitted patch, 58: workbench_moderation-3.x-2824725-56.patch, failed testing. View results

Eric_A’s picture

1: When a node (created prior to the Workbench Moderation 7.x-3.0 update) has a published revision and a more-recent unpublished (e.g. Draft/Needs Review) revision, any changes to the revision state of the more-recent revision changes the published revision to unpublished, leaving no published revisions of the node.

I was unable to reproduce the

leaving no published revisions of the node

Everything else is by design.

I tried two things with two such nodes after upgrading to WM 3.0.

Changed the state from draft tot needs_review.
Edited the concept and changed state from draft to needs_review.

With both nodes I still had a published revision of the node.

joseph.olstad’s picture

Status: Needs work » Closed (outdated)

closing this as outdated.
if you have issues, upgrade to the latest dev release of drafty , and the latest dev release of workbench_moderation 7.x-3.x
a new dev release of drafty was pushed yesterday that has some important fixes.

Eric_A’s picture

Priority: Major » Critical
Status: Closed (outdated) » Needs work
Issue tags: +Needs reroll

Actually, I kind of reproduced this now, or at least a very similar bug. Given a node created in 1.x with a more recent draft, editing the draft unpublished the published revision. This is pretty severe.

So I'm not actually changing state, just a small edit to the draft, save the draft and kaboom.

Unfortunately right now I'm not able to look into this...

Eric_A’s picture

    // Fetch the most recent published revision.
    $query = db_select('node', 'n');
    $query->addJoin('INNER', 'node_revision', 'r', 'n.vid = r.vid');
    $query->addJoin('LEFT OUTER', 'workbench_moderation_node_history', 'm', 'r.vid = m.vid');
    $query->condition('n.nid', $node->nid)
      ->condition('n.status', 1)
      ->orderBy('m.hid', 'DESC')
      ->fields('r', array('nid', 'vid', 'title', 'timestamp'))
      ->fields('m');
    $published = $query->execute()->fetchObject();

Hm, unless I'm mistaken the assumption here with the orderBy() is only correct for content created in workbench_moderation 3.x, but broken for anyone who did the update from 1.x.

Eric_A’s picture

Please disregard #64, Sorry for the noise, Will come back to this later.

rpayanm’s picture

Status: Needs work » Needs review
FileSize
863 bytes

Status: Needs review » Needs work

The last submitted patch, 66: 2824725-66.patch, failed testing. View results
- codesniffer_fixes.patch Interdiff of automated coding standards fixes only.

aaronpinero’s picture

Is it possible that changes in Drafty from beta 4 to rc1 cause this issue? I have a site running Workbench 3.0 and Drafty beta4 and no one has complained about this, but I notice the unpublishing problem immediately when testing a new workflow setup on a site using Workbench 3.0 and Drafty rc1. However, I only noticed the problem after editing Drafty's configuration option for deleting redundant revisions.

joseph.olstad’s picture

we're doing bilingual with this recipe of drafty , entity_translation and workbench_moderation:
#2828635-9: Security + Bug Fixes for Workbench Moderation (3.0)

aaronpinero’s picture

Joseph,

I'm not sure when you established this recipe, but it seems that both Workbench and Drafty have had some updates that are more recent(?). Any experience there?

For all, I have been playing with this for a while and I've isolated *something*. I am working with Workbench Moderation 7.x-3.0 and Drafty 7.x-1.0-beta4.

  • If I have a node that has a published version and I create a new draft. Everything is okay.
  • If I transition that node from Draft to Needs Review using the link in the Needs Review tab, the node transitions as expected
  • If I transition that node from Draft to Needs Review using the publishing option in the Edit Draft screen, the node transitions as expected
  • If I transition that node from Draft to Needs Review using a Views Bulk Operation, the node transitions as expected
  • If I transition that node from Draft to Needs Review using the state change option in the Moderate tab, the node transitions to Needs Review and the currently published version somehow disappears, such that there is no currently published version of the node.

The same pattern holds if I work on a node that has a published version and a draft in the Needs Review state. If I transition that draft from Needs Review back to the Draft state using the option in the Moderate tab, the currently published version somehow disappears. But if I use any other method (on the Needs Review screen, using VBO, in the edit screen for the draft), it works like it should.

aaronpinero’s picture

I've isolated my particular issue to the workbench_moderation_moderate_form_submit() function being called twice in a row on an occasion of the workbench_moderation_moderate_form being submitted once. The first submission action seems fine, but the second one is what causes the unwanted unpublishing of the published revision of the node. Part of the problem might also be in the workbench_moderation_moderate function, where it, according to the comment, checks to see if the published version is being unpublished.

aaronpinero’s picture

And one more note before I run up on the limit of what I am able to do: the Rules module may be causing a problem here. I uninstalled Rules on the site I've been testing and the double execution of the workbench_moderation_moderate_form_submit function ceased. That's sort of a shame, because I wanted to use rules for some state-change-related functions, but at least I can now point to something as the culprit.

joseph.olstad’s picture

Recently I fixed something sort of related for a different client, they had some custom vbo action submit code that was doing double publish in a certain use case. They were on an older wb and no drafty.

My recipe is beta4 patched similar to rc1 but better with extra patch and entity_translation for workbench_moderation with related patches. I am with a new client now that is using outdated workbench_moderation 1.x
But my previous client still doing well with that recipe.

oadaeh’s picture

I tried both patches in #66 and #56 (they are slightly different) in an attempt to address #2946293: Fields are not set to correct revision when publishing draft content, but the code changes caused the content to become unpublished when their states were changed.

kwfinken’s picture

Any progress at all on this? Has this been abandoned?