How to create and use Dreamweaver templates, part 1: introduction

Dreamweaver logoAn overview of some of the basic concepts, tools, and options available in Dreamweaver Templates (DWT). These notes are particular to the CS3 version, but many will apply to other versions, as well.


Templates are KEY to creating a site that you can easily maintain for the long haul.  Even if you are not the one currently maintaining a site, your future self might be asked back to update a site in a few years...and you want those updates to be easy.

A template allows you to specify the areas of a page that users can edit in order to keep their content current. The main goal of a template is to allow you to reuse a complete layout/design on multiple pages, while also limiting the chance that a user will accidentally break that layout.

Given the potentional overwritten file problems caused if you have multiple Dreamweaver users updating a site, a developer's dream is to never need to touch every page of the site. Thus, a secondary goal when designing DWTs is to create the basic DWT structure in such a brilliant, flexible, well-thought-out fashion, that only the Cascading Style Sheets (CSS) and included files will ever need to be updated.


There are two main flavors of XHTML to choose from: transitional and strict. When creating a new site, one should generally use strict XHTML, as it enforces the separation of content (XHTML) from presentation (CSS) and will make your future design changes easier.  The main reason one might choose to use transitional is for older, legacy sites that contain some deprecated markup.

For more information see this excellent blog post comparing transitional and strict markup.

Once you've chosen your XHTML flavor, you will then need to carefully consider what type of XHTML structure to create to allow for the most flexibility in CSS designs and redesigns. You'll first need to map out some of the components that will appear in your template design, such as regions.


By default, regions in DWTs - defined using HTML comment tags - are uneditable by the end user. In order for users to be able to update content in a flexible manner, but without breaking the template, developers must use these regions wisely in their DWTs.

There are three main types of regions in your DWT toolkit - editable, repeating, and optional - as well as an editable tag attribute.

For more information, see my blog post on template regions.


In a word, don't use them.

Library items, such as a navigation menu or a footer, are frequently used on many pages of a site. Since one of the developer goals for DWT creation is to never have to touch multiple pages on the site, use server-side includes and regions instead of library items.

For more information, see my blog post on server side includes.


Code snippets let you store code (XHTML, PHP, etc.) for quick reuse. Unlike library items, however, changing a snippet doesn't change any other piece of code on your site.

Snippets are the ultimate pouch for your toolkit: this is where you can create a repository of the code that you use over and over in your web development.

Be wary of using Dreamweaver's example snippets, however, as some of them may not conform to current standards.

For more information, see Adobe's article on working with snippets.


By default, DWTs limit you to placing server scripts (SSIs, PHP, etc.) inside of the <html></html> tags.

Scripts outside of these tags won't be copied to documents based on that template UNLESS you add special code to allow for it.

For more information, on choosing whether to place scripts in your template or on individual pages, see Adobe's article on server scripts.


When you add a relative link to a DWT, DW expects the link to be relative to the Templates folder, and will update the link automatically when you create a new page to reflect the link relative to that page.

However, as the template does not interact with included files, the links within SSIs should either be absolute or relative to the root folder.

Good practice tip: never link to index.html files, just to the document root for the appropriate folder.  The server will automatically direct you to the correct file for that folder - and that file may change names or file extensions in the future.

For more information, see Adobe's article on links in templates.


Think of template parameters as page variables that users can edit. For example, a parameter could be an optional region ("leftColumn") that users can turn on or off.


Parameters must be defined only once in the non-editable area of the template's head block.  However, you can reference a parameter in any uneditable region of the template.

Be aware that parameter changes in the template will not affect already existing child pages, only new pages made based on the template. So, it's best to have your parameters decided upon before creating multiple pages.

Template expressions are statements that allow developers to use parameters to perform actions when new a page is created. For example, an IF expression can tell a page which SSI to include, based on whether the page is pure XHTML or includes PHP coding.

Like parameters, expressions must be defined in the uneditable region of a template, but can be referenced in an editable region on a page. Unlike parameters, changing expressions in a template changes all, not just new, child pages.

For more details on this Javascript-like language, see this article on template parameters & expressions.

For More Information