As stated earlier in this chapter, a publishing site in SharePoint is simply a site that has the SharePoint Publishing Server feature active. This feature introduces a Pages library that can be viewed as a special document library that stores publishing pages within it. You can use these pages to embed text, images, and other content and then make them accessible to end users. The Pages library is similar to the Wiki Pages library, but with a lot more functionality. Publishing pages use page layouts to present their content in a rich and consistent manner. Other added features include additional Web Parts, found within the Web Part Gallery, that can be used to perform activities such as content rollups.

Additional changes beyond those that the SharePoint Publishing Server feature implements when it is active can be automatically configured. When you use a publishing site template, the template implements additional features and configuration. For example, if you choose the Publishing Site With Workflow site template, approval workflows are configured on libraries within the site during the site provisioning process. This template also restricts all subsites to using the same site template.

The publishing site templates available within the web user interface of SharePoint 2013 on an existing site are:

You can view this list when you go to Site Content and then choose to create a new subsite. Figure 15-1 shows the Publishing tab displaying the two publishing sites, in addition to the enterprise wiki.

Figure 15-1. The Publishing tab of the New SharePoint Site page shows the publishing sites and the enterprise wiki.

If you wanted to view these same templates by using Windows PowerShell, one way you could do so is to filter the results returned by the Get-SPWebTemplate cmdlet to only return those templates with the word “Publishing” within their titles. This could be accomplished by executing the following code:

Get-SPWebTemplate | Where-Object {$_.Title -like "*Publishing*"} '
| select Name, Title, Description, CompatibilityLevel | Format-List

This code actually returns more than the two publishing sites shown in Figure 15-1; in fact, eight templates are returned. The complete list is shown Table 15-1.

The first thing you should notice about the site templates is that they can be grouped into two sets of four templates based on Compatibility Level. If you are not already familiar with levels 14 and 15, they equate to the 2010 and 2013 versions of SharePoint, respectively. The description of each site template can give you a good idea of the degree of extra functionality introduced by selecting one template over another. One additional note about Compatibility Level, as it pertains to sites, is that when you choose to create a new site through the web UI or by using New-SPSite, the default Compatibility Level is 15, which is the 2013 version. By default, you only have the option to create 2010 versions of a site if you elect to use the New-SPSite cmdlet and specify 14 for the Compatibility Level parameter.

The method you use to map the Master Page Gallery as a network drive on your local machine depends on whether your machine has Windows XP, Windows 8, another Windows-based operating system, or another operating system altogether. If you are using a Windows operating system that is later than Windows XP and up to Windows 8.1, as of this writing, you can use the article at the following URL to learn how you map the Master Page Gallery as a network drive: http://msdn.microsoft.com/en-us/library/jj733519.aspx. If you are on another operating system or are comfortable with how you map paths, then the only important thing to remember is the URL structure to follow. The URL structure is http://<siteURL>/_catalogs/masterpage/. There is really just one prerequisite to being able to successfully create the mapping, and it is security based. You must have at least Designer permission, which is the same permission you need to be able to access the Master Page Gallery through the web UI.

To really grasp the role that master pages, page layouts, and pages play within a publishing site, as well as how they interact with each other, you need to understand what the page model is.

At its lowest level, the page model starts with a master page. A master page contains the common elements that should be displayed on every page for a site. Some of the typical common elements are:

The next level up is the page layout, which we have already discussed in some detail; however, more detail is needed to help clarify its role in the page model. Page layouts are able to identify what to correctly render where, along with how to render it, through the use of page field controls and their mapping to site columns. A sample code extraction of a page field control found in a page layout is shown in Example 15-1. The mapping is accomplished by using the FieldName parameter of the field control, which needs to have its value set to the internal name of the site column whose content the page field control should display.

<PublishingWebControls:RichHtmlField FieldName="PublishingPageContent"
HasInitialFocus="True" MinimumEditHeight="400px" runat="server"/>

The field control shown in the listing is of type RichHtmlField, which is available under the namespace Microsoft.SharePoint.Publishing.WebControls. There are many other control types found within this namespace, in addition to other control types found in other namespaces. For example, the TaxonomyFieldControl, which is used to expose the value of a managed metadata field or site column, is found in the Microsoft.SharePoint.Taxonomy namespace.

