SharePoint custom site definitions... I'm lost...

10 Comments

• We sing a song when we are editing definitions. Its about being in a pit, it goes,
  
  
  
  "Just keep digging, just keep digging, just keep digging, digging, digging".
  
  
  
  

• The thing to keep in mind is that some modifications to the site def after provisioning a site will cause changes to all site. For example, changing the aspx's will cause changes to all unghosted sites, but changing which lists are provisioned and which web parts on the page (in the onet.xml) will not reflect on sites already created.
  

• I've been doing a lot of work the past few months with sitedefs so I'll post a blog with some more details about changing things in place, aspx files, etc. which might help explain things more.
  

• We do loads of changes to the sitedefs and we create our own, but we are also depending on the fact we can change things AFTER we create instances of the sitedefs. This is one of the big reasons to use sitedefs in the first place. Ofcourse we prevent unghosting of those sitedefs.
  
  
  
  The thing is that Microsoft decides in all its wisdom that they consider this as "unsupported".
  

• See my blog comments.
  

• This comment is published on the weblog of Cornelius:
  
  
  
  Hi Cornelius,
  
  
  
  Microsoft is talking about "Supported and unsupported scenarios", and under unsupported scenarios they make the following statement: "When you work with custom site definitions or custom area definitions, the following scenarios are not supported:... You modify a custom site definition or a custom area definition after you deploy the custom site definition or the custom area definition.".
  
  
  
  They are not differentiating between unsupported by the software, or unsupported by Microsoft support.
  
  
  
  It is not that we are just playing around with site definitions and are messing things up. I'm talking about 20+ team development on huge SharePoint implementations. Ofcourse we test things out, not on just a virtual PC, on multiple test servers. It is not about expecting "free support".
  
  
  
  What is it about: the model of being able to extend and modify instantiated sites over time is key to a large implementation. For example the MySite definition. Assume the implementation of an intranet for 30.000 customers, each having their own MySite. So each customer has an instantiation of the MySite site definition. It is impossible to come up with the perfect MySite definition upfront. And I can tell you: the default Microsoft implementation is NOT the implementation to go forward with for years to come. So over time new functionality is needed, based on user comments and user statistics. It is impossible to sell to your customers that you need a huge team of people to do FrontPage customizations on 30.000 sites, in the mean time ghosting all the modified MySite pages. The other approach left: modifications through code. First of all we have the ghosting issue again, second issue: we now have a site definition (which we may not modify), and after instantiating we have to do modifications through code, that should be kickstarted directly after site creation. This approach is way to complex and defeats the power of the site definition system. This is just one example, there are many more examples in a real life SharePoint implementation.
  

• so i can't change the site definition in the home page?
  

• 
  

• 406535.. Outstanding :)
  

• I like what you guys are up also. Such smart work and reporting! Keep up the superb works guys I've incorporated you guys to my blogroll. I think it will improve the value of my site :).