In CMS world, Template, or Page Template is the base of the page user creates, it defines high level structure, basic functionality and sets the tone of look and feel. In Adobe AEM, the template concept is widely used across different products. There are templates for pages, forms, content fragments, experience fragments and assets. I am going to focus on page templates in this blog, since that’s one of the most commonly used features in my projects. Creating page template used to be a pure developer task, and content authors can only select from a list of predefined templates when they create a new page. This is changed since editable template was first introduced in AEM 6.2. It allows a super-author group (i.e. template authors) to create and edit page templates. Since its introduction, Adobe has made some enhancements to this feature in AEM 6.3. Both editable template and developer defined template, or static template, can be available for page creation. So you may have a question about which one to use, or both. I hope after this article, you will find some useful information and help you make this decision.
Best Practices for Templates
First of all, best practices for page templates are to reuse existing templates and keep the number of templates low, unless there’s a drastic structure or design change.
With that in mind, I am going to analyze static and editable template from the following perspectives: template creation, structure, page creation, permissions, tasks and responsibilities, and I will give you some tips and tricks, considerations and references when using either, or both. I have created an example of both static and editable template, it is available in my GitHub project, and I also created a content package for the sample content I used, it’s tested on AEM 6.3.
Template Creation
For static template, it’s developed by developers with a cq:Template
type and has a jcr:content
node with sling:resourceType
of the page component. After code is deployed to AEM, the temple will be available to use.
For editable template, a project specific folder is recommended to be created under /conf, AEM comes with /conf/global
by default and you can use that if it must (but that needs to be enabled also before use).
You can create the conf project folder (or enable /conf/global folder) by going to Tools -> General -> Configuration, check the “Editable Templates” box. If you prefer, you can also create it in your project code repository and deploy to AEM. The folder should have /conf/<
your-project
>/settings/wcm/templates
, which holds all editable templates for this project; /conf/<
your-project
>/settings/wcm/policies
, which holds all page and component content policies; and /conf/<
your-project
>/settings/wcm/template-types
(not a must, if you only use OOTB template types), which is kinda the template of an editable template and is copied over to the template (after that, only a static reference between template type and the template created from it). There are several OOTB template types:
/libs/settings/wcm/template-types/html5page
/libs/settings/wcm/template-types/afpage
/apps/settings/wcm/template-types/coreCmpPage (came with AEM Core WCM Components).
After the conf project folder is created, template authors can create the template by choosing a predefined template type in Tools -> General -> Templates -> Project folder.
After the editable template is created, it needs to be enabled and published before the content author can use it and create the content pages.
Structure
- Template location
For static template, template code is usually stored at /apps/<
your-project
>/templates
.
For editable template, template code is stored at /conf/<
your-project
>/settings/wcm/templates
. The template types and policies, however, can be stored at /conf, /apps and /libs. They follow the same order in resource resolution strategy as well.
- Structure in repository
For static template, /apps/<your-project>/templates and /apps/<your-project>/components/structure should be created by default from the Adobe AEM project maven archetype.
For editable template, you can create the /conf/<your-project> structure in either ui.content or ui.apps module in your project.
- Page/component design
For static template, design is stored at /etc/designs/<my-site>/jcr:content/<page-component-name>/<component-name>
(if page has a design path of /etc/designs/<my-site>) or /etc/designs/default/jcr:content/<page-component-name>/<component-name>
.
For editable template, design is stored at /conf/<
your-project
>/settings/wcm/policies
.
- Template node structure
For static template, it looks like:
/apps/<your-project>/templates/ <your-template-name> [cq:Template] jcr:content [cq:PageContent] (optional)<list-of-components> [nt:unstructured]
For editable template, it looks like:
/conf/<your-project>/settings/wcm/templates/ <your-template-name> [cq:Template] initial [cq:Page] jcr:content [cq:PageContent] policies [cq:Page] structure [cq:Page] (optional)thumbnail.png
- Page structure
Page created from a static template has initial nodes from the template, while page created from editable template usually has a “root” node and will have initial nodes under /<your-template-name>/initial, they are editable components. The page will also render with non-editable components defined in /<your-template-name>/structure. These components have a “lock” status and don’t have property editable = “{Boolean}true”
.
Page Creation
Before page can be created, you need to make sure either static or editable template is allowed in the designated path. Usually you can set Allowed Templates on (root) page properties, or you can set allowedPaths property in the cq:Template node. Precedence and detail can be found here.
There is no difference in page creation process, content authors cannot tell editable template from static template in the create page wizard. Both are displaying template title and thumbnail.
After page is created, page from editable template will not have design mode option. And there will be dynamic connection between the template and page. A change in /<your-template-name>/structure may hide component/content in existing page. Page from static template, however, will not have dynamic connection to the template after the page is created, changes to the template will not affect existing pages.
Permissions
Permission is not applicable to static template except to set up the standard authoring permissions and privileges for content authors. However, editable template is required to set up the default template authors group and configure the required access rights (ACLs) for these authors to create and edit templates in the /conf/<your-project>. That means they will need full access under /conf/<your-project>/settings/wcm/templates and /conf/<your-project>/settings/wcm/policies, and they will need at least read access under /conf/<your-project>/settings/wcm/template-types.
For details, see here.
Tasks and Responsibilities
Admin:
- (optional) Creates a new folder for editable templates
- Set up template authors group
- Configure ACLs for template authors
Developer:
- (optional) Creates template structure in the code repository
- Develop static template or any custom template types
- (optional) Configure policies and templates for Template Author
- Develop page component, clientlibs, services etc
- Develop content components that will be used in the page or editable template
- Knowledge transfer to Admin, Template Author and Content Author if required
Template Author (for editable template only):
- Create template
- Edit Structure, Initial Content and Layout of the template
- Configure content policies for the components and page
- Configure initial page properties, page design and other property if necessary
- Enable and publish the template
Content Author:
- (optional) Set up Allowed Templates property on the page
- Create page with template
- (optional) Set page design of the page
- Author page with components
Tips and Tricks
- If you create the editable template structure manually in your code base or CRXDE, make sure you have a /settings/wcm/templates node (even is empty), otherwise the folder won’t show up in the templates console.
- It’s also good to have a /settings/wcm/policies node, otherwise the content policies may write to /apps/settings/wcm/policies.
- If you have custom template types, it’s best to put the /settings/wcm/template-types node in the same path as where you put your /templates and /policies nodes.
- In your module’s /META-INF/vault/filter.xml, set filter properly so it doesn’t overwrite other folders inside /conf, or the project’s templates (/conf/<your-project>/settings/wcm/templates) and policies (/conf/<your-project>/settings/wcm/policies), since they will have authored content in JCR.
- Component code may require update if it needs to be drag and drop onto the editable template.
- In order to show the mobile emulator in toolbar and use the Layout mode, make sure your page resource type is added to com.day.cq.wcm.mobile.core.impl.MobileEmulatorProvider-<app-name>.xml.
- Set access rights properly if you use editable template, see Permission section.
- Put internationalization in mind when creating the editable template.
- Set up template availability strategically so correct templates show up in the right page path and easy to track and modify, test thoroughly for your use cases, see Page Creation section.
- If you already have a custom content policy, you can change the cq:policy in /conf/<your-project>/settings/wcm/policies, otherwise there are default policies you can use from wcm/foundation/components.
- Reference to ootb templates, Adobe sample projects when you are stuck, see References section.
Considerations
Static Template:
Being the legacy way of using and developing template, if your company have been on AEM for a while, your developer and content authors may have already got comfortable with static template, it has a smaller learning curve. Structure wise, I find static template simpler and straight forward, usually everything is defined in the page component. But the major drawback is that it is a developer only task. Developer develops and provides all the variations of template in the code, the template cannot be changed without a code release. Template cannot be visualized in AEM before a page is created. You may find yourself writing more code in the page component to include different business requirements. You may also end up having a new template and/or page component with small variations.
Editable Template:
With editable template, you give template authors the flexibility to create and modify the template as they want. It acts as a central place to manage everything about the template (structure, initial content, layout) and components used in the template. It’s more modular as you can control what components author can see and use on the page, if the component is editable or not, what design properties the page/components have, how should the component display on different devices, or even hide it on small screens. With the granularity level editable template supports, it has a more complex node structure than static template. If you are migrating to use editable template, make sure you accessed the requirements for not only the template but also the components. Expect bugs as you use template editor. For example, iparsys doesn’t work in template editor based pages. Since it’s new and more complex, time should be allocated and POC should be performed to set up the environment and foundation, so the transition can be smooth for production. Also training is recommended to admin, developers, template authors and content authors.
References
Blog demo project on GitHub: https://github.com/guangweiyao/blog
Content package for Blog demo site: https://drive.google.com/drive/folders/0BzjN-KcnRwx7elJ6eWlGOXQtMU0?usp=sharing
We.Retail project: https://github.com/Adobe-Marketing-Cloud/aem-sample-we-retail
AEM Template Editor custom template type project:
https://github.com/Adobe-Marketing-Cloud/aem-sites-example-custom-template-type
Create an Experience Manager Template using the Template editor: https://helpx.adobe.com/experience-manager/using/aem_lazybones.html#CreateanExperienceManagerTemplateusingtheTemplateeditor
Templates: https://docs.adobe.com/docs/en/aem/6-3/develop/templates.html
Creating Page Templates: https://docs.adobe.com/docs/en/aem/6-3/author/site-page-features/templates.html
Managing your content with the Adobe Experience Manager Template Editor: https://s3.amazonaws.com/qnuyfhrc/L314-summit-template-editor-workbook.pdf
Is allowpaths property work in Editable template ?
Yes, you can set Allowed Templates on (root) page properties, or you can set allowedPaths property in the cq:Template node. Precedence and detail can be found here: https://helpx.adobe.com/experience-manager/6-3/sites/developing/using/templates.html#TemplateAvailability
What exactly do we mean by : “Once a page is created using templates, after that if we make any change in static template it wouldn’t affect the page.”.
I have a AEM 6.0 system with me where pages are created by using static templates. When I add a component or make any change to the template script (like adding a class to a div) the changes are reflected across all pages.
Thanks for any help.