Someone changed my ONET.XML!

Okay, so there's some buzz going around based on a recent Knowledge Base article (KB# 898631) from Microsoft on supported and unsupported scenarios with custom site definitions. Some people are upset at the scenarios and say that the reason why we're using sitedefs (vs .stp files) is that we can apply the changes against existing sites to "automagically" update a site. Heather Solomon (new to my SharePoint blogroll) has a great reference blog on what directories contain what files and where do they end up when a site/area gets created. Nice stuff and very handy.

Anyways, here's some scenarios that I ran into a few times with some guidelines on how far you can push the sitedef envelope (even if it is unsupported).

Modifying the default setups. This is completely unsupported and while I do agree (after all, I wouldn't want someone to create a new portal and have things missing that should be there) however it does create an age old problem we've had with SharePoint. You can't create a new portal with custom areas. Sure you can create new areas by cloning existing ones, but since you can't modify the default setups all portals will always start exactly the same for everyone. The real crux is for organizations that want to customize the My Site so all new My Sites will get something more "corporate" with the standard stuff. After all, I can create a new default team site by copying the STS directory and messing with all the options (say I don't want people to be able to create discussion areas, no problem). However I can't touch My Site because it's part of the base system and thus unsupported.

There's another kicker to modifying default setups. Like I said with the Portal, these are default Setups. I don't recall seeing any hardcoded values anywhere that depends on these things being there but if I was supporting a product I sure wouldn't want someone calling me if they messed with my control pages. That's like screwing with a .NET assembly and removing bits and pieces of it and recompiling it back to hope it still works. The only thing is that you don't need to decompile the schema files that make up a SharePoint site because they're all there in front of you, with just a flick of Notepad away from becoming your worst enemy. So okay, I'll buy not modifying the default setups but for the love of all that is holy, can we at least modify My Site and have a choice of which portal definition we use when creating a new portal?

The other non-supported scenario is one of updating a sitedef once sites have been created. I'm on the fence with this because of doing a total fubar on an existing site (which I've done many times, it's not pretty). I can understand the need to put a stake in the ground and say this is unsupported. Like I said I've messed up sites by doing a redeploy over top of existing ones and boy did it hurt. There were points where I *had* to open the thing up in FrontPage just to delete it. Modifing sites in-place (via an updated sitedef) is a bit of a sort spot because as Serge van den Oever put it in this blog, the reason why we use sitedefs is so we can have more flexibility with creation of a site (sans programming) and update it easily. 

Here's the scenario I ran into with doing this. Create a list and define a field to be a DateTime field (don't get me started on Lookup fields again). Now sometime later you decide to change the DateTime field to a Text field. Boom. You try to revisit a list that uses that field and edit it and you'll be in a world of hurt. I don't have the exact DON'T DO THIS list of what fields can and cannot be transformed from and to (anyone game to putting one together?) but basically changing types can be bad. They sometimes can work. For example going from a numeric field (as long as you don't specify decimals, etc.) to text is sometimes okay. Going from Text to say Choice sometimes works. Again, there are some scenarios that work and some that just plain put you in reboot server land, you are screwed, do not pass Go. This is due to the fact that behind the scenes it's not a 1:1 mapping of column you create to column in database and all that metadata in all those tables sometimes just gets really, really confused.

Adding new fields (or adding anything). This isn't so much of a problem. Adding new fields to SCHEMA.XML generally always works with no ill effects (and I have yet to create a situation where it did). After all you are just adding more meta data about the lists so when a list renders it's add/edit form it's just another field to display. The only drawback here is if you make a field mandatory you can end up in a situation where your lists metadata isn't valid because any new fields will just be blank.

Of course, any of these scenarios, good, bad, or otherwise, are offiicially unsupported according to the KB article so buyer beware. What's odd is they support modifying sites via FrontPage. Now while I can only mess up one site at a time with FP, I can really mess it up with a simple removal of some DHTML or Web Part Zone tags (read: make site unrenderable to the point where you can't fix it). So that doesn't make sense to me.

P.S. I also stumbled across a nasty gotcha recently around missing files and the execution of ONET.XML. In ONET.XML you can specify files to copy to your new site when it gets created (again, referring back to the body of this blog, this section of ONET.XML only gets executed once on site creation hence why you can't update it and expect your sites to automatically be populated with new files that were not there before). Anyways, in the Modules section of ONET you can specify files to copy and where to copy them to. This is great but you'll get a nasty message as ONET is being executed when it hits a file it can't find. Yes, it's a file not found message and the new SharePoint Blue Screen of Death which has practically no information at all. I came across this but we were creating new sites with dozens of custom lists, dozens more of lists being generated and even more dozens of files being copied. Which file was it that was not found? The FileIOException class that will get thrown if you're doing this programatically contains a property called, what do you know, FileName. So why can't the IIS log, the SharePoint log, or even the SharePoint page itself tell me what file it can't find? I had to hunt and peck through my entire system until I found the culprit. In any case, I closed the ticket with Microsoft and asked them to kindly add more information error messages especially when they know the context of the message. It's akin to you buying something and your bank or the retailer saying "Not enough funds". So how much more do I need? I'm just looking for a little break here.