The final layer is the page, which is the content. As mentioned earlier, page field controls on a page layout map to site columns. These site columns are grouped into a content type and made available in a Pages library that it is associated with the page. It is important to note that not all site columns for a page need to be mapped to field controls within a page layout. Because of this, it is best to categorize the site columns for a particular page into one of two groups: those that are used for presentation and metadata and those that are used strictly for metadata. An example of one that is used for presentation would be a site column that is used for storing a news article image or the body for a news article. An example of one that is used strictly for metadata could be one that is used for metadata keywords or audience targeting.

When you add the layers together you get the final rendered page that a user would get. Figure 15-2 shows a rendered SharePoint publishing page broken down by using the page model.

Figure 15-2. This SharePoint publishing page is broken down by page model.

To learn more about SharePoint master pages, pages, and the deployment of each of these, see the section Using pages in SharePoint in Chapter 7.

We have already discussed why a page layout is important for publishing in SharePoint and how it is involved in the page model. This section discusses the options for creating a page layout and then goes into detail on how to control the presentation and editing of a page by using a page layout.

There are more ways to create page layouts in SharePoint 2013 than there were in SharePoint 2010, thanks to the new Design Manager. When you choose to use the Design Manager approach, you will interact with an HTML page when you want to make changes to a page layout, and that HTML page in turn is associated with an .aspx file that SharePoint uses in the page model. When you make a change to the HTML page, this change is then propagated to the associated .aspx file. It is important to remember that this propagation is in one direction only, going from the HTML page to the .aspx file. Because of this, any changes made to the .aspx file that did not first occur in the HTML page will get overwritten when the next change to the HTML page occurs. To learn more about how to create a page layout, see the article “How to: Create a page layout in SharePoint 2013” at http://msdn.microsoft.com/en-us/library/jj822368.aspx.

The approach taken in previous versions of SharePoint, in which only an .aspx file is created and then deployed to a SharePoint site, is still supported. Some developers might be more familiar with this and might prefer it in place of using the Design Manager.

Page fields, as described in the Understanding the page model section earlier in this chapter, are visible through a page layout when you are creating a new publishing page. These fields are associated with a content type, and each page field on a page layout should reference a field within the associated content type. Page fields are able to read and write to a content type field because they too have an assortment of available types. For example, if you needed to expose the Title field for a content type that had a column type of Single Line of Text, you would use a page field with a field type of TextField to support read and write operations on the Title field, as shown in the following code:

<SharePointWebControls:TextField ID="tfTitle" runat="server" FieldName="Title"/>

The TextField uses a SharePointWebControls prefix, which requires a reference as shown in the following code:

<%@ Register Tagprefix="SharePointWebControls" Namespace="Microsoft.SharePoint.WebControls"
Assembly="Microsoft.SharePoint, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e94
29c" %>

A TextField field type is considered a simple field type and can be styled by simply wrapping the page field with a div that has an ID that you can reference by using cascading style sheets (CSS). This allows developers and designers to control the presentation of the content rendered through the controls.

Most field types are considered simple; however, the RichHtmlField is an exception. As its name implies, this field type allows the author to have an experience similar to using a word processor when authoring content within it. A ribbon with a multitude of options is available for managing fonts, paragraphs, and other text-centric functions, as shown in Figure 15-3.

Figure 15-3. The SharePoint ribbon is used for editing a RichHtmlField.

Because of the many options available to the author during the editing experience, the brand or presentation consistency of the content might be at risk if too many liberties are taken with the available options. Because of this, the RichHtmlField field type has properties that can be used to control which of the editing or formatting options should be available to the author. Table 15-2 shows a breakdown of the primary Allow properties that can be used to control the editing and formatting experience.

There are many more properties than those listed in this table, but these are the most common properties needed for content authoring and the editing experience. To view the complete set of properties, see http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.publishing.webcontrols.richhtmlfield_properties.aspx. The following code snippet shows an example of some of these properties being configured for use within a page layout:

<PublishingWebControls:RichHtmlField ID="rhfPageContent" FieldName="PageContent"
HasInitialFocus="True" AllowFonts="True" AllowTextMarkup="False" runat="server"/>

