Revisions getting reverted when two translations are pending

@dinaish20,

I don't have a lot of experience with the 3.x branch however in my use cases I'm using the 2.x version and on the /admin/content view we're displaying (filtering current interface language) titles of nodes in the current language without duplicates so the node only gets bulk processed once for all languages. Make sense?

With that said, there could be a bug in the 3.x branch, I will have to run some of my own tests.

You may wish to consider using the 2.x release instead however I don't understand your use case.

The 2.x release was made to publish all languages pending or most recent draft for the same node.

Dinaish20, if you edit related translations at the same time like you mentioned you do you might be interested to try https://drupal.org/project/entity_translation_unified_form
This module has a few different configuration options, when publishing the revisions for all translations are marked as related , perhaps your revisions are not in sync this way?

There's also a one on top of the other mode

With that said, we're using the 2x branch of moderated_content_bulk_publish, I haven't actually used 3.x much at all yet.

We are seeing issues with both the 2.x versions and 3.x versions and the both cause data (content) loss. I am changing this issue to a critical as this module should not be used until this is fixed. You can see right away there is an issue with how the revisions are being selected / created for bulk publish. If I create a node in EN as draft, create a node in FR as draft then bulk publish both using this VBO action BOTH the EN and FR published nodes have the same vid. This is incorrect.

In 2.x if you then if you edit the EN make a change and save as Draft, then edit the Fr and save as Published the FR version will show on both the EN and FR revisions pages and the Draft changes on the EN side will be lost.

In 3.x if you make a draft change in EN, then a draft change in FR and then do the bulk publish on the EN and allow the action to apply to all languages then the EN changes are lost.

What version are you using joel_osc ? When did you start noticing this?

@joel_osc , what version of core are you using and what workflow are you using ? 2.0.x is for the standard editorial workflow, should not have anything fancy in it. 3.0.x allows customized workflows has to be configured as such.

I doubt that this is widespread since there's over 9000 installs nearly 10,000 , with that said, willing to support various scenarios and look for improvements.

Drupal wxt 5.4.3... I would bet most of those sites don't use translation + moderation.

Also, just try it anywhere and look at the vids of the two published versions... if they are the same then there is an issue.

ok we're using this with WxT 6.1.2 / Drupal 11.1.8 , ran a series of tests recently and everything published correctly using the editorial workflow moderated_content_bulk_publish 2.0.36 and recently tested 2.0.32

I just did some extra tests with 2.0.41 no issues.

Here's a screenshot.

BTW, the vids of two published versions absolutely CAN be the same. It's called setSyncing.

Here's the API

https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Entity%21...

It's possible that one of your scheduled publishing modules is mangling the revisions. I suggest switching to scheduled_transitions and dump yours or fix yours.

I am not using any scheduling... and I think you are confused about syncing.

Here's another screenshot.

We've had clients use this for years, only under extreme circumstances has there ever been an issue (such as during a DDoS attack or some service availability issue)

Even then, unable to reproduce, try and reproduce the issue!

Please provide the steps to reproduce with WxT 5.3.4 or WxT 6.1.2 or some other build

Your screenshots are useless... you need to edit content along the way at each transition in each language and look at what the result is in the end to see the data loss. I thought I had provided the steps but if you need them much clearer than that I will do so. Plus the originator of the issue also provided some clear steps that indeed reproduced the issue for me.

It's possible we're not seeing these issues due to using entity_translation_unified_form which also sync's the revisions. Please update the issue summary with clear and well defined steps to reproduce in chronological order.

