SharePoint 2013 introduces the new search-based publishing model. One of the challenges when using search-based publishing is publishing RSS feeds from content aggregated using search. Find out what the challenge is exactly and what’s more important how to deal with it.
RSS in SharePoint 2010
Back in SharePoint 2007 and 2010 the most common approach for building content aggregations was to use the Content Query Web Part (CQWP). Using the CQWP you could aggregate the content from the whole Site Collection to be displayed on the site. Additionally, the CQWP made it very easy to have the same aggregation published as an RSS feed: by simply enabling the Enable feed for this web part setting in CQWP’s property you could have an RSS feed made available to the visitors of our website.
Content aggregations in SharePoint 2013
SharePoint 2013 introduces a new model for publishing content which is based on SharePoint Search. Although everything that used to work in SharePoint 2007 and 2010 is still at your disposal in SharePoint 2013, the new search-based publishing model offers many new possibilities that cannot be achieved using Content Query Web Part. Using search-based publishing we can truly embrace content reuse across Site Collections, but also Web Application and even Farms. The only boundary here is the access to the search index where the content is stored. Additionally using search-based publishing we can separate the authoring environment from the publishing site what allows us to optimize both sites for the purpose that they serve: configure the authoring site to support content editors in the authoring process and optimize the publishing site to be accessible and well performing. Because the content aggregated using search comes from the search index, we cannot use the Content Query Web Part anymore. Instead a new Web Part called Content Search Web Part (CSWP) has been introduced in SharePoint 2013. The CSWP is in many ways more powerful than the CQWP as it leverages the search-based publishing model which allows us to build really dynamic experiences. One question seems to be unanswered though: how do you build an RSS feed for content aggregated using the Content Search Web Part?
Content Search Web Part and RSS
If you explore the UI of the Content Search Web Part you won’t see any options that would allow you to create an RSS feed for the content aggregated using CSWP. Additionally, even if you explored the hidden properties of the CSWP, you won’t find there anything related to publishing RSS feeds either. So is it really not possible to create an RSS feed for a Content Search Web Part?
Search-based RSS feeds in SharePoint 2013
It turns out that although it might not be obvious from the UI, it is possible to build search-based RSS feeds in SharePoint 2013 after all. Although you cannot make them reuse the same settings as configured in a Content Search Web Part, you should be able to achieve comparable results.
Search-based RSS feeds 101
SharePoint 2013 contains the srchrss.aspx Application Page that can be used to build an RSS feed based on a search query. If you just call that page without passing in any parameters you will get an exception stating that generating the feed failed. The easiest way of controlling whether the mechanism is working or not is to request all items from the search index. You can do this by appending ?k=size>0 to the URL, eg.
Configuring search-based RSS feeds
Narrowing the results to a single catalog
In Cross-Site Publishing (XSP) scenarios one of the common requirements might be to narrow the search results to show content from a single catalog only. You could do this similarly as a catalog Result Source, by adding the SPSiteUrl and ListID properties to the query, for example:
Narrowing the results to items of particular Content Type
Another common requirement for publishing RSS feeds is to include only items of particular type, such as news or blog posts. You can do this by extending the keyword query query string parameter by adding parameters to filter content by a particular property, for example:
Appending an * (asterisk) to the ContentTypeID property will also include all pages that inherit from that particular content type
Narrowing the results to items tagged with particular term
In Cross-Site Publishing scenarios you might as well get a requirement to publish an RSS feed including items that are tagged with a specific term, for example to get only blog posts on mavention.nl we would use the following query:
If you want to include items tagged with child terms as well you should prepend the term ID with # (pound), which for usage in the URL has to be encoded as %23.
Changing the number of results published in RSS
By default the srchrss.aspx page returns top 10 items. You can change this number using the count query string parameter, eg.
Although using the srchrss.aspx page might be good enough for some scenarios, it probably won’t be sufficient to match all requirements due to its limitations. Following is an overview of some of the most important limitations of using the srcrss.aspx page for publishing RSS feeds.
Using the v query string parameter you can pass the name of the Managed Property that you would like to sort on. Unfortunately sorting is always ascending.
Including custom Managed Properties
The list of columns that are retrieved is fixed and defined in the srchrss.aspx page. With this you cannot include additional columns in the RSS feed.
The RSS feed is rendered using the srchrssgen.xsl file located in the TEMPLATE\LAYOUTS folder. You cannot configure the srchrss.aspx page to use another XSL stylesheet.
SharePoint 2013 introduces the new search-based publishing model. One of the challenges when using search-based publishing is publishing RSS feeds from content aggregated using search. Although SharePoint 2013 offers the srchrss.aspx application page that can be used to build RSS feeds, it has some limitations. You should always verify its capabilities against your requirement to make an educated choice whether using the srchrss.aspx Application Page is a suitable option or not.