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.I would like to provide some useful options related to content moderation for this module.
1. Give the choice to the users to keep node revisions with "Published" moderation state.
2. If 1. is selected, give further choice to users to save revision logs and basic data from deleted revisions into the closest published revision. This second option would allow to remove most "draft/working/in progress" states revisions while still keeping some logs about what happened in the published revisions which are kept alive.
| Comment | File | Size | Author |
|---|---|---|---|
| #31 | interdiff_28_to_31.txt | 2.62 KB | joseph.olstad |
| #31 | 3217675-31.patch | 3.97 KB | joseph.olstad |
| #30 | This_option_does_not_remove_published.png | 10.52 KB | joseph.olstad |
| #28 | interdiff_26_to_28.txt | 1021 bytes | joseph.olstad |
| #28 | 3217675-28.patch | 3.96 KB | joseph.olstad |
Comments
Comment #2
casaran CreditAttribution: casaran commentedHere is the first try for a patch.
Comment #3
casaran CreditAttribution: casaran commentedAnother try. The patch is actually applying against 1.x-dev, I tested it locally.
Comment #4
casaran CreditAttribution: casaran commentedComment #5
itamair CreditAttribution: itamair as a volunteer commentedThe patch is not applying correctly because the patch is looking for a file "/src/NodeRevisionPublishedDeleteBatch.php" that doesn't exists ...
Probably that patch is malformed, and generated on a code base that is already an amend of 8.x-1.x-dev
Comment #6
casaran CreditAttribution: casaran commentedAdding README documentation.
Comment #7
itamair CreditAttribution: itamair as a volunteer commentedComment #8
itamair CreditAttribution: itamair as a volunteer commented@thanks Casaran
This new patch is providing the following enhancements:
- default definition of the additional module settings in the install/config file, and extension of the schema accordingly;
- more defensive code for checking the existence of the "content_moderation" module enabled;
- improved drupal/php coding standards;
...
Comment #10
casaran CreditAttribution: casaran commentedThank you @itamair
One more version, based and yours but putting all the save log logic inside the batch. This is to avoid a timeout when we have too many revisions.
Comment #11
itamair CreditAttribution: itamair as a volunteer commentedIt looks these last patches are causing some tests failing ... so I guess they stil need some fixes, at least on their part that break the existing tests (or the test should be adjusted accordingly)
Comment #12
vistree CreditAttribution: vistree commentedHello!
can someone explain the problem to me in a little more detail? I don't understand it at the moment. Shouldn't a node have only ONE published revision? Is there currently a problem using the module in combination with content moderation? It is the core content moderation that the author is referring to, right?
Comment #13
vsujeetkumar CreditAttribution: vsujeetkumar at Material for Drupal India Association commentedFixing fail test in #10.
Comment #14
casaran CreditAttribution: casaran commented@vistree
There is no issue per se. It's just added features.
And yes it's about the core content moderation. Let's consider the following use case. You have one node which you first save as a draft, then publish. later on you edit it again and save as draft and publish it again after that. So you have 4 revisions, 2 "draft" and 2 "published". The goal here is to remove the draft revisions while keeping the published ones, because it might be a legal requirement in some cases to always keep what has been officially published and displayed on a website. That's all!
Comment #15
vistree CreditAttribution: vistree commented@casaran: thanx for explanation. Now I got the "problem" behind this issue ;-)
Comment #16
mkolar CreditAttribution: mkolar at Ciklum Western Europe for BurdaForward commentedi can confirm this works, maybe one suggestion is: it would be good if you can select how many published revisions to keep because you can end up with lot of published revisions which are all excluded. But this helps anyway! Thank you!
Comment #17
mkolar CreditAttribution: mkolar at Ciklum Western Europe for BurdaForward commentedMarking as OK, works as if. I don't think this needs to be blocked by my upper comment.
Comment #18
mkolar CreditAttribution: mkolar at Ciklum Western Europe for BurdaForward commentedComment #19
mkolar CreditAttribution: mkolar at Ciklum Western Europe for BurdaForward commentedI think there should be rather option to keep latest default revision, for our project i thought this will help but found out we have to keep latest default revision, here is why: imagine you have article in published state, then it god unpublished (which is default revision) so article should be unpublished, then article gets some drafts... with current version of module + this patch the unpublished revision will be deleted which makes article public again, this is wrong! There should be option to omit last default revision and not hardcoding it to "published" state because with moderation state, there could be also other state which is marked as published.
Comment #20
smulvih2I tested this patch and it doesn't seem to play nice with content translations.
First I created an English node and added a French translation. Then I added a bunch of revisions to English and a bunch of revisions to French.
English revisions:
French revisions:
Candidates for deletion:
As you can see in the last image above, all published and draft English revisions are candidates for deletion except the latest draft revision. On the French side, only the first draft (Brouillon) revision is a candidate for deletion, and all other published and draft French revisions will remain.
English revisions after deletion:
French revisions after deletion:
After deletion, only one English draft remains and the deleted revisions logs are not copied to it. On the French side, only the first draft revision is deleted and all English and French deleted revision logs are appended to the first published French revision.
I think there is some overlap with #3118464 in terms of accounting for content translations.
Comment #21
seanBWe just added a 2.x version of the module. This is a complete rewrite based on plugins to determine which revisions can be deleted. It also uses a queue worker to actually delete revisions. The default revision will never be deleted by the queue worker. Could you please test if this solves the issues you currently experience?
Comment #22
joseph.olstadPatch #13 does not apply to 2.x
It would be nice to have translation support.
Comment #23
seanBVersion 2.x does not need the patch and should already fix the issue :)
Comment #24
joseph.olstadok great, thank you @seanB
Comment #25
joseph.olstad@seanB,
After extensive testing we came to the conclusion that version 2.x doesn't fix this issue,
I'm still reviewing possible action to take.
Comment #26
joseph.olstadI haven't tested this yet.
Comment #27
joseph.olstadComment #28
joseph.olstadOk this one works, nice design for this 2.x version, was easy to implement this solution.
Comment #29
joseph.olstadComment #30
joseph.olstadI'd say forget about doing this in 1.x, upgrade to 2.x, check patch #28, it works well, there's a new configuration option added.
Comment #31
joseph.olstadnew patch
and interdiff
Comment #33
adriancidThanks
Comment #34
joseph.olstadhttps://www.drupal.org/project/node_revision_delete/releases/2.0.0-beta1
Thanks for the release! Now everyone can enjoy it without patching.