The Disaster Waiting to Happen

As Owen Wattley noted in his post, implementing the ApplyInboundIndexVersionFilter to ensure only the latest version goes into the index can cause problems that aren't apparent at first glance.

"...The problem my team found is as follows:

Create an item, version 1 goes into the index because it's the latest version

Add a new version. Version 2 goes into the index because it's now the latest version.

Version 1 gets blocked by the inbound filter, meaning the index entry for version 1 DOESN'T GET UPDATED OR REMOVED. In the index it is still marked as the latest version. So is version 2. This means you have 2 versions in your index, both marked as the latest version.

You have to be very careful with inbound filters because they don't do as you might expect. I expected that if you set "args.IsExcluded" to true then it would REMOVE that entry from the index, but it doesn't - it ONLY ensures that nothing gets ADDED. That's a subtle but very crucial difference. Once we found this problem we quickly removed the inbound latest version filter. "

The Solution

Luckily, Sitecore star Pavel Veller recommended a solution that would help alleviate these issues. I just took his idea and implemented the solution.

As this keeps popping up time and time again in the Sitecore 8.x projects that I have been working on, I wanted to share this implementation with the community.

Setting Up Connections

Our client purchased a copy of the software, and loaded it on their Staging server. We then had a developer set up the connections to each Sitecore instance in the various environments.

Within a few minutes, he could connect and sync content between 3 different environments with a few button clicks.

The Shared Connection Problem

The problem we were faced with was that non of the other developers could see the connections that the first developer had set up under his profile. Would we have to get each developer to set up the connections individually?

The Shared Connection Solution

If you navigate to C:\Users\{username}\AppData\Local\Hedgehog_Development\Razl.exe_Url_????, you will see a user.config file that contains all the connection information.

So, to get the connections to show up for a new developer's profile, this is what you need to do:

Each user needs to run Razl once. This will create the "Hedgehog_Development\Razl.exe_Url_????" folder structure and user.config file in the location mentioned above.

Get a copy of the user.config of the developer that initially set up the connections and replace the file in each user's C:\Users\{username}\AppData\Local\Hedgehog_Development\Razl.exe_Url_???? location.