Thursday, November 18, 2021

Quick site creation | Site Template in AEM(Adobe Experience Manager)

A Site Template provides a starting point for a new site. A Site Template includes some basic theming, page templates, configurations, and sample content. Adobe provides a Basic Site Template to accelerate new implementations. The predefined site template can be a starting point for any site creation.

Site templates:
Artifacts containing themes and templates are a developer-free way to create production-ready sites. Templates are customizable and can be reused across regions, brands, and experiences.

Site creation wizard:
The site creation wizard imports site templates into the Experience Manager interface as a complete website ready for immediate authoring and personalization.

Out-of-the-box core components:
Drag-and-drop components let you easily customize page elements, like text and imagery, as well as functionality, like search, navigation, and bread crumbs.

Style system:
Select various style elements to adjust the layout, content, and design of components to create a brand design and maintain consistency across pages, all without backend development.

Integrated front-end workflow:
Front-end developers can configure sites in their preferred code environment then export the finished product back into Experience Manager — even as authors continue to build content.

Quick site creation/Site Template feature helps to help you to set up a landing page/microsite with ease and speed. The developer needs to be involved to customize the template and developing our own template.

The Quick site creation through the Site Template(Site from Template) is currently enabled only in AEM as a Cloud but the functionality is still in prerelease mode.

Refer to understand how the prerelease channel can be enabled for AEM as a Cloud/AEM as a Cloud SDK.

The site creation through Site Template will be enabled once the prerelease channel is enabled for the AEM as a Cloud environment/Local SDK.

java -jar aem-sdk-quickstart-2021.11.6019.20211109T172940Z-211000.jar -r prerelease
quick site creation in aem

The latest standard site template can be downloaded from, create the site using this template.

Refer to for more details on importing site templates and creating sites based on the template.

The imported templates are available under /conf/global/site-templates

The relationship between site and site template is managed through context-aware configurations under the site-specific conf folder.

The site content and styles can be changed/authored by content authors and also the templates can be modified if required.

Each site created through the Site template creates its own set of templates under /conf folder

The standard template can be checked out from, the template can be customized by the developer based on the custom requirements.

git clone

The customized site template can be built and imported to AEM as Cloud/Local SDK and sites can be created using the customized template.

To build the template

npm install
npm run build
npm run deploy - to deploy to the local instance, for cloud instances manually import the generated template package under the template root(aem-site-template-standard-{version}.zip)

Change the version number in package.json “version”: “1.1.0” or customize the configurations to create a completely new site template.

The Site theme can be downloaded(one-time initial download) for a specific website now and the theme can be customized by the FE developer.

Select the site root folder, select “Download Theme Sources” under the site panel

Somehow the downloaded theme is not in the expected folder structure, the src folder is missing — looks to be a defect in the latest SDK versions, rearranged the files based on the folder structure in the standard theme

Modify the AEM/Project details to the .env file

# AEM url
# AEM site name
# AEM proxy port

Now the FE developer should be able to apply the theme changes and test the changes by proxying the request to the AEM server — http://localhost:7001/content/sample3/en/home.html?wcmmode=disabled(the page requests are proxied to the AEM server and the local theme CSS and JS are injected into the page). While the FE developer working on the theme changes the content Author can enable the required content changes. Refer to for more details.

The site-specific theme changes can be deployed to the AEM cloud server through Cloud Manager Front End Pipeline, create a new site-specific theme repository in CM, define a deployment pipeline with code option as Front End. The pipeline will deploy the changes to CDN and inject the CSS/JS links to the AEM website.

The FE developer should be able to continuously improve the theme, test the changes locally through the proxy and deploy the theme changes to AEM servers through Front End Cloud Manager Pipeline(somehow no option to upload the theme changes to the local SDK server). Refer to for more details on deploying the theme changes to AEM servers.

In summary, quick site creation is a very good feature to quickly launch landing pages and microsites without much involvement from AEM backend developers. The sites can be quickly created, themed, and launched, also the theme can be continuously improved by the FE developer without much involvement from AEM BE developers.

Currently, the quick site creation template directly points to the Core components, if required pointed to platform level proxy components by customizing the standard site creation template, this will help us to apply some of the platform level common changes across the websites.

Some of my concerns —

Reusability — site-specific templates, reusability is limited.

Maintainability — site-specific templates and FE modules will create more overhead for maintenance.

Note — The Quick Site Creation tool is currently a tech preview. It is made available for testing and evaluation purposes and is not intended for production use unless agreed with Adobe Support.


Wednesday, November 10, 2021

Single Page Application(SPA) Design Patterns with AEM(Adobe Experience Manager)

