This is probably more for posterity than anything else, as most folks should have been using SharePoint 2003 technologies for almost a year.

But my work site uses 2003 still, with an upgrade coming up in the next few months.

Recently I had to fix some site-wide site templates that had some issues with unghosted and non-functional pages. I’ll look a little into what we think generated the problem, what doing it the “right way” looks like, and how to administer, manage and deploy site themes.

What are site themes? How do they compare to site definitions?

In contrast to site templates, which are a mixture of HTML, ASP.NET and CAML and are difficult to customize and troubleshoot owing to there not being any meaningful testing or debugging configuration, or meaningful development environment – if you decide to go into site definition-land, prepare to use a lot of text editors, lots of incremental testing, and lots of prayer (or whatever substitutes in your life), site templates are actually pretty easy to generate. You use a mixture of the in-SharePoint GUI, themes (which you may have had to generate the hard way) and FrontPage 2003 to create site templates out of a test or design site (you can even use a live site, but it can be more confusing to get it right that way), then use the SharePoint GUI to generate the site template, which then shows up in the site collection site template gallery.

When you’re satisfied with your site template, you can download the *.stp file from the site template gallery and begin to deploy it to other SharePoint site collections via either the global site template gallery (administered with the stsadm.exe utility) or a site collection’s site template gallery (via uploads/deletions through the SharePoint GUI).

If on the other hand you decide to create your own site definitions, you do get slightly better performance, the possibility of creating truly novel sites (site templates, on the other hand, must be based on pre-existing site definitions, most of which are created by either Microsoft or by really big-time development houses that are leveraging SharePoint for the functionality) that do cool things not possible with out of the box site definitions. The problem is that there’s no meaningful development environment for site definitions. In 2005, some of the TechEd presenters got almost cussed out for this failing. I’ve worked with site definitions myself, and let’s just say they’re not for the faint of heart. I worked for 2 weeks on a site definition pilot and I was barely done in time, even though the overall changes to standard definitions we were seeking were really minor. There is no debugging, no testing environment. You just use a VPC running SharePoint and deploy your changes to that and hope they worked, test by creating a new site based on the site definition and cross your fingers and hold your breath. A single error of certain kinds of syntax can keep the entire site from working properly. It can even be difficult to delete a site based on a non-functional site definition.

I’d recommend sticking with site templates if at all possible. They’re saner and easier to work with.

If you feel you must work with site definitions, feel free with my blessing (just don’t ask me to help you). Good starting points: 1, 2, 3, 4.

Things to know

Here’s a list of concepts to be familiar with before you start:

• The difference between site templates ans site definitions, above.
• Ghosting and unghosting – Ghosted pages are ones that have not been edited and saved in FrontPage. If you edit a page and save it, even if no changes were made, in FrontPage, you immediately unghost it. This makes maintenance tricky – all look and feel customizations need to be made separately to unghosted pages – and also cuts down performance – each unghosted page is rendered separately from ghosted pages, which get performance bonuses from being based on standard pages from site templates or site definitions.
• GhostHunter, part of the Web Part Toolkit from BlueDog Limited, helps you identify unghosted pages and reset them to ghosted status (losing any specific look & feel customizations possibly made to the page via FrontPage)
• FrontPage 2003 – be well enough acquainted with FrontPage that you know how to use it to edit Web Parts and other smart parts in SharePoint without saving changes to the page (and unghosting it, causing problems outlined above).

Doing the Dirty Deed

So you want to make a clean, unadulterated, properly ghosted Site Template?

The process requires careful movement, solid thinking, and not clicking any buttons without really thinking about what you’re doing.

What kinds of changes can you make?

Any kinds of changes that are available with site themes (good links: 1, 2), i.e.:

• Colors – overall site color themes
• Graphics, including banners at the top and sides of the page
• Text font, size, color, placement

Additionally, site templates allow you to customize the behavior of default lists as well as the default lists that any site based on them starts with, including:

• For any list: Default content, default columns, column defintiions, security, URL/path information, view, any other list setting available through “Modify settings and columns”
• Lists’ appearance in the quick launch area
• Upper banner navigation
• Web Part Page libraries and Web Part Pages and their layouts
• Default look and feel of default.aspx, not the layout of the web part page, but the web parts that are on it, and how they’re configured, including the default view into any list the list view web parts might point to

