Site Definition vs Site Template

Site definition are deployed within 12\template\sitetemplates directory and are referenced in 12\template\1033\xml\webtemp*.xml files Wss offer site definitions to provide users with createable site templates out of the box. A site definition named sts prvoides familar site templates such as Team Site, Blank site, and document workspace. </p>

A site definition itself does not represent a creatable site template. Instead, a site definition contains one or more configurations, and these configurations are what appear to users as creatable site templates.

Site definition --contains--> configurations <--referenced by webtemp*.xml --> display configuration as creatable site template

When creating a new site by using the STSADM.EXE command-line utility or through custom code, you are often required to reference a site definition and one of its configurations by name. This is done by specifying the name of the site definition followed by the pound sign and the integer identifier of the configuration. For example, you can use STS#0 to reference the site template titled Team Site and STS#1 to reference the site template titled Blank Site. The following example uses one of these site template references when creating a new top-level site by using the STS command-line utility.

Changing a built-in site definitions and templates

One of the challenges in WSS 2.0 was adding new functionality to existing site definitions and templates. This was because the official guidance from Microsoft was to never edit an existing site definition or template once sites have been provisioned using it, and that developers should not modify the site definitions provided in the out - of - the - box installations, as future updates (hotfixes and service packs) could overwrite the files. To address this, Microsoft added the capability of Feature stapling.

Feature used to activate other feature

Sometime you can use a feature simply to activate other features.

When to make a feature hidden

When creating a Feature that contains a Feature receiver performing certain tasks that require special permissions, consider making it a hidden Feature, thereby requiring activation via STSADM.EXE. Why? When a Feature is activated from the browser interface, the code is executed within the context of the configured identity of the application pool hosting the Web application containing the site collection. This identity may not have the necessary permissions, such as writing to the file system. However, when a Feature is activated using STSADM.EXE, the identity of the user performing the command is used, who may have more permissions than the application pool’s identity.

Feature Scope

A Feature's scope enables developers quantify how broad the effects of activating the Feature are. If a Feature is scoped at the site level, then activation affects only the SharePoint site it is activated within. However, if it is scoped at a site collection level, then the activation affects all sites within the site collection. To administrator, the scope affect where the feature can be activated to after the feature is installed. If it is farm feature, it can be activated at http://.../_admin/ManageFarmFeatures.aspx, if it is webApplication feature, it can be activated at http://.../_admin/ManageWebAppFeatures.aspx, if it is sitecollection, it can be activated at http://../sitecollection/_layouts/ManageFeatures.aspx?Scope=Site, if it is site feature, it can be activated at http://../site/_layouts/ManageFeatures.aspx