April 10, 2015 // By Magenic
Note that this blog post assumes you know what site columns, content types, lists and content-type association to a list are and how to work with them. If these are unfamiliar, take a look at the links starting with lists, then site columns, then content types and finally content-type association. It also assumes knowledge of web parts and adding them to a web part page.
Microsoft introduced a new feature in SharePoint 2013 called Cross-Site Publishing. This new functionality allows content in one site collection to be more easily shown in another site collection. In previous versions of SharePoint, you could do this through the use of search, but the process was cumbersome and required a more sophisticated knowledge of search and its configuration. With 2013, Microsoft has introduced the ability to designate a list or library as a “catalog.” Marking a list or library as a catalog doesn’t change the fact that it is still a list or library. It’s just a way for the list or library to say “Hey! I’m available for connection if you want to show my contents somewhere else!” Once marked, the content of the catalog (which is just a list) can then be shown in search results within a content search web part in the target site collection.
What’s neat is that although the main use-case for catalogs is for cross-site publishing, it can also be used for intra-site publishing. That is, one can mark a list or library as a catalog and connect to that catalog from within the same site that hosts the list or library.
Why would you want to do that, you ask?
There are many reasons, some of which will need to be discovered. That’s what makes frameworks and foundational technologies so interesting. There’s no way of knowing how they will be interpreted in the wild.
In my case, I needed a way to show list items to anonymous users on an Internet-facing publishing site. More to the point, I needed to create a news feed that could be easily maintained.
The following image shows the end product of what I was attempting to accomplish.
This is just one news feed item, but shows what each item in the listing would look like.
It has become very clear to me over the past year that search-driven applications are the future. I’ve wrestled with FAST technology through SharePoint 2010 and have seen the enormous power it gives to tame the ever-growing data beast we create in our SharePoint environments. It turns out that this world-class search engine is also an excellent content aggregator; I now have the full capabilities of a powerful search tool available to query for content and render it in complex web applications both within and outside of SharePoint. As I was thinking of ways to implement this news feed, it struck me that I could use the new content search capabilities of SharePoint 2013 to create a simple listing using the content search web part.
To do this, I created a list and associated it with a content type. I did this because I wanted to be sure that site columns were used, as they automatically become managed properties in SharePoint 2013 after items have been created using the site column. I created the following content type:
I needed these site columns for their search-related managed properties for later consumption, which I’ll get to in a bit.
Making the List a Catalog
Next, I marked the list as a catalog. This is done by going into the list’s settings and clicking on “Catalog Settings.” The catalog link in the list settings will not appear until you activate the Cross-Site Collection Publishing site collection Feature. Check to make sure this Feature is activated in the site settings if you do not see the link. The Feature is automatically activated if you choose “Product Catalog” at the time of site collection creation under the “Publishing” tab of the Create Site Collection application page in Central Administration.
In the catalog settings, make sure “Enable this library as a catalog” is checked and that an identifier is chosen. The identifier is the key used to uniquely identify an item in the catalog.
Connecting to the Catalog
Keep in mind that we are not going to connect in a true cross-site publishing fashion and do it from another site collection. We are going to connect to a catalog from within the same site collection.
First, however, the crawler needs to run and recognize that a list has been deemed a catalog. Once it recognizes this, it makes the catalog “connectable.”
When the next scheduled crawl is complete, navigate to site settings. Under “Site Administration,” click on “Manage Catalog Connections.”
We have now connected to the Newsfeed catalog and made it available as a result source (i.e. scope) within the same site collection.
Adding a Content Search Web Part (CSWP)
To take advantage of this new result source, I added a content search web part to a page. Earlier I said that I’d need site columns (so that managed properties were created automatically), and I’d be revisiting them later. Let’s revisit!
The search engine creates managed properties for each and every newly created site column (those for out-of-the-box site columns already exist), but only after the first item is created using that new site column. This means that to get the search engine to wake up and smell the coffee, I had to create a newsfeed item and wait for the next scheduled crawl to pick it up.
Once the managed properties existed, I used them within a content search web part (CSWP) as seen here (while editing the page and exposing the web part properties):
One of the new features associated with CSWPs is the ability to template the result set both as a whole (control template) and for the individual results (item template). Officially, this artifact is called a “Display Template.”
Comparing two out-of-the-box display template files makes this clearer:
Your edits in Items_TwoLines.html:
Automatically created Items_TwoLines.js:
In my case, I needed a template that displayed three lines and a picture. I copied the out-of-the-box Item_Picture3Lines.html file and renamed it to something more descriptive:
At that point, I used Dreamweaver to open the News_Feed_Item_3Lines.html file for customization.
This section in the red box provides the mapping between the web part property fields and the managed properties that they represent.
You do not have to limit yourself to just these fields. In fact, you can add more managed properties right into the HTML file.
In my case, I was fine with the managed properties already provided. But I could have added another line like this:
<imgsrc="/media/1479/sp17.png" alt="$getitemvalue" />
Finally, the values are used in the markup. You must use the _#= <variable> =#_
syntax to refer to the variable within the code.
Once the new template is created, it can be selected in the drop-down box within the Content Search Web Part properties:
Because the CSWP actually performs a query against the search index, it’s necessary to configure a query for it to use. This is done in the CSWP web part properties:
Because I connected to the catalog, SharePoint automatically created a new result source. This result source limits search results to those only found within the catalog.
As you can see in the dialog box, I’ve selected the “News Feed” result source. Because I want all list items to display, the Query text is pre-filled with the keyword query. While it’s possible to modify this to restrict the results further, keyword syntax and queries is beyond the scope of this blog post.
At this point I had enough configured that I could try out the CSWP. Recall that the site is Internet-facing and requires anonymous access. To enable anonymous access, you must (in this order):
- Enable anonymous access on the web application in central administration
- Ensure that there is not an anonymous policy that restricts anonymous user’s ability to navigate the site
- Since I need anonymous users to be able to write data back to a list (for other reasons unrelated to the newsfeed), I need to ensure that permissions are enabled to do that at the web application level:
<imgsrc="/media/1490/sp29.png" alt="Require Use Remote Interface Unchecked" />
- Grant anonymous access in the site’s permission settings
Testing the CSWP Web Part
With all the pieces in place, I finally tested the CSWP web part. And here is the result:
Even after ensuring that all configuration with respect to anonymous access, no results displayed even though several results exist in the catalog.
After some research, I realized there is one crucial step and one that really speaks to the idea of catalogs within SharePoint.
When I created the catalog based on the News Feed list, I failed to enable anonymous access to the catalog. So while I had anonymous access to the list, I could not view the catalog based on this same list because anonymous access was not active!
I went back to the list settings and within the “catalog settings,” I clicked “Enable Anonymous Access”:
After letting the search engine update the index with the correct security descriptors, I went back to test the CSWP and voila, the results displayed:
Getting anonymous results using cross-site publishing in the same SharePoint 2013 site collection requires a good deal of (correct!) configuration. Because of this, your first attempt at getting it working will take some time. (Though hopefully this blog post will save you that time!)
Yet for most cases in which anonymous access to customized list items is necessary, the cross-site publishing framework’s allowance for maximum customization and design freedom addresses the struggles many SharePoint-based organizations have endured in previous versions. The ability to work with standard HTML and CSS instead of complex XSLT brings traditional web development techniques back to the table. For these reasons, it deserves at least a review prior to any new SharePoint 2013 development project.
If you’re a developer, this approach takes some getting used to; it can be trying at times to gingerly step around commented-out markup. For me, I felt like the additional step of copying snippets from the design manager added more complexity to the process (just give me the master page please!). For designers, however, this new model is a welcome change. It’s easier for a designer to find relevant HTML within the mess of SharePoint and other ASP.NET markup.
In either case, once you understand the model and necessary implementation steps, subsequent attempts to build out functionality become easier (and the development cycle therefore shortens). Overall, I have to say that cross-site publishing (particularly in anonymous access scenarios) is a welcome addition to SharePoint 2013. The possibilities are really limited only by the imagination!