Editable Templates

Learn how Editable Templates replaced static templates in AEM and how they give template authors control over page structure without developer involvement.

Last reviewed: December 2024

·AEM 6.2+AEM 6.5AEM as a Cloud Service
✅
Quick Understanding: Editable Templates let non-developers (template authors) create and modify page templates using a visual editor. Unlike old static templates (which required code changes), Editable Templates are configured in AEM's UI. You define the structure, set which components are allowed, and configure initial content — all without touching code.

🔍 What Is It?

An Editable Template is a template created and managed in AEM's Template Editor UI (not in code). It consists of three layers:

1. Structure Layer

The fixed skeleton of the page — header, footer, main content area. Components here are locked and can't be moved or deleted by page authors. Only template authors can change them.

2. Initial Content Layer

Pre-populated content that appears when a new page is created. Authors can modify or delete this content. Think of it as the "starting point" for new pages.

3. Layout Layer

Defines the responsive grid breakpoints for the page. Controls how components behave at different screen sizes.

Templates are stored in /conf/your-site/settings/wcm/templates/ and are managed through AEM's Tools → Sites → Templates UI.

🎯 Why Do We Need It?

The problem with old Static Templates:

  • →Stored in /apps as code
  • →Every change required a developer and a deployment
  • →No visual editor — just XML files
  • →Template authors had to rely on developers for every update

Editable Templates solve this:

  • →Template authors can create and modify templates in the UI
  • →No code deployment needed for template changes
  • →Visual editor shows exactly what the page will look like
  • →Policy system controls which components are allowed
  • →Locked vs. unlocked areas give clear governance

In enterprise projects, this is critical — marketing teams need to create new landing page templates without waiting for development sprints.

🏗️ What Happens in Real Projects?

Real Project Setup:

  1. Developer creates the template type (the base template structure in code — one-time setup)
  2. Template Author (usually a senior content person or UX lead) creates templates using the Template Editor
  3. Content Author creates pages using those templates
  4. Developer creates components that template authors can add to templates

Common Templates in a Project:

  • →Home Page Template
  • →Article Page Template
  • →Landing Page Template
  • →Product Page Template
  • →Campaign Page Template

Governance Model:

  • →Template authors control structure and allowed components
  • →Content authors fill in content within that structure
  • →Developers build the components that both groups use

⚙️ How It Works

Template Policies:

Policies are the most important concept in Editable Templates. A policy defines:

  • →Which components are allowed in a container
  • →Default configuration for components (e.g., default image sizes)
  • →Design properties (color themes, font choices)

Policies are stored in /conf/your-site/settings/wcm/policies/ and can be shared across multiple templates.

Template Structure in JCR:

/conf/mysite/settings/wcm/templates/
  article-page/
    jcr:content/
      jcr:title = "Article Page"
      pageStructure = "mysite/components/page/article"
    structure/         ← Structure layer
      jcr:content/
        root/
          header/    ← Locked header component
          main/      ← Layout container (unlocked)
          footer/    ← Locked footer component
    initial/           ← Initial content layer
      jcr:content/
        root/
          main/
            text/    ← Pre-placed text component
    policies/          ← Policy assignments

Allowed Components Policy:

In the Template Editor, you configure each container's allowed components. This is what controls what authors see in the component picker when editing a page.

💻 Example

Setting Up an Editable Template — The developer's role in setting up the template type and page component for Editable Templates.

xml
<!-- /conf/mysite/settings/wcm/template-types/page/.content.xml -->
<?xml version="1.0" encoding="UTF-8"?>
<jcr:root xmlns:sling="http://sling.apache.org/jcr/sling/1.0"
          xmlns:jcr="http://www.jcp.org/jcr/1.0"
    jcr:primaryType="cq:Template"
    jcr:title="My Site - Page"
    jcr:description="Base template type for all My Site pages"
    ranking="{Long}100">
  <jcr:content
      jcr:primaryType="cq:PageContent"
      sling:resourceType="mysite/components/structure/page"/>
</jcr:root>

🤔 Common Confusions

❓ What is the difference between a Static Template and an Editable Template?

Static Templates are defined in code (/apps) and require developer changes to modify. Editable Templates are created and managed in AEM's UI by template authors. New projects should always use Editable Templates. Static templates are legacy.

❓ What is the difference between Structure and Initial Content in a template?

Structure defines locked components that every page based on this template will have (header, footer, navigation). Initial Content defines pre-populated editable content — authors can change or delete it. Structure is the skeleton; Initial Content is the starter content.

❓ Can a content author accidentally break the page structure?

No. Components in the Structure layer are locked — authors can't move, delete, or edit them. Only template authors (with specific permissions) can change the structure. This is the governance model that makes Editable Templates enterprise-ready.

❓ Where are Editable Templates stored?

