SharePoint Online Search: Add a Refiner for Content Type

2015-12-21_14-00-52This is yet another in the “Things that Make You Go Hmm…” category. If I only had a nickel…

I would think that one of the most common needs on a search results page would be to add a refiner by Content Type. After all, we all have robust, sensical information architectures in place to improve performance in our organizations, right?

When we create a new search results page in a Search Center, we get a few refiners out of the box that look oh-so-promising.

First there’s ContentTypeId. We all know that Microsoft uses big, ugly ids and GUIDs under the covers all the time. Sometimes they translate easily into whatever they represent. This isn’t one of those times.


Well, what about contentclass? That looks sort of almost useful. But it isn’t. Values like STS_ListItem_DocumentLibrary won’t really help anyone.


Oh, I know. Let’s add the ContentType Managed Property. That’s what works almost everywhere else. Well, except here, as the values don’t make sense to humans, as they are things like application/pdf Document or application/vnd.openxmlformats-officedocument.presentationml.pres… Yes, the ellipses are appropriate here. Who know what that means?


Finally, I found a blog post from Henri Merkesdal that retrieved my sanity. There’s a property way down the list called SPContentType that does exactly what we want.

Ahhh. That’s much better. Thanks, Henri!


Hidden Content Type Hub on Office365 Tenants

This is a simple thing, but because at the moment it’s sort of invisible, you may need a little help understanding it.

The Content Type Hub is a nice capability that lets you create your Site Columns and Content Types in one centralized Site Collection for syndication across your farm. It’s an excellent idea to use it so that your Content Types have consistent definitions and set up across those Site Collections.

In an on premises farm, you’d create a Site Collection to play this role and activate the Content Type Syndication Hub Site Collection Feature.


However, if you try to do this on Office365 in SharePoint Online, you may get an ugly error. Even if you don’t get an error, you may be creating a redundant Content Type Hub.

This is because there is a Content Type Hub Site Collection already provisioned (in the tenants I can see) at /sites/contentTypeHub. You should probably use this Site Collection for your Content Type Hub if it is there.

Unfortunately, this Site Collection isn’t visible in the admin dashboard listing of Site Collections.


To determine if you have this Site Collection, you can go to the /sites/contentTypeHub URL. However, a more conclusive test is to go into Site Settings on one of your existing Site Collections (probably the root one) and click on Content Type Publishing.


On that page, you’ll see a link to the Site Collection that is acting as the Content Type Hub, if there is one:


Removing the Default Document Content Type from the Allowed Content Types for a Document Set

I’ve been searching on and off for days on this one. When you create a Content Type based on the Document Set Content Type, it’s fairly common to want to restrict the Content Types which are allowed to be added to the Document Set.

Here’s an example. Say you have a Document Set Content Type called “Analyst Report”. You’d like to only allow documents to be added with the Document-based Content Types “Analyst Report Document” and “Analyst Report Critique”.

SharePoint actually gives you a nice dialog for this in the Document Set Settings. To get to it:

  • Go to Site Settings in the site where you created the Document Set Content Type
  • Click on Site content types
  • Choose the Document Set Content Type you want to work with
  • Click on Document Set settings

Allowing other Content Types is easy: you simply highlight them on the left and click the Add > button. Note that the order in which you do this matters, as the Content Types will be listed under the New Document button in the ribbon in the order in which you add them.

The problem is that you can’t remove the Document Content Type after you add the other Content Types you’d like to allow. When you try to do so, you’ll get this pop up alert:

Given that you’ve just created the Document Set Content Type and you haven’t even made it available in a list anywhere, how can this be? I tried everything I could think of – even blowing away a bunch of content I really didn’t want to blow away – to try to get rid of the darn thing.

I finally found the answer embedded deep in the comments on a post called Document Sets – SharePoint 2010 – Part 1 by Slava Gorbunov, who seems to be based on Sydney, Australia. It’s a good post, in that it gives a nice overview of how Document Sets work. The money was in this comment, though:

Good old Anonymous. I tell you, I’ve learned more from that guy…