A single-page application is a web application or website that interacts with the user by dynamically rewriting the current web page with new data from the webserver, instead of the default method of a web browser loading entire new pages.

SPA application will provide some of the benefits like

  • Front end developer has full control over the app
  • Seamless UI experience
  • Ease in building more interactive applications
  • Better performance

But need to watch out on some the areas like

  • SEO optimization — MPA(Multi-Page Application) application may give better SEO considering multiple pages in the website for the search engines to crawl
  • Security issues — SPA applications are more prone to XSS attacks
  • No WYSIWYG editor for content authoring.
  • More dependency on Developments teams for site launches/site changes
  • Lack of analytic insights — Considering Single page, may not be able to get details Analytics like MPA

The Single Page Applications (SPA) may not be appropriate for all the use cases, should be selected carefully based on your need and use cases.

Considering the importance of SPA, now the focus is more on SPA with CMS — Consume the content from CMS systems to enable the SPA experience to end-users.

In this post let us discuss, How AEM works with SPA frameworks to enable a seamless experience for the end-users, and explore the different design patterns for SPA with AEM.

Headless SPA:

In this design pattern, the SPA application is completely separated from AEM, and content from AEM is consumed through headless GraphQL APIs as needed. The content in AEM is managed through Content Framnents and exposed through GraphQL API as a JSON.

In this pattern, the front-end developer has full control over the app but Content authors cannot leverage AEM’s content authoring experience.

High-level steps to enable this pattern-

  • Create Content Fragment Models in AEM to structure the Content
  • Author Content Fragments through Content Fragment Model
  • Enable QraphQL API’s
  • Enable CORS
  • Consume AEM’s GraphQL APIs from the SPA application

Refer to for more details on enabling Content Fragments and consuming the data through GraphQL API.

The persistent GraphQL queries can be used to improve the data fetching performance from the SPA application.

Any GraphQL libraries e.g Apollo GraphQL client can be used to fetch the data from AEM, Adobe already enabled some of the wrapper client libraries to fetch the data.

JS —

Java —

Node JS —

Refer to for a quick simple demo(Refer to for WKND demo)

Refer to for more details on this design pattern.

Integrated SPA:

In this design, the SPA is integrated into AEM, the project fully leverages the SPA Editor SDK and the frontend components are developed as a library and the content structure of the app is delegated to AEM

The benefits of this design are, the content author can edit the app using AEM’s content authoring experience. The SPA is compatible with the template editor.

The developer is not in control of the structure of the app, the developer can still reserve areas of the app for content that is not meant to be authored using AEM.

The SPA is responsible for the routing and AEM listens to it and fetches the component data based on it.

SPA Editor — AEM’s SPA Editor provides support for in-context editing of a Single Page Application or SPA. Combine AEM’s rich content editing with all the benefits of SPAs

AEM’s SPA Editor JS SDK — In short, the SPA Editor JS SDK is a collection of open-source JavaScript libraries that provide a framework to enable the editable content for SPA pages through AEM SPA Editor.


The basic concept is to map a SPA Component to an AEM Component. AEM components, running server-side, export content in the form of JSON. The JSON content is consumed by the SPA, running client-side in the browser. A 1:1 mapping between SPA components and an AEM component is created.

Supported Frameworks — React JS and Angular are supported out of the box.

The aem-project-archetype can be used to create AEM SPA projects

mvn -B archetype:generate \
-D archetypeGroupId=com.adobe.aem \
-D archetypeArtifactId=aem-project-archetype \
-D archetypeVersion=30 \
-D appTitle=”My Site” \
-D appId=”mysite” \
-D groupId=”com.mysite”
-D frontendModule=general

The value for the frontendModule parameter can be angular or react for a Single Page App

If required update the default values in .env/.env.development files under ui.frontend project

The aem-clientlib-generator module enabled as part of the ui.frontend project generates the AEM ClientLibraries for the SPA scripts.

The SPA components internally use the AEM Content Service API to fetch the required authored content — the JSON data exposed through JSON exporter.

If the existing SPA follows the AEM SPA development guidelines, then the SPA can be migrated to AEM and edited through the SPA editor

Refer to the below links for more details



Some of the limitations with the current version of SPA Editor — the below features are not currently supported by the SPA editor

  • Target mode
  • ContextHub
  • Inline image editing
  • Edit configs (eg. listeners)
  • Style System
  • Undo / Redo
  • Page diff and Time Warp
  • Features performing HTML rewriting server-side such as Link Checker, CDN rewriter service, URL shortening, etc.
  • Developer mode
  • AEM Launches

The SPA Editor(Integrated SPA) is the recommended solution for projects that use a SPA framework (React or Angular) with AEM.

