You say building a Publishing toolset for SharePoint Foundation is a little crazy, maybe you’re right. Regardless, we did it and it’s in and working for many customers globally.
This is the 2nd article of a two part series covering the Qualitem Web Publisher, why and how. Please refer to “Web Publishing For SharePoint Foundation – Why?” – for background information on why we did it.
A quick recap
Our customer needed to create content on the Staging farm and have it migrate to the Production internet farm, whilst retaining the ability to publish content (for example set the welcome page, master pages, custom layouts, access the editing toolbar, and run approval workflows). The alternative was for them to buy SharePoint Server for their 190,000 employees; this was never going to happen and simply cost prohibitive even for this extremely large organisation.
This article will start to address the how, albeit at a fairly high-level to start with, essentially:
- The customer needed to publishing content from SharePoint (Intranet) to Foundation (Extranet).
- The publishing experience needed to be as close as possible to the SharePoint publishing feature.
- Build a publishing feature to be compatible across SharePoint Server and SharePoint Foundation – this would allow pages to flow between the 2 environments.
So we set about writing a SharePoint Publishing feature that worked in SharePoint Foundation; so how did we do it?
The “lowest common denominator” approach
Consider this scenario – 2 farms, the Extranet farm running SharePoint Foundation and the Intranet Farm running SharePoint Server Standard. The destination Extranet server is therefore running a sub-set of SharePoint functionality currently available in the Intranet SharePoint Server Standard environment. It was imperative to reduce/remove the dependencies on SharePoint Server Standard components without losing the SharePoint Publishing functionality.
An example of this is the Content Publishing features of SharePoint Server Standard. These features are key to how content is managed on the Intranet, however, how can we simulate these on the Extranet without imposing a SharePoint Server licensing cost. This was important to the customer as it was cost prohibitive to buy SharePoint Server for their subsidiary business users.
It is also possible to deliver similar Content Publishing components without imposing a licensing overhead (like Content Query web part). We achieve this through development and customisation; specifically replacing Microsoft built-in components with “freeware” components built within the SharePoint community.
Bringing the SharePoint Server Enterprise Intranet back to a “lowest common denominator” (and not using the Publishing feature) facilitates a simpler content migration path. In effect, we simulate and replace as many features as possible without using SharePoint Enterprise features.
In fact, we have a situation now where SharePoint Server would be in question as needed for their Intranet except for the fact that Forms Services and People Search are required.
The following components are required to be replaced or augmented in Intranet for a possible synchronisation of content with the SharePoint Foundation Extranet site.
- Turn off the Content Publishing features in SharePoint Server. The list below represents Publishing features affected:
- Libraries (Site Collection Documents, Site Collection Images, Style Library – these are global libraries that can be re-created.)
- Lists (Content and Structure Reports, Reusable Content, Workflow tasks, – these lists can be re-created.)
- Administrative links (These are links to the Site Settings page, including the ability to manage Master Pages, Navigation, Searchable columns, Content and Structure, Content and Structure Logs, Variations and Translatable columns. These will need to be re-created or replicated.)
- Additional Master Pages and default Page Layouts are stored in the Master Page Gallery (This needs customisation to support the current master page and layouts)
- Content Types and Site Columns (These are global components that are either not used or are easily re-created)
- Web Parts (Content Query Web Part (CQWP), Summary Links, Table of Content. These will be replaced (if needed) by functionally similar Web Parts.)
- SharePoint Groups (The following SharePoint Groups are created and can be re-created if needed: Approvers, Designers, Hierarchy Managers, Quick Deploy Users, Restricted Readers and Style Resource Readers, and although I do not find some of these groups useful in non-publishing site, there are some that will need to be recreated, such as the Approvers SharePoint Group.)
- Personalised Views (The personalise option is installed as part of Publishing feature, only Shared View is supported without the Publishing feature). This will not affect the viewing of Extranet content by anonymous users. For Intranet users, adding personal views and web parts will not be possible as this is a Publishing feature and we have not scoped including this.
- Workflows for content approval; simulate/replace content publishing workflows and port these to Visual Studio workflows.
- Base the custom site templates on a collaboration portal templates rather than publishing templates
- Replace the Breadcrumb navigation with custom control to cater for different location of page content.
- Build our own navigation provider for the top-level navigation.
- Setting of the Master Pages and Welcome pages in SharePoint Foundation.
- Custom layouts and the Pages library (although our solution supports publishing pages to any library, not just the Pages library.
- Editing toolbar – this was a major component in making the editing process seamless.
Compare “features” set – align as much as possible
We needed to align features across the SharePoint Server Intranet and SharePoint Foundation Extranet as much as possible. Most content migration issues relate to there being a mismatch in “features” between the source site template and the destination site template. When the base or underlying site templates are different or have different features installed, it is likely that the migration will fail.
All features installed and activated are to be the same across the SharePoint Server Intranet site and the Extranet site, these include:
- Web parts
- Custom content types
- Custom features
- Custom workflows – like the moderation approval and cross-site content publishing.
Custom layouts and master pages –getting these into SharePoint Foundation
The Content Publishing features of the SharePoint Server Intranet supports the ability for pages to be created and moderated. When pages are created, users have the option of selecting a custom layout (which defines content placeholder areas).
It is imperative to simulate the multiple layout support and custom master page support for the Extranet. This will ensure pages are supported and can load without error.
The synchronisation of the custom layouts and custom master pages is a customisation as SharePoint Foundationv3 doesn’t support Content Publishing out-of-the-box.
Adding Ribbon buttons
Our aim with the Content Publishing feature was to minimise the usability impact of implementing a replacement publishing feature. Our Ribbon buttons resembled the ribbon in SharePoint Server and apart from some styling attributes most seasoned SharePoint Server users would find it difficult to pick the difference.
Don’t under estimate the necessity of the ribbon, given it drives the editing process, it, along with the selection of layouts and master pages, they are the “killer” features of content publishing.
Content Synchronisation Options
So now we had a Publishing feature across two farms, how do we get the content from Staging to Production? The client wanted a solution where they could opt-in particular content and this was managed on a page-by-page basis.
As with most things, there is always more than one way to achieve the same result. SharePoint Server and SharePoint Foundation has a very rich content deployment and migration application programming interface (API). There are many built-in options using this API to make content migration and deployment easy for SharePoint Server administrators.
Content Deployment – not a viable option
SharePoint Server has various content migration features built-in as part of the Content Publishing and Management features. However, when looking to synchronised content with a separate SharePoint Foundation farm, most of the built-in options either do not work or impose a licensing overhead. The built-in content migration services as part of SharePoint Server attracts a license overhead – this is why we couldn’t use it.
The other issue with this is that the destination or Extranet SharePoint Foundation needs to accept the “right to receive” content from a source SharePoint Server and this is not supported in SharePoint Foundation.
Finally, using this method, the entire site collection is replicated – this does not allow for an opt-in, only replicate tagged content model.
Other content synchronisation options
Using standard SharePoint (out-of-the-box) tools, there are three other methods of getting content from one farm to another, these include:
- Export/import of sites, libraries and lists. The STSADM utility is used to complete this task and it can be batched or scheduled to update entire sub-sites; or individual lists. It replaces the entire site/list and there’s no ability to opt content in or out.
- Backup and restore site collection. The STSADM utility is used to complete this task it can be batched or scheduled. It backs up and replaces the entire site collection and therefore, as with import/export option, there’s no way to opt content in or out of the synchronisation process.
- Custom Workflow – this is the preferred option and is discussed in detail below.
Custom workflow – the preferred content synchronisation option
The Custom Approval workflow is the preferred content synchronisation option. These workflows are customisation to SharePoint that action any business rule built into the workflow (via source code). Content can be opted in or out using metadata and migrated optionally on approval or without approval if needed. It leverages the SharePoint Content Deployment and Migration API which is an extremely rich and functional API.
In conclusion, the undertaking of creating a set of publishing tools for the SharePoint platform was huge. Our customer needed to create content on the Staging farm and have it migrate to the Production internet farm, whilst retaining the ability to publish content. It was not an option for them to buy SharePoint Server (it was cost prohibitive for their 190,000 employees), so we set about creating a Publishing and content migration feature for SharePoint Foundation.