Content Versions

All content in dotCMS maintains a change history that lists all previous versions of the content. The change history (and each older version) of any piece of content can be viewed, and the content can be reverted to older versions if desired.

Saving and Publishing New Versions

Each time content is saved, the following occurs:

• A new version of the content is created (with the same content identifier, but a new inode).
• The new version is set to be the Working version of the content.
• The previous Working version is kept (and may be accessed from the History tab - see below).

Each time content is published, the following occurs:

• The current Working version of the content is set to be the Live version.

Version History

To view all saved versions of the content, open the content properties and select the History tab:

The History tab displays the Identifier of the content. In addition, the History tab displays the following information for each version of content:

Actions

You may take the following actions for any piece of content:

Identifiers and Inodes

Each piece of content in dotCMS is identified by unique keys: the identifier and the inode. Since each piece of content is automatically assigned these unique keys, you can create content types and individual content items which share the value of multiple fields (such as the Title) without causing conflicts.

These two keys have two different but related purposes. In most cases, content contributors do not need to understand or pay attention to the identifier and inode; however if you are a content architect, site builder, or web developer and plan to access content in dotCMS via Widgets or Velocity code, it is important to understand the difference between these two different keys.

Identifier

The Identifier identifies the individual piece of content, without specifying a specific version of the content.

• When you first create any new piece of content, it is assigned a unique identifier.
• As you edit and save changes to that piece of content, and as you create different versions of that content (for example, versions of the content in different languages), the identifier always remains the same.

inode

The inode identifies a specific version of a piece of content.

• As you edit and save changes to content, each saved change is stored and identified as a separate version, and each version is assigned it's own unique inode.
• It is common to have multiple versions of the same piece of content.
  • For example, when you have unpublished changes to a piece of content, your active Live version and Working version of content are different.
  • In addition, when you create versions of the same piece of content in multiple languages, each language version of the content is a separate version.
• All versions of a piece of content share the content Identifier, but each version has its own unique inode.

Accessing Content by Identifier vs. inode

In most cases, when you access content in dotCMS using a content identifier, you may access the content using either of these keys, and which version of the content you retrieve will depend on whether you use the identifier or the inode:

• When you access content by the identifier, you will always retrieve the most recent version of that content.
  • If you access the content in Edit or Preview mode, you will retrieve the most recent Working version of the content.
  • If you access the content in Live mode or from the front-end, you will retrieve the most recent Live version of the content.
• When you access content by inode, you will access the specific version of content identified by that inode.
  • Even if a newer version of that content has been saved and published, you will still access the specific (possibly older) version of the content specified by the inode supplied.

Storage and Automatic Cleanup

dotCMS has a built-in job that automatically prunes significantly old versions of content. In particular, past versions of file assets and contentlets in excess of a year old, and in excess of 100 content versions, are deleted by default without any action by the user. Along with clearing up storage, this is also meant to decrease the number of hard links created in cloud environments, and speed up synchronizations, backups, and upgrades.

This deletion routine only prunes content that exceeds both the age and the version-count limits. Older content versions under the count limit will not be affected, nor will excess versions that are still young.

However, this default behavior can be adjusted through environment variables.