My current project has me working on a custom search solution for a SharePoint public facing site. The site has a good number of sites, each with a good number of pages, as well as many lists, libraries, etc... One of the requirements the client had was to only display Documents and Pages in the search results. This didn't seem like an unreasonable request at the time, so I agreed. Well, as it turns out, it was not so simple after all.
I started looking at Search Scopes, thinking to myself that I could create a Scope with a set of rules to give the "slice" of data I wanted. This is what I wanted. Keep in mind that this is a publishing site.
- Pages.
- Documents from specific libraries.
Sounds pretty simple on the surface. So, I started creating property rules. I only wanted results from certain libraries. That was fine, I created a rule to pull from certain folders (as they are described on the Scope rule screen). I very quickly realized that scopes are pretty limiting. I cannot group rules. I cannot have for example, color is red OR color is yellow, only AND's. There is very limited logic available with Scope rules. This pretty much forced me to switch my approach from a simple Scope based solution to a SQL Syntax Query solution that would allow me to pretty much return whatever I wanted.
Now I needed only documents, regardless of extension. At this point I was a little perplexed. I spent a good deal of time looking thru all of the crawled properties trying to find one that would help me. It was then that I discovered the isDocument property, which, coincidentally, was also a managed property out of the box. I added this to my query and was now only getting documents from the specified libraries back in my search results. Almost there. I still needed to get Pages (from all of the sites in the site collection).
How on earth was I going to do that? Well, in the process of testing and debugging over and over again, I have discovered a little known property that was sitting right under my nose the entire time. If you go to create a property rule within a Scope, you will notice the contentclass property. I wondered what this property did. Well, it was a life saver. Essentially, every piece of content in SharePoint seems to be tagged with this property. I believe it's all set internal as I have yet to see it referenced anywhere (at least in my limited searching).
This entire time I was working on a custom search results page that looked very different then the out of the box version, as it was for a publishing site and as I mentioned, all they wanted searched were Pages and certain Documents. As part of the development process of that search results page, I placed a Review control on the page so that I could see my search results in their raw format as I worked on the custom rendering. The contentclass property was right there, already in the default properties that were searched. I of course, had to add it to my SQL Syntax Query but nonetheless, it was crawled and managed for me already. I found a couple of blog posts that describe the possible values for this property, but they were incomplete, so here is, as far as I can tell, a complete list of possible values, that you can use in your Scopes, SQL Syntax Queries or Keyword queries should you need to.
case "STS_Web": // Site
case "STS_List_850": // Page Library
case "STS_ListItem_850": // Page
case "STS_List_DocumentLibrary": // Document Library
case "STS_ListItem_DocumentLibrary": // Document Library Items
case "STS_List": // Custom List
case "STS_ListItem": // Custom List Item
case "STS_List_Links": // Links List
case "STS_ListItem_Links": // Links List Item
case "STS_List_Tasks": // Tasks List
case "STS_ListItem_Tasks": // Tasks List Item
case "STS_List_Events": // Events List
case "STS_ListItem_Events": // Events List Item
case "STS_List_Announcements": // Announcements List
case "STS_ListItem_Announcements": // Announcements List Item
case "STS_List_Contacts": // Contacts List
case "STS_ListItem_Contacts": // Contacts List Item
case "STS_List_DiscussionBoard": // Discussion List
case "STS_ListItem_DiscussionBoard": // Discussion List Item
case "STS_List_IssueTracking": // Issue Tracking List
case "STS_ListItem_IssueTracking": // Issue Tracking List Item
case "STS_List_GanttTasks": // Project Tasks List
case "STS_ListItem_GanttTasks": // Project Tasks List Item
case "STS_List_Survey": // Survey List
case "STS_ListItem_Survey": // Survey List Item
case "STS_List_PictureLibrary": // Picture Library
case "STS_ListItem_PictureLibrary": // Picture Library Item
case "STS_List_WebPageLibrary": // Web Page Library
case "STS_ListItem_WebPageLibrary": // Web Page Library Item
case "STS_List_XMLForm": // Form Library
case "STS_ListItem_XMLForm": // Form Library Item
case "urn:content-class:SPSSearchQuery": // Search Query
case "urn:content-class:SPSListing:News": // News Listing
case "urn:content-class:SPSPeople": // People
case "urn:content-classes:SPSCategory": // Category
case "urn:content-classes:SPSListing": // Listing
case "urn:content-classes:SPSPersonListing":// Person Listing
case "urn:content-classes:SPSTextListing": // Text Listing
case "urn:content-classes:SPSSiteListing": // Site Listing
case "urn:content-classes:SPSSiteRegistry": // Site Registry Listing
I spent a good deal of time coming up with this list, but if someone finds on that is not mentioned, please let me know though a comment and I will update this list. If you are wondering how I found all of these, it was actually quite easy. I simply started to add the different types of content to the various sites, crawled it, and then looked at the output in my GridView while developing the solution. You can see a pattern, so it did get a little easier after that was discovered. I'm guessing as well that the SPS* ones are left over from SharePoint Portal Server 2003. I didn't actually see those in my research, but pulled them from a post by Jose Barreto where he mentions some of these values.
So, by limiting my SQL Syntax query to only include items that are have a contentclass equal to either STS_ListItem_850 (Pages) or STS_ListItem_Document (Documents) along with making sure that the isDocument property is true (1), I was able to meet the requirement. Well almost.
Of course, SharePoint HAD to throw me a curve ball. As you may or may not know, Publishing sites have the concept of a Welcome Page. This is set via a link that appears on the Site Settings page of a Publishing site.
During my testing of the search results, I noticed that none of the Welcome Pages were being returned in the search results. I knew they were being crawled, because I saw them in the crawl log. It was time for some additional debugging. I enabled my trusted ReviEw and inspected the results with the search filter off, so I was getting results for all types of content, not just Pages and Documents. I noticed that the Welcome Pages were in fact appearing BUT the content class associated with them was STS_Web. I have no idea whatsoever why this is, but that's the way it is. So, I had to modify my WHERE clause in my query to include STS_Web results as well. Once I added that, I started to get all the results I expected, and most importantly the results that the client wanted.
So there you have it. The contentclass in all of its glory. It is super useful, especially if you are writing your own queries. You could use it for all sorts of things. Just be aware of the Welcome Page caveat for Publishing sites.