The current issue summary (not very descriptive on what transitions they've configured) describes version 3 which is COMPLETELY different from version 2 and requires additional configuration. I've tested version 2 extensively. @joel_osc, please provide your steps to reproduce the issue for version 2.0.41.

For version 2 it's easier, editorial workflow, standard, not customized, otherwise no guarantees.

I can also confirm this issue, and I agree that it is critical, as indeed it can result in data loss.

Although it gets even more complicated when translations are involved, it can also be reproduced on a single language site without translations. (At least I suspect that the root cause is related). Here's the simplest case of steps to reproduce:

Tested on: Drupal 11.2.5 (standard profile, clean install), module version 3.0.0-rc2, workflow: standard editorial
Content type: Article (comes with standard profile)

1. Create an article with body text 'REV 1', add revision log message 'REV 1' and save as Draft
2. On /admin/content view select the article and apply: 'Publish latest revision'
3. The result is correct, the article gets published, and when visiting /node/1 with Anonymous user, the article is accessible with body text 'REV 1'
4. Edit the article, change body text to 'REV 2', add revision log message 'REV 2' and save as Draft. At this point, this will be the latest revision of the node (in Draft state). The current revision (the published one) is still the same, visiting /node/1 I see the body text 'REV 1' (correct)
5. On /admin/content view select the article again and apply: 'Publish latest revision'
Expected: on the node page I expect to see the latest version as published with body text 'REV 2'
Actual: the body text is still 'REV 1'

Looking at the revisions tab of the node at this point, I can see 2 revisions in the history, both are the ones created when the bulk action was applied with message: 'Bulk operation publish revision'. I think this is also not as expected as both revision with log message 'REV 1' (created in step 1) and the revision with log message 'REV 2' (created in step 4) are missing (and also the contents of those revisions, meaning that the content 'REV 2' cannot be restored).

This is the simplest steps I could demonstrate the issue, but if the scenario would be adding multiple additional revisions (content edits) in draft state (after step 4), then applying the bulk action (current step 5) would remove all previous draft revisions, and would create one single current published revision that is the same as the previous published revision (i.e. all the draft edits are lost, and we reverted to the original published version).

As mentioned above, the issue indeed also exists with translations where it gets more complicated, as the results also depend on which selected translations the action is applied on in a given bulk operation. However, I think that the scenario I described could be related to the issues with translation revisions.

@keszthelyi since you're using the standard editorial workflow I would suggest to stick to version 2.0.41+.

With that said, those are pretty clear steps so I'll have to try this when I get a chance.

As for 2.0.x, we use it along with entity_translation_unified_form enabled node edit/add forms which allows editing both languages at once so this is likely why I haven't noticed the issue myself. @keszthelyi have you tested with 2.0.x?

Until I have a closer look at this - If you install and configure https://drupal.org/project/entity_translation_unified_form , should resolve the issue when using 2.0.x

That is not reasonable... I can also reproduce this and will provide steps shortly. But recommending a module that has nothing to do with this one is irresponsible. Please stay focused on the issue at hand.

@joseph.olstad I only used standard editorial workflow for the tests and because it makes it easier to give steps to reproduce as it is configured already. Also, I could reproduce the same issue on version 2 of the module.

@joel_osc, this module "moderated_content_bulk_publish" was originally written for the Prime Minister of Canada who's stack relies on the entity_translation_unified_form module (they still use it today). This "ETUF" module which I like to call it just received a major feature enhancement contributed by another Canadian department. I took the original authors custom code (an employee created code) for moderated_content_bulk_publish and turned it into a contrib module with their blessings. Since then (about 6 years ago) , they use this version.

The Prime Minister of Canadas website also paid for a lot of bug fixing in ETUF in the early development years and since I've used it on other projects. They also helped develop moderated_content_bulk_publish and have recently submitted an unrelated patch for this module.

With that said, I'm open to reviewing merge requests and patches to fix things for others that aren't using ETUF in order to support translation workflows with moderated_content_bulk_publish. I also recognize that 95%+ of the installs of this project do not deal with publishing many translations however my intent always has been to support this and ensure it works.

It would be great if someone put forward a patch or merge request that helps. There's quite a bit of regression testing involved. I recently added a basic phpunit test and was working on a more relevant phpunit test for moderated_content_bulk_publish but got hung up on a few things. I'd like to focus on completing automated test coverage as well as support your workflows.

Please do not take my suggestion of ETUF lightly, it is a mature solution and one that is greatly appreciated by the Prime Ministers teams as well as many others that use it.

To avoid introducing regressions (since this project works for many now) I prioritize issue 3549650.
#3549650: Add bulk moderation test to 2.0.x

Meanwhile if you have a patch /merge request to submit that helps, please do submit it.

I'm working on the "Add bulk moderation test" , the coverage initially won't cover the scenario listed above, I'll get a basic bulk moderation test written first and then add coverage to test the above scenario to see if that can help lead to a reliable fix that works for everyone.

Right now the bulk moderation test coverage is targetting the 2.0.x branch. I'll then port it over to the 3.0.x version in a new issue. (a lot of work doing this so I'll split it up and allow myself and others to get more credits if they help out).

*** UPDATE ***

1. completed "#3549650: Add bulk moderation test to 2.0.x"
2. completed #3552164: Port bulk moderated publishing test to 3.0.x
3. completed #3552166: Add test coverage for bulk moderated publishing translated content 2.0.x
4. completed #3552204: Add test coverage for bulk moderated publishing translated content 3.0.x

*** END UPDATE ***

Just realized today that I’m listed as a maintainer on this project. Thanks everyone for the detailed reports and steps!

I’ve reviewed the thread and I agree with the core concern: this module should not require ETUF to avoid data loss. While the original implementation was developed on a stack that used ETUF (which keeps EN/FR revisions in sync and changes revision behavior), recommending ETUF as a workaround isn’t reasonable here because it fundamentally alters how revisions are managed.

I’ve run into similar issues with moderated multilingual workflows; publishing must target the intended revision for each language. Without careful selection of the source revision per translation, it’s easy to publish the wrong state or discard draft changes.

I think comment #22 is on the right path, we should add tests to capture the scenarios reported here so we can fix without regressing existing installs:

• Single-language, standard editorial workflow: publish latest revision via VBO when newer drafts exist (per @keszthelyi’s steps).
• Multilingual with moderation: drafts in multiple languages → bulk publish only selected translations vs. all languages.
• Test both View bulk operations and Node bulk operation actions.
• Verification that correct source “latest” translation revisions are published and that intermediate draft revisions are not discarded.

Ok, I believe I have created the test coverage (in this merge request) that prooves there's a problem for this use case.

https://git.drupalcode.org/project/moderated_content_bulk_publish/-/jobs...

With that said, next is working on a potential fix.

Hoping to soon have a fix.

https://git.drupalcode.org/project/moderated_content_bulk_publish/-/merg...

All tests are passing.

Thanks all, sorry for the long wait.

3.0.0-rc3

AND

2.0.42