The 2026 Drupal Business Survey is open. Your response will help shape the future of the Drupal business ecosystem.Problem/Motivation
When using the Revision Manager module, selecting both Age and Amount as criteria for deleting old revisions does not behave as expected.
If revisions are collected based on the Age filter first, the module deletes all revisions older than the configured age, without applying the Amount (maximum number of revisions to retain/delete) constraint.
This results in more revisions being deleted than intended and ignores the configured “maximum amount” limit.
This issue may lead to unintended data loss, especially on content types with many revisions.
Steps to reproduce
Install and enable the Revision Manager module.
Configure a cleanup rule and select both conditions:
Delete revisions older than X days (Age)
Delete only X number of revisions (Amount)
Run the revision cleanup process using cron or manual execution.
Observe the list of revisions selected for deletion.
Actual behavior:
All revisions older than the Age setting are marked for deletion, ignoring the Amount constraint.
Expected behavior:
Revision selection should first filter by Age and then respect the Amount limit, deleting only up to the specified maximum number.
Proposed resolution
Update the revision selection logic so that when both Age and Amount are selected:
Filter revisions based on Age.
Apply the Amount limit to the filtered set.
Ensure the Amount value is respected as a hard cap on the number of revisions deleted.
Add test coverage to verify that combined criteria work as expected.
Review the current query or service responsible for collecting candidate revisions and adjust logic ordering if needed.
Remaining tasks
Confirm exact location of the revision selection logic in the module.
Implement updated logic to apply Amount constraint after Age filtering.
Add automated tests to cover combined Age + Amount cases.
Review and update documentation if needed.
Submit merge request / patch for review on Drupal.org.
User interface changes
No UI changes expected.
All modifications occur in backend logic.
Optionally: Add helper text clarifying how Age and Amount interact when both are selected.
API changes
No public API changes anticipated.
Internal logic adjustments may affect internal service or query behavior, but no API contracts will be altered.
Data model changes
None.
No schema or entity changes are required.
| Comment | File | Size | Author |
|---|---|---|---|
| #19 | revision_manager-3560354-intersection-change-19.patch | 9.48 KB | j-barnes |
Issue fork revision_manager-3560354
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #7
j-barnes commented@raajkumar.kuru - Thanks for the detailed write up. Originally the idea was to have each plugin work independently in a sequence, each performing its own deletions. The process would look like this:
1. Each plugin independently identifies deletable revisions
2. Each plugin's deletions happen immediately before the next plugin runs
3. There's no coordination between plugins
However, the previous node_revision_delete implementation used an AND operation across all plugins - only deleting revisions that were marked for deletion by all enabled plugins.
I can see where this approach would be beneficial:
- More defensive: Acts as a safety net against unexpected data loss
- More intuitive: Users naturally expect "keep at least N revisions" to be a hard floor, regardless of age
- Order-independent: The result is the same regardless of which plugin runs first
Given that, I think it might make sense to switch the approach. If should be relatively straightforward to implement, essentially taking the intersection of all deletable revisions identified by each plugin before performing any deletions.
Comment #8
raajkumar.kuruComment #9
raajkumar.kuruComment #11
j-barnes commented@raajkumar.kuru - Thanks again for the patch and detailed report! I've switched to an intersection strategy for when multiple plugins are enabled. This should match what most users expect. Let me know if it solves your issue, I'll add a patch as well.
Before (sequential):
- Age deletes 5 old revisions first
- Amount then runs on remaining 7, deletes 4 more to keep 3
- Result: 3 remain
After (intersection):
- Age candidates: 5 (old revisions)
- Amount candidates: 9 (keeping newest 3)
- Intersection: 5 (only what both agree on)
- Result: 12 - 5 = 7 remain
We already had integration tests covering this scenario - just updated the expected counts to reflect the new behavior.
Since this change results in more revisions being kept (not fewer), it's the safer direction. Most users probably won't notice the difference, and those who do should appreciate having Amount act as a proper safety net.
Comment #16
j-barnes commentedComment #17
raajkumar.kuruWhen the revisions to delete from the Amount candidate are zero, but the Age candidate returns a non-empty list of revisions to delete, the code incorrectly returns all revisions from the Age candidate.
This happens because the condition is treated as an AND, but the current logic behaves like an OR.
In short:
Age candidate returns some revisions to delete
Amount candidate returns zero revisions
The intersection logic still returns the Age candidate’s revisions
This is incorrect — the intersection should be empty.
The line causing the issue:
This line keeps any non-empty candidate list, which breaks intersection logic.
Comment #18
raajkumar.kuru.
Comment #19
j-barnes commentedGreat catch! Fixed the logic and added tests covering the empty candidate cases. Give it a try and let me know how it goes.
Comment #20
j-barnes commentedComment #21
raajkumar.kuruIts working as expected.
Good to merge
Comment #22
sunny-lee commentedLooks great here! Saw the issue on test as well and on several nodes on test there were only 1 or 2 revisions left but after this fix there was consistently 3 or 5 - the amount it was set for so it is correctly using 'AND'.
Comment #24
j-barnes commentedMerged, thanks everyone!
Comment #27
pfrenssenThanks all for this change! I think indeed this is the safest way to do it. There are 2 ways of interpreting the use of multiple plugins together and we should go for the conservative approach.