If you compare this code snippet to the previous example for a TextField, you will notice that both controls come from the same namespace. The two Allow properties in this example affect the way the ribbon renders for an author, as shown in Figure 15-4.

Figure 15-4. This Format Text ribbon tab has some of the Font group options unavailable.

In Figure 15-4 you can tell that the ability to choose fonts and pretty much everything else is still there, but the ability to use bold or other text styles is not available.

An edit mode panel primarily allows a designer or a developer to wrap fields and content within it to control what is visible while an author is editing a page, hence the naming of the control. There are in fact two different modes that a page can be in: display mode and edit mode. Display mode is the only mode that visitors to a site will ever experience, whereas an author will also view the edit mode when creating or modifying a page. The interesting thing about an edit mode panel is that it can be used to control the visibility of content and controls in either display mode or edit mode, even though its name would suggest that its scope is limited to the edit mode. To help explain this, the following code snippet is used to render the text Contoso on the page, but only while the page is in display mode:

<PublishingWebControls:EditModePanel ID="MyEditModePanel" runat="server" PageDisplayMode="Displa
y">Contoso</PublishingWebControls:EditModePanel>

Notice that this is controlled by means of the PageDisplayMode property of the EditModelPanel control. Furthermore, the two available choices are in fact Display and Edit.

Page fields, as this chapter has just covered, are crucial to authoring content-driven pages. There are, however, many times that the content being authored directly on the page is not the only content that the author would like to use. You might discover a list or a library of documents that you would like to reuse or surface as links on a page. The obvious solution is to use a Web Part to surface the content; other than the RichHtmlField that was discussed earlier, there are no other page fields that support embedding a Web Part. And even then, the author is burdened with how to use HTML markup within a RichHtmlField to control the presentation of multiple Web Parts. Because of this need, requirements should be gathered and Web Parts zones should be identified as part of the solution.

Simply put, a Web Part zone is an area on a page that is dedicated to Web Parts and the ability to add, modify, or remove them. Further, Web Parts have the ability to control such things as the default chrome setting for added Web Parts and also the orientation of added Web Parts, whether they should be stacked vertically or horizontally. The following code snippet shows a simple Web Part zone that sets the orientation of the Web Parts placed inside of it in a horizontal format and sets the default chrome to be BorderOnly:

<WebPartPages:WebPartZone runat="server" Title="First Row"
ID="FirstRow" PartChromeType="BorderOnly" Orientation="Horizontal"><ZoneTemplate></ZoneTemplate></
WebPartPages:WebPartZone>

The namespace used to add a Web Part zone is Microsoft.SharePoint.WebPartPages. The horizontal format is set by using the Orientation property, and the default chrome is set to only show the border for Web Parts that are within the zone by using the PartChromeType property. Figure 15-5 shows how this would look when a page is in edit mode.

Figure 15-5. Web Part zones are visible when the page is in edit mode.

By using device channels, you can redirect users to the correct master page that is targeted for their type of device. This concept alone is powerful, but being able to take it to the next level is where device channel panels come in. A device channel panel is used within a master page or a page layout to wrap content or functionality and target specific device channels. The following code shows a sample device channel panel:

<Publishing:DeviceChannelPanel runat="server" IncludedChannels="Safari">
    <div>Only visible to those devices included in the Safari device channel.</div>
</Publishing:DeviceChannelPanel>

The code is self-explanatory, but it is important to note that the DeviceChannelPanel object is found in the Microsoft.SharePoint.Publishing.WebControls namespace. Also, the IncludedChannels is where you identify which device channels, by their alias, will be able to see what is contained within the DeviceChannelPanel. If you would like to include more than one device channel, the aliases should be comma delimited and passed to the same property.

There are a few different strategies or approaches that you can use device channel panels in. The first is to help lower the number of one-to-one relationships between master pages and device channels. You can use device channel panels to limit the number of master pages by pairing up more device channels to a single master page and then use device channel panels to fine-tune the experience by hiding or showing sections of the master page that each device channel should see. A limitation that needs to be accounted for during the planning phase of device channel panels is that they cannot be used to wrap Web Part zones; however, if a Web Part is embedded within a page layout or master page, it could be wrapped by a device channel panel.

