Andrew Connell [MVP MOSS]
1350 Posts |  39 Articles |  3385 Comments
.NET  |  MCMS  |  SharePoint  |  Office System
PDCBling
SharePoint Quick Links
Article Categories
Archives
Post Categories

View Andrew Connell's profile on LinkedIn

Add to Technorati Favorites

Over the last few weeks and a few times at the Office Developer Conference 2008 this past week in San Jose, CA I have been approached with questions about my approach to creating site definitions. The reaction I get is usually mixed so I thought it would be interesting to see how others feel about this approach. Keep in mind that this is by no means a stated recommendation... it is simply my approach.

Thinking back to my days in the WSS v2 / SPS 2003 timeframe, I recall sitting in a class learning about site definitions,picking through all the CAML and also reading a few books. The reaction was always nausea... I hated them as they were just so big, bloated, and frankly, too damn hard to create and perfect. I did everything I could to avoid them like the plague. Unfortunately they are a necessary evil that we can't completely ignore; you must have a site definition to create a site.

What about v3?

First, I still do everything I can to avoid creating site definitions. They are too big and cumbersome making it hard to debug when problems arise. Most importantly, they are very inflexible; once one a site has been created off a site definition, it should never be directly changed. The most you can do to a site definition after a site has been created off it is to use Features to modify the sites or even staple Features to the site definition. But there is no way to remove functionality from a site definition. Consider if a site definition activated a Feature that created a list template. What if you don't want that list template? You can't remove it unless you do it through the API, but the list template will always be created... you are simply doing cleanup work. Sure, site definitions are much easier than they were in v2 with the addition of Features and the global site definition.

But there are times where it is just simply unavoidable to create site definitions. We just need them at times. In those times I go with the minimalist approach... I like to think of it more like the v3 approach. I take a copy of the blank site and strip it way down... no TeamCollab Feature, no WSS branding image... nothing... a truly blank site. I then give it a new name and ID. At this point I'm finished with my site def... but what about adding the required functionality I need for a project? I take all of that and embed it within Features and then create associated stapling Features that are used to attach them to the site def. This approach allows me to create site definitions very quickly and makes them much easier to debug and develop. More importantly it provides me much more flexibility than the v2 approach. I can easily remove functionality by deactivating existing Features or even remove functionality from future sites by deactivating the stapling Feature.

Most of my customers seem to like this approach. I'm curious how many other people are doing this, or prefer this approach...

posted on Friday, February 15, 2008 1:46 PM

Feedback

# re: You don't need to create site definitions 2/15/2008 2:17 PM John Ross
Gravatar Couldn't agree more! It's important to consider that by using a custom site definition you are also introducing additional complexity when you eventually want to upgrade to the next version of SP. I recommend against custom site defs to anyone who will listen unless you've got a special case.

-John

# re: You don't need to create site definitions 2/15/2008 3:26 PM Sherman Woo
Gravatar Would you say this is true of the Publishing Portal as well? What I dislike about that definition is that it
1. Creates a site structure, albeit a basic one. But what if I don't WANT a "Press Releases" child site.
2. Adds a whole whack of files (resources) that I don't need/want.
3. Does not allow me to use my custom page layout/content type for the default page.

Therefore, I saw no alternative but to create a custom Publishing Site definition. Now that the pain of getting that going is gone, it's not too difficult to re-create for new clients. Plus, I have a really good understanding of what's going on with those site definitions, features, and stapling.

