Hmmm, something fishy about importing subsites to be top-level sites

I was working on some vcasts for this site when I stumbled across something I wish I'd put in the book (see I am still working on it, almost a year after printing...). So without further ado, here's the thing:

You see, I have a subsite that I like to use in my conference presentations to demonstrate this and that. It's a contracting site that I've filled with custom lists, fields, columns, content types, dashboards, views, and lots of data. I like to demonstrate how to create nifty site templates with it, how to manipulate data, connect lists, and more.

So it was a natural progression that, when I wanted to demonstrate custom permissions and how to work around applying an .stp file (the single file that a site template gets packed into) to a top-level site, I'd make an export of that contractor site and use it for the demo.

So I exported the contractor subsite (and the two child subsites off of it-- one for a blog and one for a wiki).

I then made a new site collection and imported the export file to it... and found that not only did none of my workflows 'port, but that the default, three-state workflow was deactivated for all sites in the collection.

?!

I knew that workflows and alerts don't port well, but I was surprised that the default workflow for WSS was disabled. That was unexpected.

But here is why it happened in my opinion (with a shout out to James Finley, who patiently listened to me rant and kindly repeated himself over and over, with screenshots, before the issue was resolved):

When a site collection is made, the top-level site gets created and a site template and site collection features are applied (in the case of WSS 3.0, that means the three-state workflow).

In order to import a site, you must already have a site address to import it to (it doesn't create an address for itself). Because it is going to be applying the template and settings it used previously, there is no need to have a template applied to the new site because it's going to be written over. As a matter of fact, usually, importing to a completely clean new site address offers the best results. Generally, having no artifacts left to write over is cleaner and safer. This has always worked for me when moving subsites and what I tell people...

(( in contrast I must admit, I have very successfully imported over an existing site completely with no problems-- much to my dismay. ; ) I have also had a few hiccups when importing to a site with an existing template-- in front of a live audience-- as well.))

When you export and then import a subsite as a subsite to an existing site collection, the site collection features are already active, so they're available for the imported site.

And when you want a subsite to be the top level site of a site collection of its own (ie, working around not being able to apply a .stp template to a new site collection), you would normally use STSADM to do a createsite without a template, then import your exported site to it.

BUT, if you do that you run the risk of having no site collection features.

Why? James and I surmise that applying the template to a top-level site is what activates the site collection features for the entire site collection. No features at the top-level site means no features in any subsites either.

Think about it, you are importing a subsite to a top-level site-- when that subsite wasn't the one that had those features set originally, it depended on the top-level site of the its collection to do that. Therefore, that import file doesn't have the necessary hooks to start features. Without a template pre-applied, when you import, the site collection workflow doesn't activate at that site address when you import. Instead, you have to go to that top-level site's "site collection features" and activate it manually after the import is complete.

The solution (without manually having to activate the feature every time you import)? If you are going to apply a import to a new site collection's top-level site, apply a template to it first if you want the built-in site collection features. At the command line it's really easy. In the GUI it's even easier, you can't create a new site collection without applying a template.

((or, do what I did once, create a fully functioning site there first, then import over it. It made me sad, but the site collection features were active...))

An example of the commands I am referring to:

a simple export of a subsite: STSADM -o export -url http://wss2/contractors -filename file://dc1/backups/contractors.cmp

a simple site collection creation (with the standard team site template applied): STSADM -o createsite -url http://wss2/sites/contractors -owneremail person@sample.org -ownerlogin domain\siteadmin -sitetemplate sts#0

a simple import of the subsite to the new site collection as the top-level site: STSADM -o import -url http://wss2/sites/contractors -filename file://dc1/backups/contractors.cmp

((note that the export, import, and createsite commands have many more parameters than I am using here, this is just the simplest examples possible))

That also brings me to an old but interesting thought-- as to why MS decided to offer their fantastic 20 sites for site collection administrators as templates instead of import files? Why, in the end, did they end up having to split up the way those sample sites (site admin and server admin) were installed-- making them harder to adopt and apply?

There had been some speculation as to why MS did that. Site templates have shortcomings, one of which is the 50 to 500MB content limit. Also, there are things that don't move well, that work better with export/import.

But, those fantastic 40 templates (even the 20, less fancy site admin templates) were meant to encourage people to extend the use of SharePoint, and especially to purchase and use SharePoint Designer. That meant that Workflows had to 'port intact, for anyone who wanted to use the those sample sites. That means the sites for site admins had to be packaged as templates and not imports, because the workflows won't travel easily any other way.

((of course, an off-shoot of that is if a site is packaged as an .stp file, it can be installed by someone with only site administrator permissions-- hence the categorization. remember, it's not an unexpected or unfortunate shortcoming, if you can consider it a feature...))

And it explains why there are 20 site admin templates that are simple .stp template files, and why 20 are packaged as full solutions (with an additional application template core). Some of the sample sites were just too fancy to package as templates, and had to be offered with separate moving parts instead.

Getting back to the point of this post-- The subject, as to why importing my subsite as a top-level site deactivated the three-state workflow, bothered me. And because of that, I felt it important to let you know that it happened, how it happened, and how to fix it.

It's just one of those little things that might become a big thing at the end of the day on Friday when you thought it would be a piece of cake to move that nifty subsite to a top-level site like your boss asked you to...

.. so you've been warned. As always, check your site features, site collection features, security, versions, and alerts before considering the job done. You know workflows and alerts will be a problem, but check everything, just in case.