External SPA with Editable Areas:

In this design, the SPA is hosted outside of AEM, the developer keeps control over the app by only enabling authoring in restricted areas of the app. The content for the editable areas is enabled by AEM content authors.

The Developer will keep full control of the SPA application but the Content authors are restricted to a limited set of AEM’s content authoring experience.

With the SPA Editor 2.0, it’s possible to enable the in-content editing to specific areas or snippets in the app.

High-level steps to enable this pattern —

  • Create SPA project with latest Maven Arch type — remove the ui.frontend module as the SPA is externaly hosted.

mvn -B archetype:generate \
-D archetypeGroupId=com.adobe.aem \
-D archetypeArtifactId=aem-project-archetype \
-D archetypeVersion=30 \
-D appTitle=”My Site” \
-D appId=”mysite” \
-D groupId=”com.mysite”\
-D frontendModule=react\

  • Deploy the AEM project
  • Create a Page using the “Remote SPA Page” template and enable the SPA URL to the page properties
  • Enable CORS policy in AEM to allow SPA application to fetch AEM content — the default configuration to support the localhost SPA is already enabled under ui.config/src/main/content\jcr_root/apps/spaeditableareas/osgiconfig/, modify based on your SPA URL
  • Enable CORS policy in SPA application to allow AEM to access the asset-manifest.json e.g http://localhost:3000/asset-manifest.json
  • Enable AEM Editor SDK’s to the SPA application
  • Instantiate/Initialization of the Model Manager — Proxy is enabled for local Development(fetch the model through the proxy), Model Manager with Model Client(AEM Publish Server URL) can be used to fetch the model from remote AEM publish servers
  • Enable Editable areas — Container(Page)/Fixed Components, the required components should be enabled in Template policy for the Layout container.
  • Edit content in AEM

Refer to for more details.

Refer to for the sample project

Server-Side Rendering(SSR):

Server-side rendering (SSR) is rendering client-side SPAs on the server and then sending a fully rendered page to the client. This allows for dynamic components to be served as static HTML markup.

SSR is not required for all projects, select if SSR is going to provide more SEO and performance benefits, the SSR design will introduce additional complexity, effort, and cost.

Refer to the following URL to understand more on SSR in AEM.

The SSR rendering can be enabled through Node JS/Express or Adobe Runtime I/O, Adobe recommends Adobe I/O runtime for enabling Server Side Rendering. There are two communication flows

  • AEM Driven — AEM performs the bootstrapping and serving of content
  • Adobe I/O driven — Adobe I/O Runtime is responsible for the bootstrapping.

Let us review AEM Driven communication flow — I am using Node JS/Express to enable SSR in my local system(Adobe recommends Adobe Runtime I/O to enable SSR)

High-level steps to enable this pattern —

  • Create SPA project with latest Maven Arch type

mvn -B archetype:generate \
-D archetypeGroupId=com.adobe.aem \
-D archetypeArtifactId=aem-project-archetype \
-D archetypeVersion=30 \
-D appTitle=”My Site” \
-D appId=”mysite” \
-D groupId=”com.mysite”\
-D frontendModule=react\
-D enableSSR=y

The parameter”enableSSR” enables SSR support for the front-end project.

  • If required update the default values in .env/.env.development files under ui.frontend project
  • Build/Strat and Deploy SSR — Various npm scripts are enabled in ui.frontend project (build-with-ssr, build-with-express, start-ssr-ioruntime, start-ssr-express, and deploy-ssr-ioruntime) — I am using build-with-express and start-ssr-express for my local testing. The SSR server will be running in default 3233 port while executing “build-with-express” and “start-ssr-express”
  • Deploy the complete project to AEM
  • Remote Content Renderer — ensure the Remote content renderer is enabled with correct “Content path pattern” and “Remote endpoint URL”, the default configuration is enabled while creating the new project — http://localhost:4502/system/console/configMgr/com.adobe.cq.remote.content.renderer.impl.factory.ConfigurationFactoryImpl~spassr (spassr is my project name)
  • Edit the required content in AEM

Now the content is Server Side rendered — http://localhost:4502/content/spassr/us/en/home.html?wcmmode=disabled, the content will be Client-Side Rendered if the SSR service is not available.

Refer to for the sample project

In conclusion, the Single Page Applications (SPA) may not be appropriate for all the use cases, should be selected carefully based on your need and use cases. The integrated SPA model will be ideal for new AEM projects with SPA applications — this will give seamless authoring experience along with required control to Developers. In the case of SSR, Adobe recommends Adobe Runtime I/O for Server Side Rendering but Node JS flow is also supported.