I read thru the code a noticed that there are no cron tasks to add outdated revisions to the queue.
The queue adding relies on the node_update hook to check if the conditions are met, but if the nodes are not saved then they are not added to the queue.
New interface: NodeRevisionDeleteTimeBasedInterface::getDelay()
A getDelay(NodeInterface $revision) method is added to the NodeRevisionDeleteTimeBasedInterface. Each time-based plugin calculates exactly how many seconds remain until the given revision becomes eligible for deletion, based on the revision's changed time, the plugin's configured age threshold, and the current time. The Created and OnlyDrafts plugins both implement the new interface.
Queue worker changes
NodeRevisionDelete::doProcessItem()now:
min($delays) — the shortest delay across all plugins — as the requeue time. This ensures the node is rechecked as soon as the first revision becomes eligible.New queue worker: NodeRevisionDeleteRequeue
A new node_revision_delete_requeue queue worker processes delayed requeue items. Each item contains a nid and a requeue_time timestamp. If the requeue time hasn't arrived, it throws DelayedRequeueException. Once the time arrives, it moves the node back to the main node_revision_delete queue for reprocessing. The new queue exists to ensure that requeued nodes do prevent other nodes from entering the NodeRevisionDelete queue.
Show commandsStart 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 #2
bdunphy commentedCan confirm and I have bumped against this bug as well. This makes the module less useful in production uses. Having to save the outdated node in order to queue up revision deletion is not practical.
Comment #3
bwaindwain commentedSame here. We chose to use the "Delete revisions after a specific amount of time." and set it to 6 months. But nodes are only processed once after a save, then removed from the queue and never checked again. So, inactive nodes never get cleaned up.
We had to write our own hook_cron() similar to above.
To clean up manually, use drush commands or the GUI "Queue all content to delete revisions in the background."
Comment #4
alexpottI think this is a major bug for the module.
Comment #5
acbramley commentedThere is a
drush node-revision-delete:queuecommand which will queue every single nid for every single content type that has enabled plugins (i.e all of them if it's just using default config).When evaluating this module, that was the one glaring issue I found, there's no way to either a) batch queue existing content, or b) use plugin logic to find existing revisions that can be deleted without updating the nodes.
Comment #8
plopescTo try to address this scenario for our use case, we worked on the MR above.
It declares a new interface for NodeRevisionDeleteCronInterface that allows individual NodeDeleteRevision plugins to implement their specific periodical tasks.
Created plugin makes use of this interface to declare a cron method that loads a small number of entities whose revisions should be deleted and add them to the queue.
Comment #9
alexpottThis is a big new feature that involves a new interface - this is only going to land on the 2.1.x branch.
Comment #10
alexpottThe current approach has a problem because node_revision_delete plugins can be combined and it is possible that the plugin will only ever requeue content that has revisions that are being kept due to other plugins and therefore it'll stop working. Fixing this is a bit complicated. Not sure of the best solution. I'm thinking that we need to store the highest nid we get from the cron query and use that next time as the minimum nid. When we get no result we set the minimum nid back to 0. That way we constantly check new nodes so nothing gets stuck due to other rules.
Comment #13
alexpottUpdated issue summary with details of the change.
Comment #15
alexpott