Magnolia versions pages, assets and contacts by default when they are published and unpublished. You can also configure versioning for any other content type.
A fresh Magnolia installation does not have versioned content. Demo content is bootstrapped and immediately marked as "published". You see a green publication status icon but no publication has actually happened.
Versioning is functionally usable only on the admin instance, where you can use it to restore and republish an older version of some content. In case you wanted to let the visitors of your site browse through and see historic versions of, for example, a terms and conditions page, you would have to develop custom code for this feature.
The Show versions action provides access to versions. This action is available in the Pages, Assets and Contacts apps and opens a dialog containing a list of versions. If workflow is enabled, the workflow comment is appended for each version (second set of brackets).
To show a version, select the version and click Show. The selected page, asset or contact opens for viewing. You cannot edit the item in the view mode.
In the Pages app two additional actions are available:
- Compare to previous version compares the current to the previous version and opens the page in diff view that uses redlining: deletions are highlighted in red and insertions in green.
- Compare versions allows you to select the versions to be compared. Select a From and To version and click Compare to open the page in diff view.
The Restore versions action allows you to revert to a previous version. It is available in the Pages, Assets and Contacts apps. Select the version and click Restore. A new version is created automatically prior to restore. After restoring you need to publish the restored item.
Versioning functionality is enabled by default in Magnolia in the Pages, Assets and Contacts apps. Versions are saved automatically and can be reverted to as necessary.
The versioning functionality is enhanced by the Diff module that adds diff and redlining capabilities.
By default, versions are created when pages, assets and contacts are published, unpublished and restored in the related apps. Versions are also created in these apps for the purpose of restoring items prior to deletion. For more information see Deleting and restoring.
Versioning can be enabled by configuration for any content app.
In a new installation of the Magnolia bundle all demo pages, assets and contacts do not have versions even though the status indicator is green (published). This is because the content is marked as published when bootstrapped into the web applications, but no actual publication has taken place at this point in time. The available versions actions remain inactive until actual versions are created by publishing, unpublishing or deleting.
Enabling versioning in content apps
You can enable versioning in a content app by triggering the
activate/deactivate command chains in the
versions catalog instead of the
activate/deactivate commands in the
default catalog. Here is the process to enable versioning in the Categories app.
In the Configuration app >
/deactivatenodes add a
catalogproperty and set the value to
versioned. This calls the chained version command configured in the
Node name Valuemodules
Add the Show versions action configuration.
/actionsnode add the
/showVersionsconfiguration as shown below. Alternatively, you can simply extend the configuration in another content app, for example the configuration in the Contacts app configured in
Node name Value
Add the Show versions action to the action bar.
/actionbar/sections/category/groupsnode, add the
/versionsActionsconfiguration shown below. Alternatively, you can simply extend the configuration in another content app, for example the configuration in the Contacts app configured in
Node name Value
In the Categories app, create a few versions by activating and deactivating an item and then execute the Show versions action to open the VERSIONS dialog.
Number of versions
The number of versions you can create depends on the Magnolia edition:
- In the Community Edition, the number of versions is set to 3 and this is not configurable.
In the Enterprise Edition, the number of versions is unlimited and you can set it in configuration. By default, 10 versions are stored.
The number of versions is configured in
activeenables and disables versioning.
maxVersionIndexsets the number of versions to store.
Previous versions are deleted when you change to a smaller number and create a version. It's OK to change the number. The index won't be affected until a new version is created. For example, if node ‘A' has 10 versions and you change the max version index to 2, you will still see all 10 versions until the next versioning occurs. Once node 'A' is versioned again, all previous 9 versions will be removed.
Versions are created when VersionCommand is triggered. A new version of the content is created and added to the version file.
VersionCommand provides for standard and recursive versioning, and the addition of a version comment.
Here's the command definition in the
activation module in the Configuration app >
The command chains are triggered when the Publish, Unpublish and Publish deletion actions are executed in the various apps that use them. Here's the action definition for the Publish action in the Assets app configured in the Configuration app >
VersionDiffHtmlServlet is registered in the Magnolia filter chain in the Configuration app >
/server/filters/servlets/VersionDiffHtmlServlet. The controller generates the diff view between two versions of a page by checking the
fromVersionNr request parameters.
|Shows html diff of different page versions.|
The default settings for headers, cookies, host and port can be set by configuration.
By default Magnolia is set to generate a JSESSIONID cookie. This is configured in the
diff module in the Configuration app >
You can configure custom settings for:
cookies: You can specify any number of custom session cookie names to forward.
headers: The default value is
none. By adding a
headersconfig node you can specify any number of headers to be sent to the diff servlet thereby automatically excluding any headers that are not specified.
port: The default host and port is
8080. However, the Diff module will work even if you change the default Tomcat port. This means that you can use the diff functionality against another server.
Headers and cookies are configured separately.
Diff HTML generator
- The comparison only includes the body of the HTML document.
- The differences are marked with span tags.
- The header is taken from the HTML of the page that is compared to.
- CSS is added.
Here's a snippet from
diff.css (GIT) located in the
mgnl-resources folder of the module jar
Diff utility classes
Two utility classes are provided:
- DiffUtil provides the
- VersionComparisona POJO that
The CompareVersionsAction and CompareToPreviousVersionAction open the diff subapp (see below) configured in the Pages app. The action definitions are configured in the Configuration app >
|Compare to previous version|
The diff view that opens when comparing different page versions is configured in the Pages app. This configuration is in the Configuration app >
class: EmbeddedPageSubAppDescriptor embeds the page in an iframe.
label: Renders in the subapp tab.
subAppClass: EmbeddedPageSubApp is the main tab in an embedded page app.
diff subapp for the
/travel/about/what-we-believe . Note the reference to the and