Revisions

Whenever a component’s ->save() function is called without additional parameters a revision is created for that particular request. If, during the request, more components get saved, they get the same revision. The rivision is based on a timestamp and is stored in the component_revision table.

Revision system

When a revision is created 3 variables are stored on a component:

Field	Description
_revision	This field is set to the timestamp at which this revision was the live version.
_revision_from	This field is set to the timestamp the component was created and basically never changes
_revision_till	Once a revision is created, this field holds the timestamp till the moment a new revision has been created.

Storing these variables makes it possible to maintain every state of the website and restore it. Keep in mind that media files are not part of the revision tables. So once a media file has been deleted it can’t be restored the same way but a backup has to be restored. The process of restoring media files is much more tedious.

Restoring revisions

Restoring deleted revisions

Once a component is deleted from the component table all that remains are the component entries in component_revision. Restoring a deleted component can be done at database level as follows assuming you know the component id:

db.component_revisions
     .find({_component_id: <component_id>},{_revision_till: 1})
     .sort({_id: -1}).limit(1)

Note

You will need some details regarding the page that was deleted, a good start would be retrieving the _title property or the parent component.

Once you found the latest revision, which is the last state of page/component when it was deleted, it’s time to restore all the components for that specific revision by running the following commands:

db.component_revisions
    .find({_revision_till: "<revision_till_timestamp>"})
    .forEach(function(doc){
        db.components.save(doc);
    })

db.component_revisions
    .remove({_revision_till: "<revision_till_timestamp>"})

Re