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:
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:
|The content state of the version (Working and/or Live).
|Displays one or more actions, as appropriate for the Status of the version.
|The Title of the content version (e.g. the Title of the content when that version was saved).
|The user who saved the version.
|The date the version was saved.
|The inode of the version.
You may take the following actions for any piece of content:
|To 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.
|If 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.
|If 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.
- 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.
- 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.