Right below the Allowed Content Types section, you’ll see a section headed Default Content.

This provides another cool feature of Document Sets, allowing you to pre-populate them with documents. It’s really useful. The problem is that the way it starts out causes the problem. It looks like there is nothing set, but in fact, the Document Content Type is selected, and there is one “item” listed there.

What you need to do is to click on the Delete button to remove the default item which is displayed.

Then you will see no item listed…

…and you will be able to remove the Document Content Type from the Allowed Content Types.

Thanks again, Anonymous!

Using SPServices to Get the Display Names for a SharePoint List’s Content Types

My pal Tasha Scott (@TashasEv) tweeted a question today about how to get at the display name for a Content Type on a NewForm:

Hello Gentlemen,

As requested, I am posting my query from Twitter in regards to trying to pass the Content Type of an item into the PlaceHolderPageTitleinTitleArea, um, area of a New Form. I can do it easily in the Edit and Display forms using the “ContentType” property, but as stipulated i don’t think this property is set for the item until save. However, there is a Content Type ID# in the query string, so the new form knows what fields to pull… how can we convert this info into the Content Type name and display it?

Thanks for any assistance you can render! You guys are always the best.

It just so happens I got an email last week from a Codeplex user called jenglish who wanted to do something very similar, and s/he gave me the code s/he used. (I’ll just go with “he” for simplicity.) The approach is fairly simple.

First, he grabs the Content Type’s GUID from the URL. When you create a new item based on a Content Type (management of Content Types is enabled in the list’s settings), SharePoint passes the GUID for the Content Type on the URL in the Query String. It looks something like this:


Since the ContentTypeId is on the Query String, we can use it to look up the name of the Content Type so that we can display it however we’d like.

I’ve taken jenglish’s code, simplified it a little bit, and added some more comments, but it accomplishes the same thing he intended:

var queryStringVals = $().SPServices.SPGetQueryString(); // The SPGetQueryString function parses the Query String values out into an array
var contentTypeIdValue = queryStringVals["ContentTypeId"]; // This grabs the value of the ContentTypeId Query String parameter
var contentTypeName = ""; // Define a variable to hold the name of the Content Type

// Get the list's Content Types
  operation: "GetListContentTypes", // See the MSDN SDK at for details on this operation
  listName: $().SPServices.SPListNameFromUrl(), // The SPListNameFromUrl function gets the list name for the current context based on the URL
  async: false, // We'll do this asynchronously
  completefunc: function (xData, Status) {
    $(xData.responseXML).find("ContentType").each(function() { // All of the list's Content Types will be returned. We'll loop through to get the one we are interested in
      if($(this).attr("ID") == contentTypeIdValue) { // If the contentTypeId matches...
        contentTypeName = $(this).attr("Name"); // the name in our variable...
        return false; // ...and return false, which breaks us out of the loop. (We've found what we need, so no reason to continue looking.)
//... do something with the Content Type Name ...

SharePoint Content Types Are the Bee’s Knees

A student at USPJ Academy asked this question in a forum thread the other day:

Can someone explain the advantages of using Custom Content Types in a List/Form Library as they pertain to making the rollup of data in a DVWP easier?  I am not sure if this is true, but someone here at  work mentioned this as being a good general approach.

They can help with DVWP filtering, but they are much, much more important than that.

  • Content Types allow you to enforce consistent metadata structures across lists.
  • Lists inherit Content Type metadata structure changes.
  • You can attach workflows to specific Content Types.
  • SharePoint is “Content Type”-aware, and manages the forms for multiple Content Types on a single list automagically for you.
  • Content Types are constructed from Site Columns which are centrally maintained, so all Content Types can be updated with new metadata options (Office, Product Line, etc.) instantly.
  • Content Types inherit either from base content types (like Document, Item, Event, etc.) or you can set them up to inherit from your own custom Content Types.
  • Content Type inheritance is hierarchical.

I’m sure I’m missing some things, but they really are the bee’s knees. Another thing you can quote me on.