The only real trick to any of this is keeping in mind where each setting is, and how to go in and set those settings without messing with the proper ghosting of the pages in the template-creation site.

So, to start I make sure I have the right admin permissions to do what I need, then I usually pick whatever standard site definition is the closest match to the behavior of the site I want. If the site definition has been previously locked of out of display in my dev environment, I get my admin to unlock it in WEBTEMP.XML (a little more about that here, though this is for 2007). I then create a new site, usually in a specially designated site collection for building templates, using that site definition to create the site.

My company already put a bunch of time into properly creating some branded site themes for each of our operating companies, so I make sure those are installed in our dev environment, and I go ahead and apply it to the newly-create site. Then I go about primarily using the raw SharePoint GUI to make the site look as close as possible to what I want it to look like. The only things I generally don’t do in the GUI are editing the horizontal nav bar and potentially also editing the Quick Launch bar (these are for later with FrontPage 2003). So examples of changes here that I sometimes do are:

• Delete the default Shared Documents document library, recreate one initially named “docs” so that’ll be the URL/path name, then go back and rename it to “Shared Documents”, do any tweaking necessary to columns and create a few useful, typical views based on some metadata or another.
• Delete the default Issues list, and rename it for a better URL/path name. Add/subtract/edit metadata/columns as needed. Create an initial issue as a sample.
• Edit the shared view of default.aspx and remove the default Windows SharePoint Services image web part entirely. Insert a Content Editor Web Part with some Javascript that overrides the horizontal nav bar with new text/links and hides the Site Settings behind some other web part page.

When going ahead and using FrontPage 2003, I open, for instance, the site and then default.aspx (make sure editing is enabled in ONET.XML). ONCE default.aspx is open, DO NOT CLICK SAVE or in any way save from this view. When you are done with changes here, just close the page without saving. It’s trippy, I know, but if you don’t do this right, you have to go back and use ghost hunter to undo your unghosting, which is a pain. Anyway, once FrontPage has opened default.aspx, just right-click and choose to edit properties of the various navbars you wish to edit. Use the in-FrontPage GUI to make the changes, click Apply and OK as needed, but DO NOT CLICK SAVE. Once this part is done, close FrontPage to deny yourself the temptation of clicking save.

If you do make a mistake and do click save, you can install the Web Part Toolkit from Blue Dog and then use the GhostHunter Web Part to find and reset any unghosted pages. I’ll defer to the developers’ documentation here for how to do that.

Now that, finally, your site looks exactly like it should, you save it as a template. To do that, go to Site Settings, then Go to Site Administration, and finally Save site as template. If you created any custom content while creating your template site, you need to save that to the template as well. Follow the prompts and your site will be saved to the site collection template gallery (a link will be provided). Follow that link and administer the template’s name there, download a copy as an *.stp file that can be copied to other SharePoint Farms (as long as the destination has the site definition you used to create the template, and the theme you used to create the graphical changes). You can also delete the template from the site collection site template gallery if you like.

If you want to deploy this to a virtual server’s site template gallery (and not have to deploy to every single site collection you may have, which could be quite a few), you can use the stsadm -o addtemplate and stsadm -o deletetemplate to add and subtract, and stsadm -o enumtemplates to list them. You can do this on any SharePoint farm server where SharePoint is installed, so Search, Index and Web Front End servers work. The changes you make affect the whole farm, but only go into effect on an iisreset. So you can single one server out in the farm, use host files to make sure you test against it, deploy your changes and test against that site after issuing an iisreset there, then do iisreset on the rest of the farm servers when you’re satisfied your deployment worked.

A word of warning: The list of active templates is displayed to uses and to the stsadm -o enumtemplates in the order they were added, so if you want the templates to display alphabetically, you need copies of all of the templates that are deployed, plus the one(s) you are deploying, and you need to add them in alphabetical order, by template title. There is no other way to sort them. We ended up writing a couple of utilities to do this. You could script such a thing, maybe working against an XML file that keeps track of site template titles, descriptions and template file names, with the cscript Windows Scripting Host and Javascript, or really handily in PowerShell, if you can install .NET 2.0 on your front end web servers.

Related Resources

Here are some related resources:

• Windows SharePoint Services (2.0) Administrator’s Guide – Working with Templates

Questions?

Feel free to leave questions in the comments!