As for the other site definitions, I also didn't think it was a big deal to create custom ones. I.e., I don't hesitate to do it. The key reason is I find it allows us to fine-tune the definition easily. (I don't find them that hard to work with.) It *should* result in less coding to undo the Microsoft defaults, and it gives the clients the warm fuzzy feeling of being able to create "MyCompany Team Site" sites.

I *do* agree that the site defs should be kept as minimal as possible, following the OOTB definitions as guidelines, esp. the stapling part.

As for John's comment re: upgrading: while I agree we need to think about sustainability, it's hard enough to think about "what if" scenarios for the current version w/o taking vNext into account. I figure if I follow the tenants:
1. "Don't modify the default (OOTB) files", and
2. "Do as MS does (follow their example)"
as much as possible, I hopefully won't be trapping our clients down the road.

- Sherm.

# re: You don't need to create site definitions 2/15/2008 3:31 PM AC [MVP MOSS]
Gravatar Sherman-
I completely agree with you WRT Publishing sites. I personally don't care for the Publishing Portal site template because of all the extra crap it gives you. Instead I have a minimal Publishing site definition (I call it Minimal Publishing Portal) that does basically the same thing as Publishing Portal except it creates no subsites, content types or other branding content.

# re: You don't need to create site definitions 2/15/2008 3:53 PM mike hodnick
Gravatar Amen. I particularly agree with the "stripped down" approach you take. Start with a completely blank site. This is also a good approach with creating Master and Content pages for Content Management sites. The out-of-the-box site definitions (and master pages/content pages) are just too bloated to even be a good starting point. For some reason there is a tendency by folks to start from OOB templates and tweak them. Why would you want all that junk?

# re: You don't need to create site definitions 2/15/2008 7:23 PM Maxime Bombardier
Gravatar I agree with most of what you say in terms of :
1) There is no reason to use the default Publishing portal since it's almost certain you have to remove items
2) A minimal site definition should be used (I made an hybrid of the Publishing and the Minimal (from CodePlex) site definitions where I re-added workflows)
3) You shouldn't create too many site definitions
4) You should use features (with or without stapling depending if you created your feature prior to the site definition) for modifications done through code.

However, especially if you have variations, you should at least have a site definition "per landing page type". The reason is simply that variations will re-provision according to the site definition. Any customization done to it (such as the welcome page) will not be brought, worst, it can create an error if your custom welcome page is of the same name as the default one.

What I ended up doing is a "master feature" that activates dependencies such as the libraries I always need and the custom features that sets customization I couldn't do in the site definition. That way, the Site Definition configuration is very slim and only contains the features or properties that are single for that configuration.

Last, I ended up creating a Windows application to read configurations and it shows a TreeView of all the configurations, features, properties, manifests, receiver classes, and stapled features of a site definition. You can find it here : http://blogs.msdn.com/maximeb/archive/2008/02/16/site-definition-viewer-a-windows-net-2-0-tool-to-read-site-definition-and-features-configurations-version-0-1.aspx.

Maxime



# re: You don't need to create site definitions 2/16/2008 2:39 AM Muhanad Omar
Gravatar I honestly have nothing against site definitions-- I actually enjoy creating them. I never really understood the big fuss about them.

As far as them adding additional complexity, I totally disagree with you John. I love site definitions. That fact that I can staple on my Features for added functionality is amazing, and like AC said, you can easily deactivate them when you want to. None of my clients have had any complaints so far.

So AC, I definitely prefer this approach.

 re: You don't need to create site definitions 2/16/2008 7:36 AM Keith Patton
Gravatar Hi,
I think that a site definition is something that should be flexible to change, and that means three things:

Adding functionality
Removing functionality
Applying changes to existing instants of that definition.

I personally don't have anything in my definitions and do everything through stapling to make sure the first two changes above can be incorporated. If you don't do this you are assuming that anything you put in your definition will be there forever, without hacky code to remove.

The only way to do the third thing is to have a manager/controller feature receiver that will apply changes across existing sites/webs as required. I guess it's just thought too complicated to apply to existing sites so it's left to us to deal with.

That's fine, at least now there's a way to get at the problem through the feature receivers.

But all this does suggest on thing. Are site definitions better thought of and represented as a series of feature staples alone? I certianly agree and thing so.

# re: You don't need to create site definitions 2/16/2008 9:06 PM AC [MVP MOSS]
Gravatar Maxime-
Oh I couldn't agree more about the whole use of site defs with variations. As I stated in the post, I completely agree that site defs are required. However the crux of my point is that I minimize the complexity of them by refactoring as much as possible to Features which are stapled to the site def, thus giving me the same net effect. For variations, I always create a custom site def but do so as the site def being simply a vehicle for Feature activation.

