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.
Comment | File | Size | Author |
---|---|---|---|
#66 | 2824725-66.patch | 863 bytes | rpayanm |
#58 | workbench_moderation-3.x-2824725-56.patch | 787 bytes | Siavash |
#55 | workbench_moderation-3.x-2824725.patch | 1.07 KB | Siavash |
#43 | Screenshot from 2017-04-12 17:19:41.png | 92.01 KB | sri@re |
History_of_Revision_Test_Page.jpg | 112.38 KB | baronmunchowsen |
Comments
Comment #2
baronmunchowsen CreditAttribution: baronmunchowsen commentedComment #3
baronmunchowsen CreditAttribution: baronmunchowsen commentedComment #4
das-peter CreditAttribution: das-peter at Cando commentedThe 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.
Comment #5
baronmunchowsen CreditAttribution: baronmunchowsen commentedI'd say that if I read:
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?
Comment #6
das-peter CreditAttribution: das-peter at Cando commentedA 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 ;)
Comment #7
baronmunchowsen CreditAttribution: baronmunchowsen commentedI'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.
Comment #8
Arono974 CreditAttribution: Arono974 commentedHello,
Is it possible to downgrade 3.0 to 1.4 ?
Best regards,
Comment #9
dbielke1986 CreditAttribution: dbielke1986 commentedYes - 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.
Comment #10
kcolwell CreditAttribution: kcolwell commentedI hate to be useless, and complaining, but does anyone have any ideas on how to get workbench moderation 3.0 working as expected?
Comment #11
cdesautels CreditAttribution: cdesautels commentedI'm experiencing the same problem.
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.
Comment #12
dbielke1986 CreditAttribution: dbielke1986 commented@#11
:-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
Comment #13
JosephAM CreditAttribution: JosephAM commentedAlso having a similar issue on my sites. Released the upgrade yesterday, now pages are disappearing as this loses track of published revisions.
Comment #14
Matroschker CreditAttribution: Matroschker commentedThe same behavior in my system. The system is not really usable in this situation.
Comment #15
cdesautels CreditAttribution: cdesautels commentedIn 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.
Comment #16
hannes_bln CreditAttribution: hannes_bln commented@#11 - exactly the same here: this issue is rendering the module unusable... :(
Comment #17
camerongreen CreditAttribution: camerongreen commentedSame 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.
Comment #18
gluebox CreditAttribution: gluebox as a volunteer commentedRE 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.
Comment #19
shabana.navas CreditAttribution: shabana.navas at Cheeky Monkey Media commentedI 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.
Comment #20
shabana.navas CreditAttribution: shabana.navas at Cheeky Monkey Media commentedComment #21
therobyouknow CreditAttribution: therobyouknow commented#11 same for me:
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...
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?
Comment #22
therobyouknow CreditAttribution: therobyouknow commentedUpdating on downgrading:
#8 :
Yes it is- I have successfully downgraded to Workbench 1.4 by exactly following the instructions in #9:
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
Comment #23
philipbawn CreditAttribution: philipbawn commentedtherobyouknow 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?
Comment #24
therobyouknow CreditAttribution: therobyouknow commentedphilipbawn:
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:
Comment #25
justin.green CreditAttribution: justin.green commentedWe see the same behavior and with a recent upgrade and successfully downgraded to 1.4 as 3.0 was not usable.
Comment #26
Arono974 CreditAttribution: Arono974 commentedThanks JD_1, actually 2 months i have downgrade to 1.4 and all is fine.
Comment #27
smustgrave CreditAttribution: smustgrave commentedWhen looking through the code I found the following.
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?
Comment #28
smustgrave CreditAttribution: smustgrave commentedActually 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');
todrupal_write_record('node', $node, array('nid', 'vid'));
It seems to fix the issue I mentioned.Comment #29
smustgrave CreditAttribution: smustgrave commentedThis 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.
Comment #30
hass CreditAttribution: hass commentedComment #32
smustgrave CreditAttribution: smustgrave commentedThis is my first time patching core. Not sure if I got the diff lines correct. I removed docroot from it. Sorry.
Comment #33
smustgrave CreditAttribution: smustgrave commentedJust wondering if anyone has had a chance to look at the patch and offer any feedback? Believe the change could work for this issue.
Comment #34
Tess BakkerPatch in #2832600: CI error on tests, because of old test module needs to be committed first, until then, every test will fail.
Comment #35
smustgrave CreditAttribution: smustgrave commentedNow that the issue above is resolved can we test the patch again?
Comment #36
Tess BakkerTests still not working, it's now waiting for #2468907: Refactor tests to remove dependencies. We're almost there.
Comment #37
smustgrave CreditAttribution: smustgrave commentedMaybe 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
Comment #38
Tess BakkerComment #39
hass CreditAttribution: hass commentedComment #40
hass CreditAttribution: hass commentedComment #41
kholloway CreditAttribution: kholloway as a volunteer commentedIn 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.
Comment #42
MingsongThis 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.
Comment #43
sri@re CreditAttribution: sri@re commented@mingsong , i have tested (in simplytest.me)drafty new release 7.x-1.0 beta 4 and workbench moderation 3.0.
Still getting forward revisions while save it in draft and in needs review.Kindly check.
Comment #44
hass CreditAttribution: hass commentedComment #45
MingsongHi 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.
Comment #46
sri@re CreditAttribution: sri@re commentedHI 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?
Comment #47
jbaum_13 CreditAttribution: jbaum_13 commentedI 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.
Comment #48
MingsongHi @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() {
....
Comment #49
MingsongI 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.
Comment #50
MingsongThe "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.
Comment #51
beckydev CreditAttribution: beckydev commentedUpdating incorrect module reference from "Webform" to "Workbench Moderation".
Comment #52
Hemant Kumar CreditAttribution: Hemant Kumar commentedDoes anyone have solution for the issue described in #12? Flag field is causing problem when saving the draft.
Comment #53
Hemant Kumar CreditAttribution: Hemant Kumar commentedSolution 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.
Comment #54
Siavash CreditAttribution: Siavash at OHO Interactive for Dartmouth commentedI 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.
Comment #55
Siavash CreditAttribution: Siavash at OHO Interactive for Dartmouth commentedI 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.
Comment #56
Siavash CreditAttribution: Siavash at OHO Interactive for Dartmouth commentedComment #58
Siavash CreditAttribution: Siavash at OHO Interactive for Dartmouth commentedRe-uploading new patch file from #55 with fix to be reviewed again. (had wrong path)
Comment #59
Siavash CreditAttribution: Siavash at OHO Interactive for Dartmouth commentedComment #61
Eric_A CreditAttribution: Eric_A commentedI was unable to reproduce the
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.
Comment #62
joseph.olstadclosing 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.
Comment #63
Eric_A CreditAttribution: Eric_A commentedActually, 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...
Comment #64
Eric_A CreditAttribution: Eric_A commentedHm, 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.
Comment #65
Eric_A CreditAttribution: Eric_A commentedPlease disregard #64, Sorry for the noise, Will come back to this later.
Comment #66
rpayanmComment #68
aaronpinero CreditAttribution: aaronpinero commentedIs 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.
Comment #69
joseph.olstadwe're doing bilingual with this recipe of drafty , entity_translation and workbench_moderation:
#2828635-9: Security + Bug Fixes for Workbench Moderation (3.0)
Comment #70
aaronpinero CreditAttribution: aaronpinero commentedJoseph,
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.
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.
Comment #71
aaronpinero CreditAttribution: aaronpinero commentedI'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.
Comment #72
aaronpinero CreditAttribution: aaronpinero commentedAnd 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.
Comment #73
joseph.olstadRecently 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.
Comment #74
oadaeh CreditAttribution: oadaeh at Hook 42 commentedI 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.
Comment #75
kwfinken CreditAttribution: kwfinken at Michigan State University for Michigan State University commentedAny progress at all on this? Has this been abandoned?