Customizing the default.aspx File
is in some ways even simpler than customizing the ONET.XML
file. You can simply use Notepad to make the changes to the HTML and ASP.NET tags that you want in the file. You can also use FrontPage and edit one of the sites created from the site definitionas long as you select Save As
from the file menu when you save the file and save it to another place
on your machine and then copy the saved file to the site definition directory manually. This process lets you edit the file visually with FrontPage without disturbing the ghosting process that SharePoint uses.
For example, one quick and easy modification to default.aspx
is to change the image that appears above the Quick Launch bar. To change the image, open default.aspx
from the site definition in Notepad and search for onetidtpweb1
, which is the ID of the image tag in the file (there's nothing special about searching for the tag by ID, it just helps to expedite finding the right spot in the file). In this tag replace home.gif
with the name of the replacement image file that you want to use, and change the height
attributes to match the height and width of your new image. Save the file.
The last step in making the customization is to place the image in the TEMPLATE\IMAGES directory underneath the C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\60 directory where all the other SharePoint files reside.
This time, you can see the effect of your changes without resetting IIS; sites created with your new template will reflect the new graphic.
Because of the effort that's involved in creating site definitions it's easy to get frustrated and decide to move back to just doing user templates. But then you have to deal with the unghosting and maintenance headaches of managing multiple user templates mentioned at the start of this article. Worse, there's a potentially more important concern if you're going to be managing a large environment.
Sites created with user templates do not maintain any record of the user template used to create them. However, all sites do record which site definition was used to create them. This can become important when you're trying to write utilities that manage large numbers of sites, because there's no way to determine which user template was used to create the site. If you have several well-defined types of sites on your server it may become impossible to write utilities to work on just those sites directly.
User templates are good for prototyping and for smaller SharePoint deployments where the configuration management issues relating to their tendency to allow ghosting and their inability to leave their mark on the sites that are created from them. However, larger environments would be wise to limit the use of user templates where possible.
The site definition process in SharePoint is extremely flexible, however, with that flexibility comes complexity. Site definitions consist of many interrelated files and directories, but after you understand their purposes it's easy to put all the pieces together.
Despite the complexity challenges with site definitions it's important to not slip into the trap of relying on user templates for larger deployments; otherwise, managing sites en mass becomes far more difficult than necessary.