This is a blog post in the series “How to set up a product-centric website in SharePoint Server 2013.” In this series, I'll use data from a fictitious company called "Contoso" to show you how to use search features to set up a website based on product catalog data. Note: Most of the features described in this series are not available in SharePoint 2013 Online.
For an overview of the blog posts in this series, go to How to set up a product-centric website in SharePoint Server 2013.
In previous blog posts, I showed you how to create a category page and a catalog item page. I also showed you how to assign these two pages to terms within the Site Navigation term set. When we browsed to the "Audio" category, we couldn't see any content. This was because when we created the category page, we didn't add any Web Parts.
In this stage we will start to merge different pieces of what we have done in previous steps. In this blog post we'll learn:
Start stage 9
To display content on our Contoso website, we'll use the Content Search Web Part.
About the Content Search Web Part
The Content Search Web Part (CSWP) uses, as its name implies, search technology.
Most of us use search technology on a daily basis. Think about how many times a day you enter query terms in a search box, for example on bing.com; how after pressing Enter, you scan search results that are almost immediately displayed on a search results page (by the way, how did you find this blog post?).
When visitors browse to a page that contains a CSWP, they're probably not aware of this, but they're actually issuing a query. However, the thing that differs with CSWPs is that instead of entering query terms in a search box, the query is contained within the Web Part itself. This means that when a visitor browses to a page that contains a CSWP, this query is automatically issued.
Another thing that is different from the bing.com search scenario is that search results aren't displayed on a separate search results page, but within the CSWP. In most cases, visitors won't even know that search technology is being used to display the content they're viewing. To them, it'll look and feel like any other webpage.
How to add a Content Search Web Part to a page
Browse to the page where you want to add the CSWP. In our scenario, let's browse to "Audio".
In our scenario, we'll add a CSWP to Zone 3.
The CSWP contains a default query, so it already displays some content (Audio, Cameras and Computers) -- but not the content we want to display. To make the Web Part display Contoso catalog content , we'll need to configure the query in the Web Part.
How to configure a query in a Content Search Web Part on a category page
In the dialog box, notice that "Audio" is shown in the top left corner. This is the category which we navigated to and selected to edit the page from. Also notice, that in the RelevantResults section, the top three results, Audio, Cameras and Computers, are listed. These are the same three results that were shown in the Web Part when we added it.
A result source narrows the scope from which search results can be retrieved. When we connected our publishing site to our catalog, SharePoint Server 2013 automatically created a result source for our catalog. In our scenario, this result source is named catalog - Products Results. By selecting this result source, only search results from our catalog are retrieved.
For more information about result sources, see Plan result source and query rules.
When we selected this result source, the number of RelevantResults changed from 864 to 775. 775 happens to be the number of items we have in our catalog. Therefore, selecting this result source confirms that we're on the right path to configuring the query.
A key phrase in this selection is navigation terms. This refers to the category in the site navigation the visitor is browsing. In this particular case, the visitor is browsing the "Audio" category.
Remember, one of the first things we did in this series was to import catalog content into a list. We also imported terms into the term set Product Hierarchy, and associated each item in the list with a term from that term set. When we connected our publishing site to our catalog, we specified that the full site navigation should contain terms from the Product Hierarchy term set. Because we have used the same term set to tag the items in our catalog and to build our site navigation, we can use a term from our site navigation to search for catalog items that have been tagged with that same term.
So, our query in the CSWP will therefore display search results for items that are in the catalog - Products Results result source, and that have been tagged with either "Audio", or any of the children of "Audio", for example "MP3 players" or "Speakers".
This selection reduced the relevant search results to 114, which happens to be the number of items in our catalog that belong to the "Audio" group.
Another key phrase from the selection Restrict by current and child navigation terms is "current." I'll talk more about the importance of this phrase in the next section.
On the "Audio" category, the search results have changed to show different results.
If you browse to the "Cameras" category, you'll see three other search results displayed.
If you browse to the "MP3" category, you'll see three other different search results are displayed.
If you are now thinking "OK, I understand how we got the correct search results for the "Audio" category, because that is the category we clicked, and where we changed the query in the Web Part. But why do we see different search results when we browse the catalog? And shouldn’t we change the query for all the other categories as well?"
Well, let's take a closer look at what's going on.
About the query configuration
We only had to configure one query because the same page is used for all categories. Remember how in stage 8 we assigned the page ContosoCategoryPage.aspx to all terms within the Site Navigation term set? We assigned this page to all terms, so even though we edited this page in the "Audio" category, we could have edited it in any other category, and achieved the same result.
We only had to configure the query once, because the query issued from the Web Part differs depending on which category we browse to. Remember that the CSWP contains a query that is automatically issued whenever someone browses to a page that contains a CSWP, and that search results are displayed in the Web Part. Also, remember that we selected Restrict by current and child navigation terms when we configured the query in the Web part. The word "current" is very important, because it means that the query issued by the CSWP will change depending on the category the visitor is currently browsing. If you edit the Web Part from another category, you can see that the Web Part has changed.
For example, if I browse to the "Cameras" category and take a closer look at the CSWP, I can see that:
So, when I browse to the "Audio" category, the CSWP issues a query for catalog items that have been tagged with "Audio" or any children of "Audio", and displays search results. When I browse to the "Cameras" category, the same CSWP (remember, we only used one page for all categories) issues a different query, this time for catalog items that have been tagged with "Cameras" or any children of "Cameras", hence different results are displayed.
How to view details of the query configuration
To view details of the query configuration, click on the TEST tab. The actual query issued by the CSWP, is shown in the Query text field.
In our example, the query that is issued by the CSWP from the "Audio" category looks like this:
(contentclass:sts_listitem OR IsDocument:True) SPSiteUrl:http://contoso/sites/catalog ListId:3a3f66cd-9741-4f15-b53a-b4b23c3187ea owstaxidProductCatalogItemCategory:#c771504f-6a2f-423f-98de-0e12fcfa08c9
If this doesn't make any sense to you, don't worry! There is a logic to it, and I'll break it down to make it clearer.
In our Product catalog site collection, in the Product Hierarchy term set, you can see that the GUID represents the term Audio.
So now we have configured the query for the CSWP on our category page. We still have to do some configuration to make it display more than three search results, and also give it a "Contoso look." I will show you how to do this in a later post. The next step is to add a CSWP to our catalog item page, and configure the query to show individual catalog items.
Next blog post in this seriesStage 10: Configure the query in a Content Search Web Part on a catalog item page
Additional resourcesConfigure Search Web Parts in SharePoint Server 2013Scenario: Create SharePoint sites by using cross-site publishing in SharePoint Server 2013