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.

2014-11-25_10-50-00

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.

2014-11-25_10-56-28

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.

2014-11-25_10-58-51

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

2014-11-25_11-01-40

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 form 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:


http://[yourservername]/NewForm.aspx?RootFolder=[rootfolder]&ContentTypeId=0x0100D01A03625CF08449BEFDB6DF55795D14&Source=[sourcepage]

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
$().SPServices({
  operation: "GetListContentTypes", // See the MSDN SDK at http://msdn.microsoft.com/en-us/library/lists.lists.getlistcontenttypes.aspx 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"); // ...store 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.

Hiding the Title Column in a SharePoint List

There are a number of posts about this in blogs out there about this trick and I’m not sure who posted first, so I’ll attribute it to the Ferrara Data Consulting | Company Blog.  It’s certainly a useful trick, and worth repeating.

By default, all SharePoint lists have a column called Title (@Title for you SharePoint Designer junkies out there).  But what if you don’t want to use it?  Well, you can pull a veil over it, though you can’t actually delete it.  You can also rename it and use it differently, but keep in mind that the underlying column will always be called @Title, which can get confusing if you’re doing anything in SharePoint Designer or Visual Studio.

Here’s how you “disappear” it as thoroughly as possible:

  • First, go to the list’s settings page (/[listname]/_layouts/settings.aspx), and under General Settings, click on ‘Advanced settings’.
  • image

  • Turn on ‘Allow management of content types?’ by clicking the Yes radio button.  What this lets you do is allow specific Content Types to be used with this particular list.  (Content Types are one of *the* most important content management capabilities of SharePoint, so if you don’t understand what they are all about, you should learn more! Note the descriptive text in the left panel in the image below.)
  • image

  • You’ll now see the Content Types section on the List Settings page, as below.  Depending on what type of list template you’ve started with, you’ll see whatever base Content Type it uses, e.g., Item, Document, Task, etc. (You may not have realized that each of these Item types were actually Content Types!)
  • image

  • By clicking on the Content Type name, you will see the columns which are a part of the Content Type, with Title being a ‘Single line of text’ and Required, with its source being the Content Type it derives from (Item, Document, Task, etc.).
  • image

  • Click on the Title column, and you will see the Column Settings section, which is where you can indicate whether you want a column to be Required, Optional, or Hidden.  To completely “disappear” the Title column, you’ll want to choose Hidden.
  • image

  • You can now go back into Advanced Settings and turn off the ‘Allow management of content types?’ option should you choose.  There’s certainly no danger leaving it the way it is, and it may be a good idea to leave it on so that you know where you’ve used this trick by noting the presence of the Content Types section.
  • If you’ve turned off the ‘Allow management of content types?’ option, you’ll also need to go back into the settings for the Title column and change the column to not be required.

image

  • Finally, you’ll want to remove the Title column from any existing views, or you will see the (no title) entry, as below.  Keep in mind, though, that the Title column is the column which has the content menu which allows you to take various actions on the item, so you will probably want to keep it visible at least in an administrative view or two so that you can get at the individual items.

image