Another strategy is to reduce the size of pages being sent to a mobile device. This is accomplished by directing the server to not render the content found within a device channel panel whose IncludedChannels property does not contain a match to the device channel being used by the current device. This exclusion results in a smaller page than one created by using a CSS approach to hide non-relevant content, which still results in the page being too large and slow for a mobile device.

To begin working with the managed navigation APIs, you first need to choose which API you want to use. There are APIs for the following:

Not only can you take advantage of any of these four APIs, but each has been extended and enhanced from the SharePoint 2010 APIs. Some of the common uses for the APIs are to manage the creation and customizations of terms, term sets, and other properties found in an MMS Application that are related to managed navigation.

Later in this chapter we will work through an example of creating a new term set that can be used as a site’s managed navigation. The example will use CSOM using C#. Before we get started, though, we will identify the reference and namespace that are required. The following are the required reference for using the CSOM approach:

The first two are standard requirements for any CSOM interactions to even occur. The remaining two, however, are needed to create the new term set through a site. The namespaces needed after the references are included are:

To begin creating a navigational term set by using CSOM, you must begin by gaining context of the site collection that you want to create the term set under and instantiating a TaxonomySession object, as shown in the following code:

//Gain context
ClientContext clientContext = new ClientContext("http://portal.contoso.com");
//Instantiate TaxonomySession
TaxonomySession taxonomySession = TaxonomySession.GetTaxonomySession(clientContext);
taxonomySession.UpdateCache();
//Request TaxonomySession TermStores property
clientContext.Load(taxonomySession, ts => ts.TermStores);
clientContext.ExecuteQuery();

After you have gained access to the TermStores property for the TaxonomySession object, you can select the term store that you will create the term set in. The following code simulates this by using the first term store within the TermStores property:

//Throw error if no Term Stores are found
if (taxonomySession.TermStores.Count == 0)
throw new InvalidOperationException("MMS not found");
//Request first Term Store Name and Working Language Properties
TermStore termStore = taxonomySession.TermStores[0];
clientContext.Load(termStore, ts => ts.Name, ts => ts.WorkingLanguage);

After you have access to the term store, you need to create a new term group for the site collection, and then you can create a term set underneath it, as shown here:

// Create a new Term Group for the Site Collection
TermGroup scTermGroup = termStore.GetSiteCollectionGroup(clientContext.Site, createIfMissing: true);
//Create a new Term Set within the Term Group called "Contoso Site Navigation"
TermSet termSet = scTermGroup.CreateTermSet("Contoso Site Navigation", Guid.NewGuid(), termStore.WorkingLanguage);
//Commit all changes
termStore.CommitAll();
clientContext.ExecuteQuery();

At this point, you have a term group that has been created within the scope of the site collection at http://portal.contoso.com. You have populated this term group with a new term set called Contoso Site Navigation. The next step is to identify the newly created term set as a navigational term set and fill it with a few sample terms:

//Access and edit the term set as if it were associated with the web at "http://portal.contoso.
com"
NavigationTermSet navTermSet = NavigationTermSet.GetAsResolvedByWeb(clientContext, termSet,
clientContext.Web, "GlobalNavigationTaxonomyProvider");
//Set the term set as a navigational term set
navTermSet.IsNavigationTermSet = true;

//Commit changes so far
termStore.CommitAll();
clientContext.ExecuteQuery();

//Create a term for the homepage
NavigationTerm term1 = navTermSet.CreateTerm("Home", NavigationLinkType.SimpleLink, Guid.
NewGuid());
term1.SimpleLinkUrl = "http://portal.contoso.com/";

//Create a term for the default page of the news subsite
NavigationTerm term2 = navTermSet.CreateTerm("News", NavigationLinkType.FriendlyUrl, Guid.
NewGuid());
term2.FriendlyUrlSegment.Value = "news";
term2.TargetUrl.Value = "~site/news/pages/default.aspx";

//Commit all changes
termStore.CommitAll();

//Request the term set's ID property
clientContext.Load(navTermSet, nts => nts.Id);
clientContext.ExecuteQuery();

