5/16/2008 2:03:43 PM

I have a variations-based website and it had lost it's Relationships association when trying to remove a variation label. For some reason, when removing the label (en-gb), it started deleting items from the Relationships List (and did so alphabetically, not in order of their creation). Also, once this happened, I could not recreate the en-gb label. This causes several problems that are beyond the scope of this post. But what has happened since then is that I have re-created the Relationships List entries by hand yet the link between the source and varitions is broken on the sites that were affected. This means that variations will not propagate correctly (though this propagation is usually turned off as it causes more headaches for me and my users). Still, variations is broken (though to what level they ever worked is debatable). Unfortunately still, simply re-creating the Relationship List doesn't fix the variation problem.

Thank you for posting this page. It's nice to know that I am not the only person struggling with variations. Though I hope that Microsoft's "fixes" are worthwhile. In my consulting life, I have done what I could to stear people away from Variations as I believe they are more trouble than benefit. But we'll see what their new fixes will do. Maybe by MOSS 2011 they'll get it right.

Tim Dobrinski

5/19/2008 3:30:23 PM

Tim,
The Relationships list isn't the only place where Variations meta data is stored. There are hidden fields in Variation Pages that also hold part of the mapping. Gary Lapointe describes this here stsadm.blogspot.com/.../fun-with-variations.html. There is also a custom STSADM command he's written to repair relationships, but it needs some extra coding to widen the scope of it's action. (You'll see what I mean when you see the code).

Variations have faced justifiable criticism since they were released. They did have issues, I've faced them, and I'm in contact with several other users who have too. However the recent fixes released and in the pipeline do finally seem to be making Variations robust enough for the enterprise (IMHO).

Jamie

Jamie McAllister

5/19/2008 4:26:00 PM

Yeah, I saw that blog post about hidden fields in the pages that help the Variations link up, but those really don't help much given that you can't really edit those very easily (given that it's a publishing page). And while I respect everyone's opinion and don't really want to get into a discussion on whether or not variations is worth while and what changes are being made, some parts of variations are fundamentally flawed and I will still continue to advise against them. The main points being:

- Lists/Libraries not being moved over when creating variations
- Lists/Libraries do not update their variation-level cousins when changed (bad for list based items) causing a custom event handler to be written to push updates. (I've done this, but it wasn't fun).
- Heavily customized sites not propigating correctly
- Newly published changes to the root push root-language drafts to variations pages (can be turned off, but doing so kinda defeates the purpose, eigh?). This is so wrong for so many reasons. MOSS should Alert me of the changes made and tell me what changed, NOT create a draft that has to be re-translated and published or removed (via Version History). If I correct a misspelled word on the root site, now every other language translator has to get rid of a draft version that doesn't apply to them. Silly.
- Variations are fragile. Period.

And I should apologize. I just went against my idea about arguing for or against variations. But to give you an idea, my site has currently 6 variations (including the root) published and 14 more waiting on translation. And while I have streamlined the process (updating webparts to the SharePoint webpart, moving as many images from PublishingImages to a _layouts folder, removing as many images as possible, etc), creating a new variation (not including translating the content) takes a full day (it used to be a multi-day process - thankfully that's no longer the case). Due to my customizations affecting variations (Microsoft's excuse, not mine), I create a variation, just creating the root. Then, for each subsite, I manually kick off a "create new variation" process. This works for most, but only goes partially for probably 1/3 of the initial subsites. From there, I go subsite by subsite creating the varitations. For those that break, I have to copy the pages manually with SharePoint Designer. This makes them non-variation pages, so those pages are "rogue pages" now. Then I create the lists and libraries (template based, of course) and adjust them for the languages. Then it's a matter of changing the welcome page (because SharePoint wants its default page instead of mine). Then fixing the navigation since Microsoft doesn't believe I know the order things should be in. And after all that is done, then I get to spend two days translating content. If it werent' so much trouble, I'd rip out variations and start over with just a publishing site for each language and manually create the root landing logic.

So while I appreciate Microsoft updating Variations, I just have a hard time thinking they'll fix everything. That and from the experiences I've seen with SP1 and other updates to mature MOSS systems, I can't say that applying a Microsoft update to my production farm is high on my list.

That being said, I still tell people not to use variations. Unfortunately, I'm no longer a contractor, so I don't get to spread my thoughts to it anymore.

Tim Dobrinski