The dotCMS Integrity Checker feature resolves conflicts between “out of sync” objects before attempting Push Publishing from one server to another dynamic push publishing endpoint. The integrity checker does not check static push publishing endpoints.
- Causes of Push Publishing Conflicts
- Integrity Checker (Dynamic Endpoints only)
- View and Resolve Conflicts
- Multilingual Sites
To access the dotCMS Integrity Checker select System → Configuration and select the Publishing Environments tab. The Check Integrity button will appear on each Sent To server after the successful configuration of a Push Publishing environment.
Causes of Push Publishing Conflicts
When users have the ability to create and publish objects on both the sending and receiving servers, out of sync objects can be caused by a content publisher manually placing the same named object on both the sending server and the receiving server. For example, if a content publisher logs into Sending Server A and creates a folder called “Accounting”, then logs into Receiving Server B, and creates the same “Accounting” folder manually, this creates a conflict because the identifiers on the servers do not match. Because the identifiers don't match, a push publish attempt from either server will fail, since push publishing only works with matching identifiers.
Therefore, as a best practice, content publishing in a “Push Publish” environment should only happen on the sending server, NOT the receiving server. To help prevent push publishing conflicts, permissions should be set to prevent regular content publishers from creating or publishing content on the receiving server.
Integrity Checker (Dynamic Endpoints only)
The dotCMS Integrity Checker is designed to compare the sending and receiving servers for duplicate objects with the same name, but different identifiers. The integrity checker examines inode conflicts for Content Types, Folders, and Workflow Schemes, and provides some options for how to correct the conflict, allowing you to choose which version of the conflicting objects to keep (on either server).
To use the Integrity Checker:
- Open the admin console for the sending server.
- Select System → Configuration.
- Select the Publishing Environments tab.
- Press the Check Integrity button next to the Send To server you wish to check.
The system will display a “Loading” message while the content on your servers is compared. If the integrity check completes with no conflicts, the system will briefly display a No conflicts found message. If conflicts are found, the Check Integrity button will change to a View Conflicts button.
What is Checked by the Integrity Checker
The following types of objects are checked by the integrity checker to see if duplicate objects have been incorrectly authored/created by users independently on both the sending and the receiving servers.
- Content Types
- Folders
- Workflows
- HTML Pages
- File Assets
- Roles/User Roles
View and Resolve Conflicts
Click on the View Conflicts button to view the Integrity Checker report popup. Tabs in the popup allow you to view conflicts for Content Types, Folders, Workflow Schemes, HTML Pages, File Assets, and Roles/User Roles. Items with conflicts are displayed using their Velocity Variable name and the Local server inode and Remote server inode that are in conflict.
Note: Although the integrity checker does check for duplicate Roles and/or User Roles, roles and permissions DO NOT push publish. When a new user is created, a “User Role” is automatically created to handle individual user permissions. The integrity checker can be used to resolve differing user Role ID's if the same user was improperly created twice, on both the sending and the receiving server.
Conflicts in all types of content are resolved by replacing one of the inodes (local or remote) with the other to re-synchronize the object inodes between the servers.
Fix at Local Node
Choose Fix at Local Node to remove the local inode and replace it with the remote inode.
Fix at Remote Node
Choose Fix at Remote Node to remove the remote inode and replace it with the local inode.
Re-Check Integrity
After you have resolved all conflicts, you should re-run the Integrity Check.
- Press the Discard Conflicts button to clear the conflict report.
- Close the Integrity Checker popup.
- Press the Check Integrity button again to re-check the system.
For more information on Push Publishing, please see the Push Publishing documentation.
Multilingual Sites
When performing an Integrity Check on multilingual sites, there are certain conflicts which the Integrity Checker can not detect for you. In these cases, you must resolve the conflicts manually.
For example, if you create a version of content on the receiving server which has the same identifier as content on the sending server, but a different language than the content on the sending server, the Integrity Checker can not detect and resolve this conflict for you automatically. This happens because the Integrity Checker is designed to detect a page conflict when pages with different Identifiers, but the same URL and language ID, exist on both servers. When the pages have different language IDs on each server, the conflict is not detected because they are not considered to be the same page. Pages with different language IDs must be treated as different pages to avoid detection of false conflicts.
Manual Conflict Resolution
When you discover a conflict between a page on the sending server and a page on the receiving server where both pages are in different languages, use the following steps to resolve the conflict manually:
- On the receiver, check the language of the page.
- On the sender, create a version of the page in the language found from step 1 (e.g. Spanish) and run the Integrity Checker.
- Note: You don't need to add any content to the new page; you only need to create it.
- After dotCMS detects the conflict, select Fix on remote
- This will keep the Identifier of the original content (setting the Identifier of the new page on the sender to the original Identifier of the page on the receiver).
- Push the default language version of the page to the receiver.
- This time the push will succeed because the Identifiers are the same.
- You now have the correct page with the same data on both the sender and receiver.
- If the alternate language version of the page (e.g. Spanish) is no longer necessary, Push Delete that version of the page.
- This ensures that you now only have the default language version.
