Day 17 of 40
WKND: Pages and Templates
Editable templates, template types, and the page component
By the end of today you should be able to
- Explain the difference between static and editable templates
- Describe the template type → template → page relationship
- Explain the roles of structure, initial content and policies
- Say what cq:template and cq:allowedTemplates control
Static vs editable
AEM has two template systems. Static templates are the legacy model: a template in /apps,
changeable only by a developer with a deployment. Editable templates replaced
them, and they are what you should use — they live in mutable /conf, so a suitably
privileged author can restructure a template without a release.
The three-layer relationship is worth memorising:
Template type (in/apps, immutable, developer-owned)
→ Template (in/conf, mutable, template-author-owned)
→ Page (in/content, mutable, author-owned)
A template type is a blueprint for templates — it seeds what a new template starts as. Once created, a template is independent of its type; changing the type does not retroactively alter existing templates.
The three parts of an editable template
Open a template in the editor and you get a mode switcher. Each mode edits a different subtree:
- Structure — components that appear on every page using this template. Locked by default, so authors cannot remove them. A header and footer belong here. Unlocking a component moves it into the authorable area.
- Initial Content — components a new page starts with, which authors may then change or delete. It is a starting point, not a constraint, and it only affects pages created after the change.
- Layout — responsive layout settings per breakpoint.
- Policies — for each container, which components are allowed, and per component, its design configuration.
Structure is enforced on every page, forever, including existing ones. Initial content is copied once at page creation. Editing structure changes every page immediately; editing initial content changes nothing that already exists.
Policies
A policy is design configuration attached to a component within a template.
Policies live under /conf/<appId>/settings/wcm/policies and do two jobs:
- On a container — the allowed components list. This is what actually decides what an author can drop onto a page. A component missing from the policy will not appear, no matter what its component group says.
- On a component — its design options: which heading levels a Title may use, which Style System classes are offered, whether an Image allows lazy loading.
Policies are shareable: several templates can reference the same policy, so a change propagates to all of them.
The overwhelmingly common cause is the container's policy, not the component. Check the template's policy for the layout container before you go looking at componentGroup or the component definition.
Wiring a page to a template
cq:templateon a page'sjcr:contentpoints at the template that created it. AEM uses it to resolve structure and policies at render time — which is why editing structure affects existing pages.cq:allowedTemplateson a content folder is a list of regular expressions controlling which templates may be used beneath that path. This is how you stop an author creating a landing-page template inside the news section.
The page component
A template's structure references a page component (wknd/components/page), which is
itself a proxy for the Core Components page component. It renders <html>,
<head>, metadata, and the clientlib includes — which is exactly where tomorrow's
and day 19's material connects.
Type seeds template; template governs page. Structure is permanent and shared, initial content is a one-time copy, and policies decide what authors may actually place.
Watch
Adobe's own videos for this topic. They load only when you press play.
Read on Experience League
The primary sources these notes are drawn from.
Your notes
Saved automatically to this browser.
Check yourself
11 questions on today's material. 80% to pass.