Home > Uncategorized > Custom site definitions VS Custom templates

Custom site definitions VS Custom templates

March 24th, 2006 Leave a comment Go to comments

When it comes to sharepoint deployment, site definitions are preferred the most. People often rely on site definitions more than custom templates. I agree that it gives you more control on every thing, but it is not always the best solution and it truly depends on what you want to accomplish. In this article I would try to give you a high level understanding of both solutions and you got to decide which one suits you the best.

1) Custom site definitions:


  • Data is stored directly on the Web servers, so performance is typically better.
  • Full control over look and feel of site
  • ASPX pages can be defined as ghosted modules. Ghosted files are not copied into site content and are directly read from site definition (They are stored in the directory in which site definition exists) and cached on the web server. Any changes to these files are automatically propagated to all sites which are based on the site definition. For example add “ this is a changes” to default.aspx page in one of the site definitions (e.g: STS). You will see this in all default.aspx pages of the sites which are based on the site definition. As soon as you make a minor change to a ghosted file through Front page it becomes unghosted and added to the site’s content.
  • A higher level of list customization is possible through direct editing of a SCHEMA.XML file.
  • Certain kinds of customization to sites or lists require use of site definitions, such as introducing new file types, defining view styles, or modifying the drop-down Edit menu.


  • Customization of site definition requires more effort than creating custom templates.
  • Any error or inconsistency in site definition related xml files prevent site definition from working.
  • Changes to site definitions must be done one by one and after each change you must restart IIS and check to see if your change has not broken anything.
  • Most of site definition files are xml based and altering them requires a good understating of xml elements and attributes used in these file. However share point SDK fully covers them.
  • I tried using ghosting with an HTML page , but it did not work because HTML pages are cached differently than ASP.NET pages.
  • It is difficult to edit a site definition after it has been deployed.
  • Doing anything other than adding code can break existing sites (especially deletes).
  • Users cannot apply a SharePoint theme through a site definition.
  • Users cannot create two lists of the same type with different default content.
  • Customizing site definitions requires access to the file system of the front-end Web server.

2) Custom templates


  • Custom templates are easy to create.
  • Almost anything that can be done in the user interface can be preserved in the template.
  • Custom templates can be modified without affecting existing sites that have been created from the templates.
  • Custom templates are easy to deploy. All you need to do is to upload them to the template gallery of the site you wish to derive sub-sites from.


  • Custom templates are not created in a development environment.
  • They are less efficient in large-scale environments.
  • If the site definition on which the custom template is based does not exist on the front-end server or servers, the custom template will not work.
  • Top-level sites cannot be created based on custom templates.

Categories: Uncategorized Tags:
  1. No comments yet.
You must be logged in to post a comment.