If you’ve read my recent post, Fun with Variations, then you know that I’ve been doing a lot of work with variations lately. One of the things that I had to figure out a solution to was how to prevent the hidden Relationships List from getting out of sync with the pages in our publishing site when we migrated content from our authoring farm to our publishing farm. For specifics on what the Relationships List is see the aforementioned post which also touches upon some issues with it.
Breaking this list is extremely easy – let’s say that you have an authoring farm where your content authors create your initial pages and then you would like to migrate those pages to your public publishing farm using the content deployment API (so you could use my gl-exportlistitem and gl-importlistitem commands which use the API or write your own or use Central Admin’s content deployment jobs). In most cases the page will appear to have migrated just fine but you may notice a couple things that aren’t quite right – first, the Variation Label Menu is no longer working – you think to yourself, "well that’s just a navigation thing – maybe if I use the editing page toolbar to update the variations then the navigation will ‘fix itself’?". So you go into the toolbar and click "Tools -> Update Variation…". And suddenly you are presented with this very unhelpful error stating that a page already exists at the target location:
So what do you do now? Well, you could delete the page in the other variations but then you’ll lose all history and any translations that you want to keep so that’s not a practical solution. The other option is to try and understand what the failure really is and then fix that. In this case it’s the linking between the Relationships List, the imported page, and the matching pages throughout all the variations. Thus comes the creation of my new command called gl-fixvariationrelationships.
What this command does is for each page in the source variations Pages library it loops through all variations and makes sure that the GroupID field matches and then it looks for an entry in the Relationships List matching the URL of the page and if it doesn’t find an entry then it creates one and if it does find one then it makes sure that the values are correct. It’s important to note that if your setup has page variations that are named differently from one variation to another then you’ll have to fix the issues manually as there’s no way for me to handle this scenario (I’d recommend keeping page names consistent regardless of this issue though – it’s just easier to follow what page goes with what).
I probably should have done a better job abstracting this code into separate method calls to make it easier to read but time has been kind of constrained lately and I just needed to get it done. Anyway, here’s the code:
Using the command is very simple – you just pass in the URL of your site collection and then an optional page name if you only wish to fix a specific page. You can also pass in an optional verbose parameter so that you can see exactly what the command is doing:
C:\>stsadm -help gl-fixvariationrelationships stsadm -o gl-fixvariationrelationships Links publishing pages using information in the hidden Relationship List list. Parameters: -url <url> [-pagename <name of page to fix (example: "default.aspx")>] [-verbose]
Here’s a simple example of running this command against a variation site collection:
stsadm -o gl-fixvariationrelationships -url http://portal -verbose
If you only want to affect one page you could use the following:
stsadm -o gl-fixvariationrelationships -url http://portal -verbose -pagename "default.aspx"
Update 9/2/2008: Tim Dobrinski has a great tool that he’s put together for fixing many issues with the relationships list (including addressing sub-sites which I’m not currently dealing with). You can find details about the tool here: http://www.thesug.org/blogs/lsuslinky/Lists/Posts/Post.aspx?List=ee6ea231%2D5770%2D4c2d%2Da99c%2Dc7c6e5fec1a7&ID=21