The question of which SharePoint site template to use is one I get asked all the time. Some of the templates like blog, my site host, and others have obvious reasons to choose them. However, some are not so clear, and the most common question concerns team sites versus publishing sites.
First a little history is in order. Publishing sites were included first in the WCM additions to SharePoint 2007. Before this there was no such thing as a publishing option, but with the advent of ASP.NET 2.0 and technologies such as master pages the opportunity was ripe. Not to mention the ever increasing need to use SharePoint beyond list and libraries.
SharePoint 2010 greatly expanded publishing with numerous improvements. The most notable was moving publishing into both a site template and feature. This meant that you could use publishing on any site template with minimal impact. Now we have SharePoint 2013 with some of the most important WCM improvements since the 2007 version including image renditions, device channels, and more. However, despite the inclusion of site pages in SharePoint 2010, the team site template has itself remained largely unchanged. Site pages were really provided only as a solution for the lack of WCM in the Foundation version.
Publishing Is the Way to Go
Now, it’s easier to make absolute statements instead of carefully thought out recommendations, but I’m going to make one anyway: Stop using team sites and use publishing exclusively if using the server version.
Here are my reasons for this. You’ll notice most of these are features available only in a publishing context.
- Using the publishing model provides almost infinite flexibility from a presentation perspective. Page layouts provide you options only limited by your imagination. Site pages however are fixed, you cannot extend/add to them, and you lose a lot of functionality from web part zones such as easily reordering content.
- In publishing sites you get the Manage Content and Structure tool. Now I have criticized MSFT for essentially neglecting this tool since MOSS. However, it provides an OTB way to manage, move, and edit content on a mass level. Plus you get great reporting functionality on pages such as all the pages you have checked out in a site collection.
- Many of the coolest features in SharePoint 2013 including image renditions and device channels are only available in a publishing context. Image renditions specifically are a huge loss whether in an public or intranet scenario.
- Team sites do not allow you to specify a different site and system master page. In fact, it only recognizes the system master page setting no matter what you specify for the site master page. If you need an example of how painful this is just try the blog template. Plus, it greatly inhibits your UI flexibility because both site and system have different UI concerns. To make this all the more interesting, if you even want to change the master page in the SharePoint UI you have to enable publishing!
- Content approval works great with little configuring in publishing sites with workflow or turning it on existing team sites. You can theoretically add it to site pages but why?
- The only thing the team site gives you is some standard lists and libraries in SharePoint 2010. Considering the fact they’re so generic they’re often not useful, you can easily create them manually in a publishing site or just create a publishing site definition. MSFT even removed these default lists in 2013 because they were useless additions.
- Want to cross-site publishing in SharePoint 2013? As the name implies, you need publishing sites.
- The Design Manager looks pretty neat right? Try using that in a team site.
- Want to do variations on your site pages in your team site? No bueno. Again, you need to use publishing pages.
- Why also would you want to expose and train your users on two complete different ways to handle “pages” in SharePoint (“Site Pages” vs. publishing pages)? Stay with just one publishing model.
The One Remaining Team Site Feature
There is one feature not present in publishing sites, and that is the “save site as a template” feature. It’s a tempting feature, but not enough to lose all we have seen. If this is critical then invest in a proper site definition with remote provisioning, which publishing supports. Another consideration is that the Minimal Download Strategy feature doesn’t work in 2013 publishing sites, but its benefit doesn’t outweigh the cost, and I’ve reported that it breaks other core functionality.
It’s also worth nothing that if you’re using SharePoint Foundation you obviously don’t have the choice to use publishing sites. So in that scenario go hog wild with team sites.
I think it’s time for MSFT to deprecate team sites, but I don’t think that will happen due to how prominent they have figured into previous versions. Many people also assume you use team sites for collaboration exclusively, but a publishing site is still better in that scenario also. I would also like MSFT to redo the horrific blog site template using the publishing model.
If you have the ability to make a choice go publishing sites all the way.