Part 1 - The BasicsPart 2 - User InterfacePart 3 - TriggersPart 4 - Timer JobsPart 5 - Configuration OverviewPart 6 - Configuration InternalsPart 7 - Variation Hierarchy CreationPart 8 - Creating Page VariantsPart 9 - Creating Site VariantsPart 10 - Restructuring the HierarchyPart 11 - Variations Fixup ToolPart 12 - CustomizationPart 13 - LoggingPart 14 - TroubleshootingPart 15 - "View Changes" ButtonPart 16 - Translation SupportPart 17 - MOSS 2007 vs. SP 2010Part 18 - FAQ
Today I will start a new article series, which will discuss all aspects of the SharePoint Variations feature.
The article series will provide insights into the underlying architecture and will also provide details about customization.
But before we can start with the internals we first have to start with the basics.
SharePoint Variations has been implemented to address the following common scenarios:
Many companies operate globally, and even in their home market, companies often must appeal to customers who speak different languages. This diversity often requires that publishing sites be tailored for different cultures, markets, and geographic regions.
In addition, the importance of new internet connected devices like mobile phones, PDAs and internet enabled media players becomes more and more important - so presenting the same information in a different layout on different target devices is mandatory for many customers.
Maintaining a number of different versions, or "variations," of publishing sites or pages is difficult and time consuming because it can be difficult to coordinate the creation and updating of content between the variations.
Another important factor is the accuracy of the content in the different languages, which requires the integration with individual workflows, and an export and import functionality of the content for the purpose of translation through external companies.
[The terms used in this paragraph are explained in the Terminology section below]
SharePoint Variations allows copying sites and content from the source variation label to one or more target variation labels. By default, the variations feature copies only the site structure and publishing pages from the Pages library of the source variation label.
The variations feature does not copy other site content, such as lists or other document libraries, unlike the content deployment feature, which copies all content, including lists and other document libraries, from one site to another.
It is possible to configure the variation feature to copy resources like images and documents bound to publishing pages also to target variation sites - but this will only work for documents and images which reside in libraries and folders which also exist in the target site with the same site relative Url.
Another important difference between the variation feature and content deployment is that the copied content in the target variation labels can be changed, unlike the content deployment feature, for which changing copied content on the target is discouraged.
By default, when users navigate to the Variation Root Site, they are redirected to the appropriate top site of a variation label, based on the language setting of their Web browser. For example, if a user's default browser language is French, SharePoint Server 2010 redirects that user to the top site of the French variation label.
It is possible to customize this behavior by replacing or updating the redirection page responsible for the routing with a different page. This new page can implement custom logic to redirect the user based on other criteria (e.g. information from the User-Agent string).
We will discuss the details about how to achieve this in a later chapter.
The Variation Feature allows tailoring publishing sites for different cultures, markets, languages, devices or any other criteria defined by a customer.
Variation settings enable site owners to create and maintain a number of different "variations," of the same publishing sites or pages.
Exactly one variation hierarchy can be defined per site collection. It consists of a Variation Root - and sub trees for each of the "variations" which we refer to as variation labels.
Each site collection can have a maximum of one hierarchical structure, which supports variations. Each variation label defines the top site of a sub-tree of this hierarchy. The site, which contains the different site structures (e.g. one structure for English and one for German) of the different variation labels, is the variation root site.
As only one hierarchical structure supporting variations can exist in a site collection it also means that there can only be one variation root per site collection.
The variation root site contains the landing page that contains the logic, which redirects users to the correct label (more details in a later chapter).
The variation root site can be a site at any level in a site collection, including the top-level site. It is not possible to change the variation root site after the variation hierarchy has been created.
Variation labels are the names given to each of the variants. For example, variant labels could be language names - such as English, French, or German - or devices - such as PDA, mobile phone, Internet Explorer - or a combination of both like Spanish mobile phone, English Internet Explorer etc.
The flexibility is endless as the Variation system allows customers to define a custom routing logic to decide to which label to redirect a user who browses the site (more details in a later chapter).
Up to 50 variation labels are supported in a site collection.
There are two different types of variation labels:
The Variation Top site is the root or upper most site in a variation label. All Variation Top sites in a hierarchy are direct children of the Variation Root site and define the root of the hierarchy within a variation label.
Variation pages are the publishing pages that are stored in the Pages library of the source variation sites and the target variation sites. These pages and any dependent resources such as images and documents are the only content that is copied from the source label to the target labels.
Important: Storing non-publishing pages inside the Pages library of a site is unsupported! Non-publishing pages inside the Pages library of a site in the source label can cause the Variations Create Hierarchies Job Definition timer job to fail.
These are the peer pages bound together by the variation feature. Each variation label can contain one variant of a page in the source label. If the item in the source label is updated the content of the source page is automatically populated to the page variants in the target labels.
Each source site or page defines a separate variation group. All variants of the site or page in the different labels belong to the same Variation Group.
The variation system needs to keep track about peer sites and pages to ensure that updates performed in the source label are correctly transferred to the target label.
This tracking information is stored in the Relationships List. Each page or site in the variation hierarchy is represented in the relationships list as a separate list item: the Relationships List Entry.
We will discuss the Relationships List in more detail in a later chapter.
Figure 1: Variation Hierarchy