Sunday, April 5, 2015

Why content types are still awesome and useful–despite what the cool guys says

This post is about explaining why you don’t need to be concerned about custom web template id’s in search and how to maintain metadata for a site (root web or sub web). In this new world of SharePoint Online we’re only using built-in web templates and derivatives of them right?

A lot of search queries use the contentclass:sts_site webtemplate:templatename construct to limit results only to root sites of a special site type (or sts_web for sub-sites). Living in SharePoint Online most sites will build of a blank or team site, and using the new provisioning engine from Office PnP, this becomes an issue for many. You can use the engine to save a template definition xml file, and create new ones off it, but how do you distinguish sites from one another?
One thought brought forward in the O365 Yammer network is to stamp each site created with a property in the web property bag, and have it indexed. All good, at least from a versioning and engine point of view for diffs etc., but from finding the sites it’s not really needed.
What I propose is to use a custom content type just for the home page of your site. A trick I learned from my good colleagues Tarjei and Ole Kristian at Puzzlepart, and one we use all the time.
This trick solves two problems:
  1. How to filter search for only sites of one particular type
  2. How to easily add and change metadata for a site
Consider creating a content type named ProjectSite, with the following columns:
  • Title
  • Project Start Date
  • Project End Date
  • Project Leader
  • Topic
image

In the above image I inherit from Basic Page. You might want to inherit from Wiki Page or Web Part Page if that’s what you want to use as your home page.

image

Add the newly created content type to for example the Site Pages library, create a new page based on this content type, and assign it as the home page of your site.

image
image

To set custom meta data for your site, merely edit the properties of the home page.

image

The meta data entered for your home page will now be part of the sts_site/sts_web item which is indexed.

Fully security trimmed, automatically generated managed properties to use in your display templates just like any other list, and it’s super easy to change the metadata if needed. No custom UI, no fiddling with the property bag of the site for meta data or making the values searchable.

Want to search up all project sites? spcontenttype=projectsite will return them all.

And content types and pages are supported artifacts of the new provisioning engine.

5 comments:

  1. So how would you roll up against the metadata, i.e. Project Leader in your example?

    ReplyDelete
    Replies
    1. Project Leader is a people field, and by using a site column I will get an automatic generated managed property named ProjectLeaderOWSUSER which contains both name and claim. You can also map ows_projectleader to a new managed property and you will then get whatever value you have chosen to be displayed for the column.

      Delete
  2. Brilliant and simple approach, Mikael! This is much easier than using property bags to store and retrieve site values, particularly on O365.

    ReplyDelete
    Replies
    1. I think so too, and I see think the upside outvalues the downside, like if someone accidentally create a new start page with a different content type. That can be controlled in other ways.

      Delete