Node Revision Delete

The Node Revision Delete module lets you track and prune old revisions of content types.

Features 2.x

You can configure how many revisions you want to keep per content type and configure how long revision should be kept. When saving the configuration you can optionally start a batch job to queue all content to delete revisions that are allowed to be deleted. For this you need the
'Administer Node Revision Delete' permission.

The 2.0.x version of the module uses plugins of type NodeRevisionDelete to configure whether a revision should be allowed to be deleted. The module ships with the following plugins:

• Define a minimum amount of revisions to keep per content type.
• Define a mimium amount of months to keep revisions per content type.
• Define a mimium amount of months to keep draft revisions per content type.

Drush commands

drush node-revision-delete:queue

Adds all content to a queue to delete revisions for the content.

Features 1.x

• Define the max amount of revisions to keep per content type.
• Run on Drush, cron run or on a different period (daily, weekly, etc).
• When you are deleting a revision of a node, a new checkbox will appear in a fieldset saying: "Also delete X revisions prior to this one."; if you check it, all the prior revisions will be deleted as well for the given node. If you are deleting the oldest revision, the checkbox will not appear as no prior revisions are available

Drush commands

drush node-revision-delete

Deletes old node revisions for a given content type.

drush nrd-delete-cron-run

Configures how many revisions delete per cron run.

drush nrd-last-execute

Get the last time that the node revision delete was made.

drush nrd-set-time

Configures the frequency with which to delete revisions while cron is running.

drush nrd-get-time

Shows the frequency with which to delete revisions while cron is running.

drush nrd-when-to-delete-time

Configures the time options for the inactivity time that the revision must have to be deleted.

drush nrd-minimum-age-to-delete-time

Configures time options to know the minimum age that the revision must have to be deleted.

drush nrd-delete-prior-revisions

Delete all revisions prior to a revision.

Submodules

Node Revision Generate

Generates node revisions. This module is for testing.

Resources

• Article: Module Monday: Node Revision Delete
• Video: Drupalize.Me Node Revision Delete tutorial video. (non-free)

Similar Projects

Node Revision Bulk Delete

The module gives an extra feature to delete manually all revisions of a specific node prior a selected one.
Differences:

• All the features of this module are present in the Node Revision Delete module.

Node Revision Cleanup

The concept behind this module is to be able to run multiple invocations at the same time, via Drush to maximize the number of node revision deletions per second.
Differences:

• Don’t have user interfaces, is a collection of drush commands to configure and clean revisions
• You can't delete all revisions of a specific node prior a selected one.

Revisionator

This module clean up insightly old revisions removing revisions older than the specified age, leaving a minimum number of revisions per node.
Differences:

• All the features of this module are present in the Node Revision Delete module.

Node Revision Restrict

Restrict revisions of node for each content type. This module has an admin interface to specify node revision threshold for each content type available. The possible setting include node type with corresponding revision limit, provided on the Node Revision Restrict configuration form.
Differences:

• All the features of this module are present in the Node Revision Delete module.

Revision Deletion

Enables the ability to mass delete aging node revisions. Possible settings include node type, the age of node revision before being deleted, along with a cron frequency setting.
Differences:

• All the features of this module are present in the Node Revision Delete module.

Node revisions autoclean

Allows to manage node's revisions store, older revisions are automatically deleted. You may choose how many revisions you want to keep for each node type. Latest drafts coming after a published revision are never deleted. You may also choose to delete revisions by date.
Differences:

• All the features of this module are present in the Node Revision Delete module.

Revision disintegrate

In heavy editorial environments, revision enabled entities may end up having many very similar revisions. Over time, as the database grows, the value of these revisions diminish. This module will delete these 'lesser valued' revisions by comparing revisions from a set of parameters
Differences:

• You can clean the revisions based on the followings parameters:
  • When was the previous revision saved
  • Has there been a change of author since the last revision?
  • How much of the actual text differ?
  • Is it the first revision ever? (Nice for historical reasons.)
• You can’t restrict revisions for each content type
• You can’t set how many revision should be keeped in each node
• You can't delete revisions based on the node inactivity time
• You can't delete all revisions of a specific node prior a selected one.

Revision Purger

Allows deleting revisions of entities.
Differences:

• You can delete revisions of other entities different than nodes.
• You can’t restrict revisions for each content type
• You can't delete revisions based on the node inactivity time
• You can't delete all revisions of a specific node prior a selected one.
• There is not drush commands to configure or run node revisions cleanup

Revision Snip

The Revision Snip module provides a utility to prune node revisions that are older than a certain number of days from the database.
Differences:

• All the features of this module are present in the Node Revision Delete module.

Support

If you need paid support beyond the issue queue, or you need custom functionalities, you can drop a message to the main developer.

Issues

If you love the Kanban Boards we have one thanks to ContribKanban.

As with all contributed modules, when considering submitting an issue:

1. Read the documentation (two or three times is better). Don't forget the home page.
2. Review the existing issues list. (Don't forget to select "<- Any ->" for the "Status" field.)
3. Gather all the appropriate information. This may include (but is not limited to):
   • Drupal version.
   • Browser type and version.
   • Database type and version.
   • Error messages, if any.
   • Module settings.
4. Submit the issue. If other modules are involved, you may need to submit the issue to those modules as well.
5. If you go to provide a patch use the following naming convention:
   [node_revision_delete]-[short-description]-[issue-number]-[comment-number]-[drupal-version].patch

And please don't forget to use the Issue Summary Template to report an issue, if you need help to understand how the issue queue works, see the Getting Started in the Issue Queue video.

Development version status

The development versions (-dev) are where the newest stuff is, including any bug fixes and new features. We try to make sure it is tested before we commit anything, but occasionally a bug will get from us. Your help in testing this code is greatly appreciated. The translation templates may not always be up-to-date in the dev releases.