Showing Blog Post Comments and Likes Count in SharePoint

In SharePoint 2013 OnPremise, we had one requirement recently to show the comments and likes count with each blog post in the content search web part. We have two different Sharepoint Web Applications (different domains with different AD), and we were required to show this web part on both these applications' front pages.  Also one important thing to note is that we have only one “Mysite” for both the applications.

Based on the customer requirement, first we implemented this only for the first web application.

During this implementation, we found that likes count implementation was pretty straightforward (using “LikesCount” managed property, in display template, mapped to “ows_LikesCount” crawled property). The continuous or incremental crawl updates this property correctly (for continuous crawl it takes around a three minute interval to update).

But we found that this wasn’t the case with the comments crawled property “ows_NumComments.” Though we created a managed property for it, say NumComments, it still wasn’t updating the comments counter after continuous or incremental crawls. It requires a full crawl all the time to update the counter. We also found this issue mentioned here.

Comments counter (# Comments) column is not created as Site Column. It is local in posts library.

To set it in full crawl, we can set “My Site” in new content source and set it to run every three or “x” mins.

But setting a full crawl for updating only one field wasn’t our choice that time (considering performance overhead for whole application) so we decided to fetch the comments count with the help of REST calls from the display template. For this to work with cross site (“My Site” was in a different domain), we had to add few entries in web.config of “My Site” to allow cross domain requests from single calling domain:

<configuration>
    <system.webServer>
        <httpProtocol>
            <customHeaders>

And put following entries inside the “customHeaders” tag:

<add name="Access-Control-Allow-Origin" value="<http://calling-domain>" />
<add name="Access-Control-Request-Method" value="GET,POST,HEAD,OPTIONS" />
<add name="Access-Control-Request-Headers" value="Content-Type,Authorization" />
<add name="Access-Control-Allow-Credentials" value="true" />

This worked great for only a single domain for few months. But then there came the new request from the customer to add the same content search web part on another application front page as well. Now for this cross site REST calls to work with two  domains (or host-headers) we simply replaced  the value for “Access-Control-Allow-Origin” to “*” as mentioned in this MSDN blog.

<add name="Access-Control-Allow-Origin" value="*" />

But after many unsuccessful attempts, It was concluded that “*” doesn’t work with SharePoint environment, it allows only single domain address for allowing cross site access.

So we decided to again give it a thought on our first approach of using Managed Property for Comments count for only this second application. As in this second application, blog posts are only coming from “My Site” so there was no need to do a full crawl for the whole second application and it was needed for only “My Site.” So it was a considerable case for full crawl as we have to do it only for “MySite” and not for those main sites with huge contents and libraries.

We created a new managed property “NumComments” for “ows_NumComments” crawled property and then created a new Content Source which had full crawl scheduled to run for every ‘x’ minutes interval or so. We have assigned only “MySite” reference in new content source and scheduled to run it for every 30 minutes. Earlier we thought it would be a performance overhead, but since we have to do full crawl for only “MySite,” it shouldn’t be a problem.

We kept the approach of using the REST call for the first application, as it is as there were posts from both the first application and “My Site” as well. So it was not convenient to allow a full crawl fo the first application because of the huge contents.

Conclusion

So we had to use this mixed approach for fulfilling our requirement (especially for showing the comments count) for both applications.

For the first application, we used the REST call approach for fetching comments count from the comments list (by adding above Access-Control-Allow-Origin entries in web.config in “MySite,” which works well for a single domain).

For the second application, we used the full crawl technique (for only “MySite” set to full crawl) where 30 mins crawling schedule is set for updating NumComments managed property and then showsthe correct number in webpart.

I hope this will help someone struggling to overcome a similar situation.

Happy Learning!