Web Publishing for SharePoint Foundation

Published: 2017-07-04 by qualitem-com-user-prod.

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.

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.

Conclusion

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.

Web Publishing for SharePoint Foundation – How?