Revisions
Like most websites, our example site cookiewiki.com has many web pages. There are fixed pages, such as the home page, contact page etc. There are news stories, such as announcements of upcoming cookery events, or forewarnings of planned site maintenance. These are pages which can only be edited by the site administrator for obvious reasons.
Then there are the many, many recipe pages, which can be added and ammended by anyone who cares to enter a throwaway email address and register as a member (aka authenticated user). Letting people enter their own recipes, after all, is the point of the site.
Drupal retains all of this site content in its database. If someone edits a node, the new content replaces the old. The old content is lost forever.
With revisions, you can keep several versions of the same web page. Only one version is actually visible on your website, but the other versions are still there. Normally, the latest revision is displayed, but you can very easily choose to show one of the other revisions instead.
Why use revisions?
There are many reasons why you might want to use revisions, but for illustration we will describe a couple here.
Suppose you want to change your front page to highlight a promotion or special event, or even just to display a special holiday message for your visitors. At the end of a certain period, you want to remove the message and return to your normal front page.
You could do this by manually removing the changes to get your original page back, but that is rather tedious, and you could make a mistake. An easier way is to create the special front page as a revision, so your original front page is still there. At the end of the period, simply change revisions, back to the normal front page. You can then either delete the special page, or keep it around for next time.
A second use is to protect your content. cookiewiki.com allows members to add and ammend recipes, which works well most of the time. But once in a while some joker thinks it would be funny to vandalise a recipe. This could be a real pain if the original recipe was lost, but if you make recipes use revisions by default (and you don't allow members to change that default), you can easily delete the vandalised revision, and return to the original.
Even if you are the only person editing content, it can still be useful to use revisions. Sometimes you might edit a piece only to decide, on re-reading it, that you really prefered the old version. You might be able to restore the old version from backup, but that can be a long-winded process. With revisions, it is very simple.
Creating revisions for a specific page
You can create a new revision of a particular page (eg your front page) as you edit it. In the Revision information groups, check the Create new revisions checkbox. If you wish, you can also enter a Log message to remind you what this revision is.
Creating revisions for all content
You can automatically create revisions for all content of a particular type. For example, to ensure that revisions are kept for all Recipe content:
- Click Navigation | Administer | Content management | Content types.
- Click edit for the Recipe type.
- In the Workflow settings group, ensure that Create new revision is checked.
As administrator, you will still have the option to override this (ie to make an edit without creating a new revision) by swithcing revisions off when you edit the page. However, a normal user will not have the option to do this, unless you specifically allow it.
Managing revisions
When you view a page, as administrator, you will normally see the usual two tabs at the top of the page, View and Edit. As soon as you create revisions for a page, an extra tab appears, called Revisions.
If you click this tab, you will see a list of the revisions for that page. The current revision (ie the one which users see when they visit the page) is at the top, earlier revisions are below it. For each revision you can see who created it, when it was created, and the log message (if any).
Next to each revision (except the current revision) are links to revert and delete. Delete, fairly obviously, deletes the revision.
Revert might not work quite as you expect (although the way it works is actually very sensible).
Suppose you create a new node. We will call this the original version. You then edit it, creating a revision, which we will call Rev A. You then edit it agin, creating another revision, which we will call Rev B. The revisions list looks like this:
- Rev B (current revision)
- Rev A
- Original
Now suppose we wish to revert ro Rev A, by clicking the revert link next to Rev A. If you were expecting this to move Rev A to the top, that is not quite what happens. Actually, a new revision is created, labelled as a copy of Rev A:
- Copy of Rev A (current revision)
- Rev B
- Rev A
- Original
There are two good reasons for this. First, it records a history of who did what, when. There might be several trusted users who have permission to manage revisions. The user who reverts to Rev A might not be the same user who created Rev A. If trusted users have permission to revert, but not delete, revisions, you will have an audit trail.
The second reason is more subtle. It is always possible to edit the current revision, without creating a new revision, thus losing the current content. At some point in the past, someone decided that Rev A was important enough to keep. As soon as Rev B was created, Rev A was set in stone. Simply because we have decided to revert to Rev A should not automatically reverse the decision to preserve Rev A.
By creating a copy of Rev A, the original is not at risk of accidental modification. It is still possible to deliberately delete Rev A of course (as it should be, for anyone with the correct permissions).