Thanks for passing along your blog URL... good content!

# re: You don't need to create site definitions 2/17/2008 3:21 AM Sahil Malik
Amen bro!

 re: You don't need to create site definitions 2/17/2008 12:29 PM Marc
I'd be interested in what business requirements you feel dictate that a Site Definition or stapled Feature is needed. I've been able to start with the plain old Blank Site template and build everything that my clients want. In what instances do you immediately say "Ah, I need a new Site Definition for this" or "I need a new stapled Feature for this"? Where does simply saving sites as templates fit into it?

I'm not trying to be glib: I've seen folks who absolutely rocked in 2003 wanting to go into the file system and write code when there's a simple MOSS UI option available to get the same thing done in a few minutes. (Or the nearly magical DVWP.)

# re: You don't need to create site definitions 2/18/2008 9:14 AM Waldek Mastykarz
Gravatar I use Site Definitions as wrappers for the functionality I'm providing, eg. activating Features containing the Chrome and Content Definition (Site Columns, Content Types, List Definitions, etc.) and creating a Welcome Page of a particular Content Type/Page Layout. This provides me a baseline for further configuration and deployment of configuration.

# re: You don't need to create site definitions 2/18/2008 9:50 AM AC [MVP MOSS]
Gravatar Marc-
Good questions... for Publishing sites you need a site def for variations. Consider making a site like MSDN a SharePoint site. The dev centers would make for classic site definitions. Yes, you can start with the Blank Site template and add things accordinly but sometimes a site def is needed.

 re: You don't need to create site definitions 2/18/2008 10:28 AM Matt
Gravatar Do you have a sample project using this approach that I can download?

# re: You don't need to create site definitions 2/18/2008 10:33 AM Maxime Bombardier
Gravatar Andre, one more note regarding Feature Stapling on Site Definitions: you are correct in that it's a great functionnality and it's easier to manage customization through features than site definitions. What I'd like to add is that stapling will staple itself on a site definition; thus all sites using that definition.

Designing your few site definitions become important if you need to staple on only specific sites (and not all your sites).

Marc: There are no set rules as to when you need it beside for variations purpose (thus, at least one per "landing page" type). Otherwise, I would say it goes with the general functionnalities/properties of a site. For example, if you have a FAQ or a glossary section in your site and that the pages are very specific, then Site Definitions would be a good bet there.

# re: You don't need to create site definitions 2/18/2008 10:47 AM AC [MVP MOSS]
Gravatar Matt-
No... sorry... nothing handy, but there are plenty of samples online talking about how to create site def's as well as stapling Features.

 re: You don't need to create site definitions 2/18/2008 11:05 AM Mark
Gravatar Well, our farm has 5000 site collections. We have done this because each site (rootweb/site collection) has to have a quota.
Each site starts off identically with "value-added" extras in such as customised lists, libraries and web parts. We have used feature stapling to customise our site definition and on the whole it has worked well, although I agree that there is a lot of extra complexity.
I have found that most customisation of WSS3/OSS2007 is targetted at single or small numbers of sites, often using SPD. Where large numbers of sites are concerned, automation is important and we are lucky that we have the resources to develop the necessary infrastructure.



# re: You don't need to create site definitions 2/19/2008 10:09 AM shane perran
Gravatar For the most part, I seem to follow a similar trend. That being said I'm not certain it's for the same reasons.

In my experience the "need" for site definitions simply has not presented itself as much as it seems to for others.

Usually I find myself doing the same, stripping down a publishing site and starting there, then using a simple stapling feature to deploy the same master pages, page layouts and style sheets to all new sites.

On the flipside, I did find myself immersed in V3 site definitions recently, and to be honest it was the most I've delved into them since starting with SharePoint development/design.

