The great site barrier for content in SharePoint has been the pivot for development projects for long. Ranging from custom event handlers, custom timer jobs, even custom windows services etc. to harvest data from cross sites have been common talk.
And then SharePoint 2013 walks in like a boss and turns off the switch on all of above. The question is how this fits with your needs and where/how can you avoid custom code?
A simple example can be when you want to publish the content secured behind your intranet to extranet or to the internet site. With this feature you can pull news/blog entries from the company’s intranet and publish them on your public website. This will act like a passive hot link to the item on your secured site with the refresh rate dependent on the search crawl.
There are a few logical components to consider
- An authoring site is where content is created and hosted
- A catalog is an attribute that you can add to a list or a library in the authoring site. Marking a list or a library as a catalog makes the content easily accessible to other site collections.
- Search is the engine/glue that connects your catalog to a publishing site.
- The term store holds metadata terms that are used to organize content for publishing on target sites.
- A publishing site is where visitors go to see and read content.
The content which can be indexed is the requirement for cross site publishing. The files (images, documents) still need to be handled traditionally.
Benefits of Using Cross Site Publishing
- Site architectures will have a broader canvas (Do remember to plan the assets).
- Allows content to be shared anonymously from intranets/extranets
- Can be used across site collections and even across farms.
- Separates content authoring from branding and rendering , avoids content duplication.