The final step is to configure the web object for http://portal.contoso.com to start using the navigational term set that has just been created. This is done by the use of the WebNavigationSettings object. This object contains the means to specify the navigation model for a web object, including the ability to switch between structured navigation, which uses the PortalSiteMapProvider, and managed navigation, which uses the TaxonomySiteMapProvider. If managed navigation is used, then you also can dictate the term store and term set that should be used to drive the managed navigation. The following code shows how this can be accomplished:

//Reset the web object to the default settings
WebNavigationSettings webNavSettings = new WebNavigationSettings(clientContext, clientContext.
Web);
webNavSettings.ResetToDefaults();
//Configure the web object to use managed navigation
webNavSettings.GlobalNavigation.Source = StandardNavigationSource.TaxonomyProvider;
//Set the term store and term set to use for managed navigation
webNavSettings.GlobalNavigation.TermStoreId = termStore.Id;
webNavSettings.GlobalNavigation.TermSetId = navTermSet.Id;
webNavSettings.Update(taxonomySession);
//flush the cache
TaxonomyNavigation.FlushSiteFromCache(clientContext, clientContext.Site);

clientContext.ExecuteQuery();

After executing all the code blocks shown within the section, you should have a site that has two navigation nodes visible within the global navigation of the site, as shown in Figure 15-9.

Figure 15-9. The site’s global navigation displays the navigational term set’s terms.

The example shown within this section demonstrates just one of the many possibilities available with the managed navigation APIs. Following this approach to code the creation of a site’s navigation settings along with the initial values allows for a consistent and efficient way to provision sites.

Simply because the Content Search Web Part (CSWP) can do more does not always mean that it should be used over the Content Query Web Part (CQWP). Careful consideration should be given to requirements and the available infrastructure that supports the SharePoint implementation before making a solution decision.

When considering the requirements, if content must be available only moments after it is authored or approved, the site would not lend itself to the CSWP. In this situation, the CQWP would be the best fit because it can access the content instantly without needing to be crawled and indexed by the Search service. Another situation that would support the CQWP over the CSWP is when the SharePoint implementation is on a small two-server farm topology that needs to support several user requests and other services. This type of topology would not be able to support the constant demand of a search application’s crawl and index component on a highly demanding schedule. However, a situation in which the CSWP is the prime candidate and best choice is when you need to roll up content across site collection, web application, or farm boundaries, as shown in Figure 15-12.

Figure 15-12. The rollup abilities of the Content Search Web Part are extensive.

More than what this chapter has covered so far should be considered when choosing the correct rollup Web Part. Figure 15-13 shows a rollup comparison of both the Content Query and Content Search Web Parts broken down by key areas.

Figure 15-13. A rollup comparison between the Content Query and Content Search Web Parts highlights their differences.

As the comparisons play out you can tell that both the Content Query and Content Search Web Parts have an important role in SharePoint 2013 and each has a vital role to play in the success of Web Content Management solutions that involve content rollup.

If you have spent time branding the results of a Content Query Web Part or a Core Search Result Web Part in SharePoint 2010, you have had the opportunity to experience the benefits and pains of working with Extensible Stylesheet Language for Transformations (XSLT) within SharePoint. The understanding needed to complete even simple branding techniques by using XSLT with these Web Parts requires more than just typical XSL knowledge. XSL is still used within SharePoint 2013 for the Content Query Web Part, but display templates have become the de facto solution for the all search-driven Web Parts. A display template is one of two types:

Figure 15-14 shows how a control template and item template would be used to present results as a content rotator.

Figure 15-14. This display template is broken down by control and item template.

Display templates have the following primary categories:

Display templates are stored at the site collection level within a root folder aptly named Display Templates, which is inside the Master Page Gallery. Each of the categories just listed is a folder within the Display Templates folder, as shown in Figure 15-15.

Figure 15-15. Display template categories are stored in this folder structure.

Display templates are made up of two associated files, much like the new HTML page layouts are in the Designer Manager. The files are an HTML file with which developers and designers interact, and an associated JavaScript file that SharePoint uses when the display template is being called. It is important to remember that, as with all other associated files in SharePoint 2013, you should modify the HTML file only. This is because SharePoint updates the JavaScript file whenever there is a change that has been made to the HTML file. So if you make a change directly to the JavaScript file it would work as intended, but you run the risk of having that change be overwritten the next time someone decides to update the HTML file instead.