It was a a fairly large 5000+ site deployment which was scripted and used a 1/2 dozen site definitions. During the creation of the site definitions I was able to get a pretty good grasp on the definitions and what once seemed overwhelming turned out to be pretty useful/logical. I did however (have) to be forced into using them on that particular project so obviously there was some missing link there all along. :)


 re: You don't need to create site definitions 2/25/2008 5:53 PM MK
Gravatar Would you happen to have this "Minimal Publishing Portal" available for download? :)

# re: You don't need to create site definitions 2/26/2008 6:31 AM AC [MVP MOSS]
Gravatar MK-
You'll be able to get it from the source code download associated with my book when that's finished... so a few months from now.

# re: You don't need to create site definitions 2/27/2008 9:29 AM Mark Arend
Gravatar I very much agree with Andrew's approach: strip down the site definition to a bare minimum and put all the features you need in stapled features. Even when you're creating custom site definitions based on defaults! Why?

Microsoft KB article 898631 says "We do not support modifying a custom site definition or a custom area definition after you create a new site... by using that site definition." (http://support.microsoft.com/kb/898631/en-us). This is a monstrous pain, but there it is.

I recently encountered this: what happens when you search for content on Wiki pages? The search results all show "Wiki Pages" as the name of the document. This is pretty easy to fix... just open the DocumentTemplates\wkpstd.aspx file and change the <SharePoint:ListProperty...> in the PlaceHolderPageTitle to <SharePoint:ListItemProperty...> as it appears in the PlaceHolderPageTitleInTitleArea.

But wait... we can't change this file! So, let's change what points to it... oh, wait, that's onet.xml in the site definition... we can't change that file! What's our option? Delete all wiki sites created from this site definition. Edit the site definition, redeploy it, re-create all wiki sites from it and restore their content from backups. OMG.

So, to remain supported, if I want a custom site definition... and there are good reasons for it as people describe above... then take Andrews's approach and strip it down, replacing functions with stapled features. You'll thank yourself down the road.

# re: You don't need to create site definitions 2/27/2008 9:36 AM AC [MVP MOSS]
Gravatar Mark-
Great comment!

 re: You don't need to create site definitions 3/9/2008 11:11 PM Mark E
Gravatar Great article thanks.

Quick beginner type question. I have played around with deploying the minimal publishing site definition on codeplex but I don't understand how to use it as the basis of a new site collection. Currently I can only figure out how to use it when creating a new sub site, but I need my top level site to use the definition.

Any help or links to info appreciated

Mark

 re: You don't need to create site definitions 3/26/2008 3:58 AM P
Gravatar What about default welcomepage. This page is already created in pagelib when feature is stapled on. What if you want to use a custom pagelayout as welcomepage? Do you have to create a feature than will remove the current pagelayout before adding a new one?

# re: You don't need to create site definitions 3/26/2008 4:27 PM AC [MVP MOSS]
Gravatar P-
So just delete that page and replace it with something you want to use. Then update the welcome page property of the SPWeb to point to your page.

 re: You don't need to create site definitions 3/28/2008 10:23 AM P
Gravatar Thanks.
Use PublishingWeb.DefaultPage. I tried to strip down the onet.xml to only contain the configurationelement. All features get activated by stapling, also modules. Has anyone tried this? I have some troubles with contenttypebinding (file not found - pages) and pagelayouts that appear without associated contenttype.

Is it true that onet.xml will disappear in next version of Sharepoint?

# re: You don't need to create site definitions 3/28/2008 10:47 AM AC [MVP MOSS]
Gravatar P-
This process does work. Are you trying to bind the content type to the Pages library? No need... let SharePoint do that on the fly when you create a page in that list. As for the page layouts without an associated content type, you need to make sure you set the PublishingAssociatedContentType field when provisioning the page layout. As for the onet.xml file, there is nothing public about the next version of SharePoint (O14)... way to early to assume these things.

 re: You don't need to create site definitions 3/31/2008 5:04 AM P
Gravatar I tried to remove the publishingfeatures from Microsoft from onet to a staplerfeature. I dont`t get any errors but when I look in the gallery, many publishingpages from MS (like defaultLayout.aspx) have no contenttype. Here is mye code:

<Configurations>
<Configuration ID="-1" Name="NewWeb"/>
<Configuration ID="0" Name="X">
</Configuration>
</Configurations>

Stapler.xml
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">

<FeatureSiteTemplateAssociation Id="C85E5759-F323-4EFB-B548-443D2216EFB5" TemplateName="X#0" />
<FeatureSiteTemplateAssociation Id="02464C6A-9D07-4F30-BA04-E9035CF54392" TemplateName="X#0" />
<FeatureSiteTemplateAssociation Id="6C09612B-46AF-4B2F-8DFC-59185C962A29" TemplateName="X#0" />
<FeatureSiteTemplateAssociation Id="C6561405-EA03-40A9-A57F-F25472942A22" TemplateName="X#0" />
<FeatureSiteTemplateAssociation Id="F6924D36-2FA8-4f0b-B16D-06B7250180FA" TemplateName="X#0" />
<FeatureSiteTemplateAssociation Id="B21B090C-C796-4b0f-AC0F-7EF1659C20AE" TemplateName="X#0" />
<FeatureSiteTemplateAssociation Id="00BFEA71-1C5E-4A24-B310-BA51C3EB7A57" TemplateName="X#0" />

<!-- Searchfeature -->
<FeatureSiteTemplateAssociation Id="7AC8CC56-D28E-41f5-AD04-D95109EB987A" TemplateName="X#0">
<Property Key="SearchCenterUrl" Value="~SiteCollection/Finn" />
<Property Key="DocLib" Value="$Resources:cmscore,List_Pages_UrlName;" />
</FeatureSiteTemplateAssociation>
<Elements>

This process wont work since we obvisily have some timingissuses. http://blogs.tamtam.nl/mart/lsquoStaplerrsquoVsLsquoSiteDefinitionrsquoFeatureActivation.aspx.

Have someone tried this?


 re: You don't need to create site definitions 3/31/2008 11:00 AM P
Gravatar Found the solution. Features in the staplerfile is not activated in order. When you create my own publishing features (pagelayouts with associated contenttypes), you have to make sure that MS OOTB features is activated before using ActivationDependencies.

 re: You don't need to create site definitions 6/3/2008 3:39 PM CH
Gravatar I've been very interested reading this thread as I've been looking for a solution to customizing the existing Search Center site definition. I would definitely like to avoid creating a new site definition and just use features but I'm completely lost as to how to do this.

Basically what I want to do is change the default search page to one of my own creation (we have some custom requirements), as well as provision some other pages that will be used by the search center.

Ideally it would be nice to provision a new search center, activate the feature, and have everything be wired up nicely but I haven't been able to figure out if that's even possible outside of a custom site definition.

Any thoughts?

# re: You don't need to create site definitions 6/4/2008 9:25 AM AC [MVP MOSS]
Gravatar CH-
You could do a lot of that with a few Features, but frankly I think you do want to create a new site def. based on what you describe.

 re: You don't need to create site definitions 6/4/2008 10:25 AM CH
Gravatar AC,

Thanks for the quick response. I was kind of losing my mind trying to figure this out. In the end, I'm thinking of using features to deploy the custom page layouts, web parts, etc. and the use the site definition to manage the provisioning of the pages, which shouldn't change often, if ever.

# re: You don't need to create site definitions 6/10/2008 8:09 AM Phil Wicklund
Gravatar AC,

I was really intrigued by your post. One area that I’m still puzzled with is how this could relate to branding. Specifically, how could you easily “activate” a particular brand across your entire farm. I see site definitions as the easiest approach if that farm wide (or web app. wide) consistency is desired. I wrote a short blog post that details my thoughts more fully:

http://philwicklund.com/archive/2008/06/09/phil’s-top-10-best-practices-for-branding-sharepoint-part-2-of-10.aspx

Thanks a million!

Phil

# re: You don't need to create site definitions 6/10/2008 8:48 AM AC [MVP MOSS]
Gravatar Phil-
You totally missed the point of my post. You still don't need to create a site definition to do this. You can achieve the exact same thing using Features & Feature stapling.

# re: You don't need to create site definitions 6/10/2008 11:55 AM Phil Wicklund
Gravatar Sigh…. So the stars just aligned in my brain – I now understand what you’re saying. For some reason I was getting hung up on large scopes, say a web application or a farm, that need to carry a consistent brand. But if every site in that farm upon creation had a feature that auto-activated and set the MasterUrl property, every site WILL have that brand. After figuring that out, I stumbled over what to do with existing sites that have already been provisioned (potentially thousands), however, I quickly realized that a custom site definition obviously wouldn’t help there either, so that’s a mute point too. I’ll need to write a follow up post most certainly…

My SharePoint upbringings raised me to be very excited/dedicated to site definitions – I almost feel like I just lost my best friend here. Hopefully in V4 Microsoft will come out with another convoluted set of XML files that I can learn up and down, and then I can claim to be smart again :)

Thanks AC!

Phil

 re: You don't need to create site definitions 6/24/2008 6:16 AM SnakeWIKI
Gravatar HI,
I want to create a custom site definition for WIKI sites.
I want to change the layout of the WIKI site and pages - to change color, font, add different logo, and a custom menu to the left side of the site.
How do I do this? I really really need help on this, a step by step.
Pretty please, help me!

Thanks

//SnakeWIKI

# re: You don't need to create site definitions 7/24/2008 8:14 PM Doug Ware
Gravatar Great post! I think it's important to note that if you have features with receivers that accept properties, you can't set the property values via stapling. If you want something other than the default property values you'll have to include the feature activation in a site definition.

http://www.elumenotion.com/Blog/Lists/Posts/Post.aspx?ID=62

Post Feedback

Title:
Name:
Email:
(email will not be displayed)
Url:
Comments: 
Please add 3 and 3 and type the answer here:    
All Comments Are Filtered & Moderated
Unfortunately comment spammers are just too effecient and are constantly dirtying up blogs with irrelivant and unwanted comments trying to improve their standing on search engines. All comments on this blog are moderated. I do not censor comments, but I don't approve comments with vulger language or those soliciting products. Most of the time comments are approved within a few hours of being submitted with the only exception when I'm traveling.

Why are you asking for my email address?
The only reason I'm asking for your email address, which isn't required to submit a comment, is to provide a gravatar if you've created an account for yourself and associated your email address with a small image. If you have a gravatar created for the email address you submit, it will appear next to your comment. Otherwise nothing will appear.

What is a gravatar?
A gravatar is a "globally recognized avatar." You can get more information about gravatars, as well as create your own for free, at www.gravatar.com. You can also view my gravatar here.


Copyright © 2003 - 2008 Andrew Connell
Creative Commons License 
This work is licensed under a Creative Commons License
Site design by Heather Solomon.

 
 
MOSS WCM Training
Looking for MOSS 2007 WCM developer training? Look no further! I teach my 4-day hands-on and 5-day online WCM classes for developers I offer through the Ted Pattison Group.

Get more information on the WCM courses!


Upcoming Classes
 Hands-on WCM:
 » Atlanta, GA
   Sept 22-25, 2008
 Online WCM:
 » July 21-25, 2008
 » December 8-12, 2008


» Register today!

JAX Office Geeks
Jacksonville Office Geeks (JOG)
JOG is a special interest group in Jacksonville, FL dedicated to bringing the local SharePoint commnity together to share tips, tricks, ideas and best practices for developing solutions on the SharePoint platform.

Next meeting details...
When:
Thur. Sept 18th, 2008
  6-8p EDT
Topic:
Enterprise Content Management - Document Retention

Speaker:
John Holliday, MVP MOSS

RSVP Today!


» Subscribe to the JOG newsletter