Content Versions

Last Updated: Feb 26, 2024
documentation for the dotCMS Content Management System

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:

Each time content is published, the following occurs:

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:

StatusThe content state of the version (Working and/or Live).
ActionDisplays one or more actions, as appropriate for the Status of the version.
TitleThe Title of the content version (e.g. the Title of the content when that version was saved).
AuthorThe user who saved the version.
Modified DateThe date the version was saved.
inodeThe inode of the version.


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

ViewTo view a particular version of the content, click the Title of that version.
After clicking the Title, you may view all fields of the content in the other tabs.
DeleteIf a version is not the Live or Working version, you will have the option to Delete it.
Warning: A version of content may not be restored once it has been deleted, so do not use this action unless you are sure you will never need to recover the version.
Note: Please also see the Drop Old Asset Versions documentation.
Bring BackIf a version is not the Live version, the Bring Back option will display.
Selecting this action (and then verifying in the confirmation pop-up) reverts the content to the selected version.
The reverted version becomes the new Working version of the 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.


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.


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.

Property/VariableValue TypeDefaultDescription
DOT_CONTENT_DROP-VERSIONS_ENABLEDBooleantrueEnables or disables the pruning job.
DOT_CONTENT_DROP-VERSIONS_CRONCron expression0 0 0 1 * ? *Determines how often the job will run, as defined by a Cron expression.
DOT_CONTENT_DROP-VERSIONS_OLDER-DAYSInteger365Identifies the maximum allowable age of a content version. If the version's age, in days, is greater than the value set, it can be marked for deletion.
DOT_CONTENT_DROP-VERSIONS_GREATER-THANInteger100The maximum number of content versions stored per language. E.g., if set to 100, a contentlet with 120 versions may, according to age, shed its 20 oldest versions.
DOT_CONTENT_DROP-VERSIONS_OLDER-DAYS_BATCH-SIZEInteger500Sets the size of the batch of versions to be deleted each time the job runs. As such, the pruning takes place in a staggered, gradual fashion, to limit the operations' system footprint. To have the whole process finish sooner, for example, dotCMS recommends smaller batches run more frequently.

On this page


We Dig Feedback

Selected excerpt: