Hi everyone,

I’d like to answer a common question about how to modify the behavior the Variations feature in SharePoint 2010 uses when propagating pages. That is, how pages in the source variation site are copied and appear on target variation sites as minor draft versions.

Page propagation is triggered by publishing a page on the source variation site by default. Each time you publish a source page, the Variations Event Receiver adds a work item to the Variations Propagate Pages timer job queue. When the timer job runs, it will begin executing the first 100 page propagation work items. For each work item, Variations will copy the source page to all target sites, creating the page if it does not yet exist, or appending a draft minor version if the target page does already exist.

In some cases, users might not want changes to a page on the source to necessarily propagate to all targets. That is, users might want to make source-local changes and have the option to make changes globally applicable when they want. This often takes the form of a question like “How can I stop variations from overwriting my target pages every time I publish a source page?” Variations in SharePoint 2010 helps you do this.

In SharePoint 2010, we’ve worked to improve the Variations feature’s server citizenship by moving all Variations operations to the timer service. This way, server administrators can control the frequency with which operations run and better manage server load. The “Update Variations” button now adds a work item to the same Variations Propagate Page timer job queue as does publishing a page when “Automatic Creation” is enabled. What differentiates “Update Variations” is that you can also use this button to propagate source draft versions without publishing them on the source variation site.

When you run this PowerShell script to enable “On-Demand Page Propagation,” all Variations Propagate Pages timer job work items are filtered and discarded except those added to the queue by the Update Variations button:

Enable On-Demand Page Propagation:

[System.Reflection.Assembly]::LoadWithPartialName(“Microsoft.SharePoint”)
$site = new-object Microsoft.SharePoint.SPSite(“http://yourserver/sites/abc”)
$folder = $site.RootWeb.Lists["Relationships List"].RootFolder
$folder.Properties.Add(“DisableAutomaticPropagation”, “True”)
$folder.Update();

Disable On-Demand Page Propagation:

[System.Reflection.Assembly]::LoadWithPartialName(“Microsoft.SharePoint”)
$site = new-object Microsoft.SharePoint.SPSite(“http://yourserver/sites/abc”)
$folder = $site.RootWeb.Lists["Relationships List"].RootFolder
$folder.Properties.Remove(“DisableAutomaticPropagation”)
$folder.Update();

“Update Variations” in SharePoint 2010 can be used to propagate the current version of a page on-demand provided that the Variations Propagate Page Timer Job is enabled

In MOSS 2007, some users disabled the “Variations Propagate Pages” timer job in Central Admin as a workaround. With the timer job disabled, publishing a source page would not cause SharePoint to copy the source page to any target page. Authors on the source variation site could then use the “Update Variations” button to propagate the current version of the source page on-demand.

Clicking “Update Variations” in MOSS 2007 immediately propagated the current version of the source page to all target pages, “skipping the line” and bypassing the Variations Propagate Pages timer job. So when the timer job was disabled, “Update Variations” could still be used to propagate pages.

However, when the timer job is disabled, publishing pages on the source continues to add work items to the timer job queue if the “Automatic Creation” option is enabled, as it is by default. Over time, the queue can grow and contain hundreds or thousands of work items, all of which would begin to execute if the Variations timer job were re-enabled in the future. If you upgrade to SharePoint 2010 with a backlog of work items, SharePoint will discard these.

With the new “On-Demand Page Propagation” functionality, you can achieve this content distribution model out of the box.

“Update Variations” in MOSS 2007 works differently under the hood from its counterpart in SharePoint 2010

Things to keep in mind:

• “On-Demand Page Propagation” affects the entire site collection; that is, if you enable this setting, no source page will be copied to any target page when the source page is published. Only the “Update Variations” button will cause pages to propagate when the timer job is enabled.
• Source pages will be copied as draft minor versions to all target variation sites when you use the “Update Variations” button.

Thanks for reading. Happy propagating!

Josh Stickler
Program Manager

View Changes is a new SharePoint 2010 Variations feature that compares two versions of a source page relevant to the corresponding target page. View Changes provides a report highlighting the differences between the source version that has most recently propagated to the target and the prior source version that propagated to the target and was published on the target. By highlighting differences, the View Changes button simplifies in-browser content editing using the Variations feature.

I’m Josh Stickler, the Program Manager responsible for Variations. In this post, I will explain:

• Where to find the View Changes button
• When the View Changes button is available
• Our envisioned content editing process using View Changes

The most common application of the Variations feature is in multi-language sites.  Let’s look at View Changes from the perspective of Anders, an English-to-Danish translator working with the Danish subsidiary of AdventureWorks, an international camping goods retailer.

AdventureWorks is set up with an English (EN-US) site as its source label and target labels for international markets, each corresponding to a different language.  Pages from the source label automatically propagate to the target labels when they are published so AdventureWorks’ global web presence is in sync.  Translators at each of the targets then process the English-language content for localized consumption. AdventureWorks’ Variations hierarchy looks like this:

Initial Localization

Automatic Creation

Let’s imagine that content authors at AdventureWorks in the United States have just published a new page with a sneak peek of this winter’s new product lineup. Since “Automatic Creation” is enabled (this is the case by default), the page is picked up by the Variations Propagate Pages timer job and copied to all target labels, including Danish (DA-DK).

E-mail Notification

As the designated owner of the new page, Anders gets an e-mail informing him that this page has been copied to the target label by the Variations feature and is ready for processing. 

Target Translation and Publication

Anders navigates to the page on the Danish (DA-DK) variation of the AdventureWorks website and sees the English language content.  Since it’s all new, he translates all of this content into Danish and submits the page for approval.  The page is approved and published and now appears on the Danish variation of the website.

Since Anders received an entirely new page to translate, there were no changes to view; hence, the View Changes button is not available.

Subsequent Modification

Source Modification and Publication

Back in the United States, AdventureWorks decides to announce a new product in its sneak peek lineup.  English language content authors add a paragraph describing this new product, an ultra light sleeping bag, and publish the page. The page now propagates to the Danish variation.

E-mail Notification

Anders receives an e-mail notification that new content is ready for processing.  He visits the appropriate page on the Danish variation site and the English content appears and is waiting for translation.

But wait, there is a lot of English content here, and Anders has already translated most of it.  Only one paragraph has been added.  How will Anders know that he doesn’t need to re-translate the whole page?

It’s at this point that the View Changes button comes to the rescue and is available. 

Please note that View Changes requires the Variations Propagate Pages timer job to be enabled. View Changes only compares changes between a source version of a page and a target version that has been copied using the Variations Propagate Pages operation.

Version Comparison

Anders clicks the button and a version differential window pops up, highlighting the new paragraph that has been added.  Now, Anders knows that only this paragraph has been added and doesn’t have to scan through the new and old versions of the English content to determine what he has to translate. 

Restore Previous Version

Anders decides he prefers to revert back to the translated Danish version of the page as a basis for adding the new paragraph.  With the View Changes window open, Anders knows exactly which paragraph to translate and where it goes.  He adds the new content in Danish, submits for approval, and it’s published live on AdventureWorks’ Danish variation site.  Fantastisk.

In addition to providing target variation site translators with insight into what content has changed when pages are copied from the source, SharePoint 2010 also enables authors on the source to decide when to propagate content to targets. By default in MOSS 2007, when content authors published pages in the source variation site, that page would automatically propagate to all target variation sites, even for small changes that are relevant only to the source variation site.

SharePoint 2010 provides the ability to disable automatic page propagation; source variation site content authors can then use the Update Variations button to propagate content on demand. See my previous post, “Site and Page Propagation” for more information on how to enable this setting.

Thanks for reading! Keep checking back for new blog posts.

Regards
Josh Stickler
Program Manager

When you provision a new SharePoint publishing site, one of the first options you’ll see on the default welcome page is to use the Variations feature to manage multi-lingual sites and pages. My name is Josh Stickler and I’m the Program Manager responsible for Variations. In this post, I’ll provide a brief overview of the Variations feature and highlight main improvements in SharePoint 2010.

If there are additional areas that are of particular interest to you, please post in the comments section and I will try to address as many as I can. I’d really appreciate getting any and all feedback. Thanks!

What is the Variations feature?

Variations is a SharePoint feature that facilitates the management and maintenance of content that can be served to multiple audiences. These audiences can vary in terms of different languages, countries, or regions, but they can also represent different brands or devices.

How does Variations work?

For each channel you wish to serve content, you can specify a Variations label. Labels are instantiated as SharePoint publishing sites and the full set of labels in a site collection is referred to as the Variations Hierarchy. I refer to SharePoint publishing sites created and managed by the Variations feature as “variation sites.”

Using variations, target variation sites reflect one source variation site in terms of pages and site structure. When setting up variations, specify one variation site as the source; all other variation sites are targets. By default, pages published on the source variation site are copied to all target variation sites as draft versions and sites created on the source are created (not copied – this is an important distinction) on all target variation sites. You can only have one source variation site per Variation Hierarchy and you can only have one Variation Hierarchy per site collection.

What’s new in SharePoint 2010?

The concept and core architecture of Variations, in which pages and site structure are replicated across multiple variation sites in a site collection remains the same as in Microsoft Office SharePoint Server 2007; however, we have made significant improvements to better meet the needs of enterprise customers serving content across multiple channels.

These improvements can be divided into four categories:

• Server Citizenship
• Content Distribution
• Editing Experience
• Reliability

Server Citizenship

Variations operations now execute in the background via timer jobs. For the end user, this means that you no longer have to wait at a progress screen for operations to complete.  For the system administrator, this means that the cost of resource-intensive operations like Create Hierarchies can be better managed.

You can adjust the frequency with which Variations operations run in Central Administration. Next, I’ll explain the difference between the “Create” and “Propagate” timer jobs in the context of improvements we’ve made to the Variations content distribution models.

Site and Page Propagation

MOSS 2007 featured two models for distributing pages across your Variations Hierarchy:

1. Automatic Creation: If “Automatic Creation” is enabled on the Variation settings page (it is enabled by default), then publishing a page on the source variation site will cause that page to be copied to all target variation sites.

2. Manual Creation: If “Automatic Creation” is disabled, then the “Create Variations” Ribbon button is the only way to copy a new page to a specific, individual target variation site.

We’ve received feedback that there are often cases in which changes need to be published locally to the source variation site without being propagated to all targets. For instance, if the source variation site has a typo in English, the correction may not be relevant to a target site in German, so if the correction is published in the source page, it can be unnecessarily confusing to copy this changed English version to all target sites.

In SharePoint 2010, we introduce a third, “hybrid” content distribution model:

3. On-Demand Page Propagation

A setting has been added (configurable through the Object Model) to disable Automatic Page Propagation. When the setting is enabled, publishing or approving a page on the source variation site will not cause that page to be copied to any target variation sites. The "Automatic Creation" setting will be ignored for pages. "Update Variation" and "Create Variation” are the means by which a user can distribute content across the Variation hierarchy on-demand.

I’ll go into more detail on content distribution models in a future post. But so as not to keep you in suspense on how to configure on-demand page propagation, here are the PowerShell commands:

Enable On-Demand Page Propagation:

[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")
$site = new-object Microsoft.SharePoint.SPSite("http://yourserver/sites/abc")
$folder = $site.RootWeb.Lists["Relationships List"].RootFolder
$folder.Properties.Add("DisableAutomaticPropagation", "True")
$folder.Update();

Disable On-Demand Page Propagation:

[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")
$site = new-object Microsoft.SharePoint.SPSite("http://yourserver/sites/abc")
$folder = $site.RootWeb.Lists["Relationships List"].RootFolder
$folder.Properties.Remove("DisableAutomaticPropagation")
$folder.Update();

We’ve also made improvements for target variation site content owners to better understand what has changed on the source variation site when new draft versions appear on a target variation site.

Editing Experience

To make efficient use of their time and effort, target variation content editors need an easy and informative way to determine what content is new when pages are propagated from the source variation.

A new “View Changes” button compares the most recent source version propagated to the target with the most recent source version published on the target.  Changes are highlighted in a pop-up report to enable content processing directly in the rich-text editor.

Highlighted report

Corresponding location in the Rich Text Editor

This button is available on a target variation page after it has been published once and a new draft version has been copied from the source variation site via one of the Variations timer jobs. I will go into more detail on this new feature in an upcoming blog post dedicated to explaining View Changes with screenshots, a sample workflow, and an example scenario.

Reliability

One of our main goals for Variations in SharePoint 2010 is to make the feature more reliable so enterprise customers can entrust management and distribution of content across multiple channels to Variations.

Now that Create Hierarchies runs in the timer service, we support pausing and resuming this operation during timer service recycles to support long-running operations in large deployments. This also means that the process is not affected by Application Pool recycles. We’ve also made the relationships list, which tracks all target pages linked to a source page, more robust. We now track variations pages using GUIDs for better performance and scale.

Thanks for reading. Check back soon for upcoming blog posts on what’s new in Variations and other exciting developments in Enterprise Content Management.

Regards,

Josh Stickler

Program Manager

There isn’t a week that goes by where I don’t get an email asking me this very question.  More often than not, its because someone has been using the Content Editor Web Part (CEWP) when they should have been using the Publishing HTML field type.  This mistake typically goes unnoticed until a customer needs to roll back to a previous version of a page or when they run a content deployment job.  So what goes wrong?  Well, the CEWP doesn’t store version history, it doesn’t participate in any publishing approval workflow and it does store absolute URLs rather than relative URLs.  The first problem means you’ll have to go to site backups to get access to previous versions of content, the second problem means that users will see updates to the content in the CEWP even if an editor hasn’t approved the page for publishing and the third problem means that all your hyperlinks will resolve to the wrong address (e.g. http://staging.adventure-works.com/ vs http://www.adventure-works.com/).

Thankfully, all of these problems can be avoided by using the Publishing HTML field type.  I’ve talked at length with Andrew Connell (MVP) about this and I know it’s something he is passionate about so I asked him to write up a guest post to explore the topic.

Ryan Duguid
Technical Product Manager
Microsoft Corp

Andrew Connell on Field Controls and Web Parts

One of the most common problems I see with people developing Publishing sites stems from the lack of understanding in the core differences between Web Parts & Field Controls and when to use them. Many a consultant have dug a deep hole in this area. My goal in this post is to make you aware of the differences to make educated decisions when selecting one over the other.

What follows is a discussion with respect to MOSS 2007 Publishing sites (aka: WCM sites), but all the concepts apply to any Windows SharePoint Services 3.0 based site.

When creating editable content regions on a page layout, enabling content owners to add and manage their own content, developers/designers are presented with two options: field controls or Web Parts. These two options are very different and Publishing site developers should be aware of the differences. The fundamental difference comes down to where the data is stored.

Web Parts
Web Parts come straight from ASP.NET and their data is stored in a personalization store. Microsoft was nice and baked the personalization store into the site collection’s content database. Data in a Web Part is stored within the context of the PAGE (i.e.: URL) & the user (which could be the shared user or a specific person). This does allow the content in Web Parts to be uniquely personalized by authenticated users.

In addition, developers and designers can only create Web Part Zones on the page layout. Content owners can then put any Web Part in the zones and any content within them.

Field Controls
Field Controls are much different from Web Parts. They are more like windows into list items. A field control pulls data (in display mode) from a particular column in a list item and writes back to that column in edit mode. Pages in a Publishing site are stored as items in a list; the Pages list. Because they are in a list, they can leverage all the benefits a list has to provide, but visioning & history is the most important here. Just keep one thing in mind: field controls are simply gateways, or windows, to the data.

When a developer places a field control on a page layout, they have the ultimate control of where it is placed on the page and any rules such as if the content owners can insert tables or images into the content. The content owners can only work within the rules defined by the developers.

What is the significance?
Great question! From my experience, MOST customers (90%+) who are rolling out a Publishing site, or Web-based content management systems such as MOSS 2007 WCM, are doing so because the following aspects are important to the project:

• Consistent lookand feel (aka: a corporate brand)


• Empower content owners & subject matter experts (SME) to maintain the content


• Free up IT staff from updating content submitted by SMEs


• Structured organization of contentand a versioned and/or historical record of the content

The challenge here is that Web Parts pose a problem with this approach. Because their data is stored in the ASP.NET personalization store in the context of the page (it’s URL mind you) & the user. However with field controls, the data is saved with the page’s list item. This means that when the page is updated, a new version is created and the old data is retained with the page.

Another challenge is with URLs in the content… especially relative URLs. Take the Publishing HTML field type & the Content Editor Web Part (CEWP). The CEWP does not store relative URLs… it stores only absolute URLs. Even if you enter a relative URL into the editor, it will be converted to an absolute URL. The rich text editor that the Publishing HTML field type is tied to does not convert relative URLs to absolute URLs.

If structure and history is important on your site, you should ONLY consider field controls for your content. If you want to have a more relaxed authoring environment where structure & history isn’t important, Web Parts are better. What if structure & history is important… does it ever make sense to use Web Parts? Sure! Use them for providing functionality like stock quotes, consuming news feeds, or rolling up content (as in the Content Query Web Part). In this scenario, the only data that’s stored is configuration data… not true content.

To summarize: the content in Web Parts is not versioned and there is no history, but the content in field controls is versioned & a history is retained (provided the Pages library has versioning enabled, which it does by default).

-AC

Andrew Connell
MVP Office SharePoint Server
www.andrewconnell.com/blog
Sr. SharePoint Instructor – Ted Pattison Group
http://www.tedpattison.net/