In /conf/your-site/settings/wcm/templates/. Unlike Static Templates which are in /apps (code), Editable Templates are in /conf (configuration) and are managed through the UI. They're replicated to Publish just like regular content.

🚨 Common Production Issues

Template not showing in page creation wizard

template is not enabled. Go to Template Editor and enable the template.

Component not appearing in allowed components

the policy for the container doesn't include the component. Update the policy in the Template Editor.

Template changes not reflecting on existing pages

existing pages inherit the template structure, but some changes may require the page to be "refreshed" or republished.

Policy changes affecting too many templates

policies are shared across templates. Changing a shared policy affects all templates using it. Create template-specific policies to avoid this.

Template locked components appearing editable

the lock configuration on the component in the Structure layer is not set correctly.

Authors lose access to expected components

a shared policy was tightened without checking every template and authoring group that depends on it.

Template works in lower environment but not production

/conf template, policy, template type, or page component content is missing from the deployment or publication path.

Unexpected design drift

too many editable style options were exposed in policies, letting authors create off-brand page variants.

✅ Best Practices

Create a separate "Template Authors" user group with permissions only to /conf

don't give template authors access to /apps.

Use shared policies for common configurations (like image sizes) but template-specific policies for unique allowed component sets.

Design templates to be flexible

don't over-lock components. Give authors room to create diverse pages.

Create a "Base" template type that all your templates extend, reducing code duplication.

Document which templates are available and when to use each one

authors need guidance.

Test templates with real content before go-live

template issues often surface when actual content is added.

Separate shared policies from page-type-specific policies so one authoring change does not accidentally affect the whole site.

Review policy changes like code changes

allowed components, styles, responsive behavior, and author permissions all affect production pages.

For AEM as a Cloud Service, keep template type code in the pipeline and manage /conf template content with clear promotion and publishing rules.

🏛️ Architect's Note

Senior Architect's Perspective

Editable Templates represent a fundamental shift in how AEM governance works. The key insight is the separation of roles:

  • →Developers build components and the template type
  • →Template Authors assemble templates from those components
  • →Content Authors create pages using those templates

This role separation is what makes AEM scalable in enterprise organizations. A well-designed template system means marketing teams can launch new page types without waiting for development.

Configuration vs. Code: Editable Templates are configuration (stored in /conf), not code (stored in /apps). This means they can be managed through the AEM UI and don't require code deployments. However, they do need to be replicated to Publish — treat them like content, not code.

💬 Frequently Asked Questions

Can I convert a Static Template to an Editable Template?

Yes, but it's complex. Adobe provides the AEM Modernize Tools (available on GitHub) that can help migrate static templates to editable templates. In practice, it's often easier to create new editable templates and migrate content gradually.

How do I restrict which templates are available for a specific section of the site?

Use the "Allowed Templates" configuration on the parent page or in the page properties. You can specify which templates can be used under a particular section of the site tree.

What is a Template Type vs a Template?

A Template Type is the base definition (created by developers in /conf/global or /conf/site). A Template is an instance created from a Template Type by template authors. Multiple templates can be created from the same Template Type.

Can Editable Templates be exported/imported between environments?

Yes. Templates in /conf are replicated through the standard AEM replication mechanism. For moving between environments (dev → staging → prod), use AEM's package manager to export and import the /conf content.

🎯 Key Takeaways

1Editable Templates replace Static Templates — no code changes needed for template updates
2Three layers: Structure (locked), Initial Content (editable starter), Layout (responsive grid)
3Policies control which components are allowed in each container
4Stored in /conf, not /apps — managed through AEM UI
5Role separation: Developers → components, Template Authors → templates, Content Authors → pages
6Shared policies reduce duplication but require careful change management

🎯 Practice this topic in interviews

↗ Where this topic fits

Sources

Sources / References

Use these AEM references to verify the concept in official docs and continue into the most relevant SplashRide pages.

Related SplashRide pages

SplashRide AEM learning path

Browse the full AEM topic collection and learning order on SplashRide.

AEM Interview Prep

Practice AEM interview questions and scenario-based answers.

AEM Developer Career Path

This AEM developer career path explains how to become an AEM developer through JCR, Sling, HTL, client libraries, Dispatcher, Cloud Service delivery, project depth, and interview-ready enterprise implementation skills.

Drupal Developer Career Path

A practical route through Drupal content modeling, site building, theming, modules, configuration management, APIs, performance, deployment discipline, and interview preparation.

AEM Templates

Understand AEM templates — the foundation of every page. Learn the difference between static and editable templates and how they shape the author experience.

AEM Components Explained: Dialogs, HTL, Sling Models, and Core Components

Learn AEM components with component nodes, dialogs, HTL, Sling Models, Core Components, authoring, inheritance, and real project patterns.