Custom templates remain tied to a particular site definition (for example, the site definition for SharePoint Web sites or Meeting Workspace Web sites), so that if the site definition is not present or is changed, the custom template cannot work.
Site Definitions : As the name implies, A Site definition is "core definition of a site" . Each site definition emerges through a combination of files that are placed in the 12 hive of WFE during installation of SharePoint. Site definition files include .xml, .aspx, .ascx, and .master page files, as well as document template files (.dot, .htm, and so on), and content files (.gif, .doc, and so on).
Difference between them are as follows
Site Definitions
- Files are on disk, better performance.
- Highly customizable and extensible (XML and .NET code is much more flexible than UI)
- Can provision multiple webs This could be achieved using Provisioning handler ( For more info, refer to the Publishing Site Definition in the 12 hive )
- Complex to create
- Requires admin access to server for deploying.
- Modifying the site definition after provisioning at least one site from it is not supported and might break existing sites.
Site Templates
- Files are in database, less efficient.
- Not easily extensible (You are limited by what UI offers)
- Can only provision one web
- Easier to create
- Installable from a Web UI by site owners.
- Custom templates can be modified without affecting existing sites that have been created from the templates(**).
** Please note that If the site definition on which the custom template is based does not exist on the WFE, the custom template does not work.
On the surface, it appears that a site template has numerous advantages; it is certainly easier to create and deploy, and you can change it without breaking sites that use earlier versions of the template because it is not centralized in the 12 hive.
However, the fact that a site template contains everything about a site in a single file makes granular modifications of individual elements very difficult. For many projects, that is a good enough reason to suffer the additional complexity of site definitions.
However, site definitions present a different challenge. If you change an existing site definition in the 12 hive, you run the risk of breaking any sites that were created previously and use the existing definition. ( Besides, this is not supported by Microsoft ) , The key is to adopt the same strategy as for the core WSS site definitions:
Keep the definition as simple as possible and use feature stapling for everything else. Feature stapling allows you to add a feature to an already existing site definition. You may think this would be a complete waste of time, because you can simply add the feature into the site definition using far less code than having a feature staple, but when I tell you that
Microsoft does not support modifying a site definition in any way after a single site has been provisioned from that site template, you may reconsider.
Features are not an alternative to site definitions. Features are a complement to site definitions. If you keep the site definition as simple as possible and use features for the majority of a site elements, you gain the benefits of granular control in the development environment while reducing the risks involved in making changes to production systems over the life of the sites.