The code markup within a control template and an item template have some similarities, but there are also some key differences. We will start by looking at a simple control template and then will progress to looking at an item template.

A control template named Control_List.html, which is available out of the box, is shown here:

<html xmlns:mso="urn:schemas-microsoft-com:office:office" xmlns:msdt="uuid:C2F41010-65B3-11d1
-A29F-00AA00C14882">
<head>
<title>List</title>
<!--[if gte mso 9]><xml>
<mso:CustomDocumentProperties>
<mso:TemplateHidden msdt:dt="string">0</mso:TemplateHidden>
<mso:MasterPageDescription msdt:dt="string">This is the default Control Display
Template that will list the items. It does not allow the user to page through items.</
mso:MasterPageDescription>
<mso:ContentTypeId msdt:dt="string">0x0101002039C03B61C64EC4A04F5361F385106601</
mso:ContentTypeId>
<mso:TargetControlType msdt:dt="string">;#Content Web Parts;#</mso:TargetControlType>
<mso:HtmlDesignAssociated msdt:dt="string">1</mso:HtmlDesignAssociated>
</mso:CustomDocumentProperties>
</xml><![endif]-->
</head>

<body>

    <!--
            Warning: Do not try to add HTML to this section. Only the contents of the first
            <div> inside the <body> tag will be used while executing Display Template code. Any
            HTML that you add to this section will NOT become part of your Display Template.
    -->
    <script>
        $includeLanguageScript(this.url, "~sitecollection/_catalogs/masterpage/Display
            Templates/Language Files/{Locale}/CustomStrings.js");
    </script>

    <!--
        Use the div below to author your Display Template. Here are some things to keep in mind:
        * Surround any JavaScript logic as shown below using a "pound underscore" (#_ ... _#)
        token inside a comment.

        * Use the values assigned to your variables using an "underscore pound equals"
        (_#= ... =#_) token.
    -->

    <div id="Control_List">

<!--#_
if (!$isNull(ctx.ClientControl) &&
    !$isNull(ctx.ClientControl.shouldRenderControl) &&
    !ctx.ClientControl.shouldRenderControl())
{
    return "";
}
ctx.ListDataJSONGroupsKey = "ResultTables";
var $noResults = Srch.ContentBySearch.getControlTemplateEncodedNoResultsMessage(ctx.ClientControl);

var noResultsClassName = "ms-srch-result-noResults";

var ListRenderRenderWrapper = function(itemRenderResult, inCtx, tpl)
{
    var iStr = [];
    iStr.push('<li>'),
    iStr.push(itemRenderResult);
    iStr.push('</li>'),
    return iStr.join(''),
}
ctx['ItemRenderWrapper'] = ListRenderRenderWrapper;
_#-->
    <ul class="cbs-List">

            _#= ctx.RenderGroups(ctx) =#_
        </ul>
<!--#_
if (ctx.ClientControl.get_shouldShowNoResultMessage())
{
_#-->
        <div class="_#= noResultsClassName =#_">_#= $noResults =#_</div>
<!--#_
}

_#-->

    </div>
</body>
</html>

When you work through this code, you can tell that it follows the typical HTML markup using HTML, HEAD, BODY, and DIV tags. Let’s start with the code found in the HEAD section. The TITLE element value is important because it is the text that shows up in the control template drop-down box when you are using a search-driven Web Part. The next section is the CustomDocumentProperties section. It has five properties that need to be filled out. Table 15-4 lists each of these properties with descriptions.

The BODY is where you place your design markup. The first section you find should be a script element. This is where you can include external JavaScript by using the $includeScript method or external CSS references by using the $includeCSS method.

After the script element you can finally start to use HTML markup to interact with the results being returned. It is important to note that up until this point in the display template, HTML markup is not supported. A client context object is available by using the ctx object inside the display template. If you would like to use JavaScript within the display template, you must wrap these sections with a “pound underscore” token as shown in the following code:

<!--#_
var jsVariable = "Contoso"
_#-->

When you need to reference a variable declared within a “pound underscore” token, you do so by using an “underscore pound equals” token, as shown in the following code:

<div>_#= jsVariable =#_ </div>

By working through this example you can begin to tell that there are some particulars that you must account for when using display templates, but even accounting for these, the ease of use and the learning curve is far shorter than that of the XSL approach in SharePoint 2010.

The primary difference between an item template and a control template is an additional property called ManagedPropertyMapping found in the CustomDocumentProperties element. This property is only relevant inside an item template, because it is the only template that needs to interact with properties being returned. Furthermore, as the name implies, only managed properties can be used in this property and within a display template. The ManagedPropertyMapping property allows a developer or designer to create properties that are exposed through the tool pane for a search-driven Web Part and also to map default managed properties to them. The following code sample is from the SharePoint native item template named Item_TwoLines.html and shows the ManagedPropertyMapping element:

<mso:ManagedPropertyMapping msdt:dt="string">'Link URL'{Link URL}:'Path','Line
1'{Line 1}:'Title','Line 2'{Line 2}:'','FileExtension','SecondaryFileExtension'</
mso:ManagedPropertyMapping>

We will focus on the section that is specific to Line 1. You first will find ‘Line 1’, which is used to set the display name of the field exposed within the Web Part tool pane, as shown in Figure 15-16.

Figure 15-16. The Content Search Web Part tool pane shows the Property Mappings exposed.

The next piece that follows is {Line 1}, which is a way to use a variable within the display template that is constant. This is because of the succeeding section after the variable ’Title’. This sets the default value for the Line 1 property, but as you can see in Figure 15-16, a user can select the box to change the mappings. If this were to happen, you would not be able to support this type of dynamic function unless there was at least one constant, hence the {Line 1}.

You can also map multiple values as the default for a property to help alleviate the need to change the mappings. The following code snippet accounts for three of the managed properties that are image-based and applies them to the mapping:

'Picture URL'{Picture URL}:'PublishingImage;PictureURL;PictureThumbnailURL'

By using the variable Picture URL, you now have a constant reference that you can use for the remainder of the display template.

There is much more that can be discussed about display templates and how to take advantage of them; however, it is beyond the scope of this book to extend this discussion any further. If you would like to continue reading on this topic, you can visit the MSDN and TechNet sites for additional information.

When you click the Catalog Settings link for a library or list from the settings page you are intending to make this list or library available as a catalog. There are a few important properties to configure to ensure that the content is exposed in the correct fashion. Figure 15-19 shows the Catalog Settings page.

Figure 15-19. The catalog settings page for a library allows you to set catalog properties.

The first and most important setting is the Catalog Sharing property, which is used to enable the library as a catalog. The next property determines whether or not you enable anonymous access to the catalog. This setting is enabled more often for Internet sites than intranet sites, because that is typically where anonymous access is enabled for a web application and site. The Catalog Item URL Fields property allows you to choose which properties can be used as tokens within the page URL. This has a visual impact on what the user could view as part of the URL to access the content from a consuming site collection. The last property is the Navigation Hierarchy property, which is used to categorize the content via a term set. The important thing to remember is that this term set is exposed through a site column, which is what you actually pick from for the Navigation Hierarchy property, and it must only support single values.

After a catalog has been enabled, a full crawl must take place to surface the library as an option for consumption in other site collections. After this has taken place, you should be able to navigate to the site collection that you would like to consume your catalog from and select the Manage Catalog Connections link under the Site Administration section on the Site Settings page, as shown in Figure 15-20.

Figure 15-20. This site settings page has the Manage Catalog Connections link under the Site Administration section.

From this page you should be able to click Connect To A Catalog and view a list of catalogs that are available, as shown in Figure 15-21.

Figure 15-21. This Connect To Catalog page for a site shows two available catalogs.

SharePoint 2013 also has cross-site publishing APIs that can be used to automate the manual process of discovering and connecting to catalogs. By using the server-side approach you can expose a list or library or consume one that has already been enabled as a catalog. If you would like to learn more about this ability, you cam read the cross-site publishing APIs section found at http://msdn.microsoft.com/en-us/library/jj163225.aspx.