AEM 6.4 has reached the end of extended support and this documentation is no longer updated. For further details, see our technical support periods. Find the supported versions here.
This document describes how to customize page authoring in the modern, touch-enabled UI and does not apply to the classic UI.
AEM provides various mechanisms to enable you to customize the page authoring functionality (and the consoles) of your authoring instance.
Clientlibs
Clientlibs allow you to extend the default implementation to realize new functionality, while reusing the standard functions, objects, and methods. When customizing, you can create your own clientlib under /apps.
The new clientlib must:
cq.authoring.editor.sites.page
cq.authoring.editor.sites.page.hook
categoryOverlays
Overlays are based on node definitions and allow you to overlay the standard functionality (in /libs
) with your own customized functionality (in /apps
). When creating an overlay a 1:1 copy of the original is not required, as the sling resource merger allows for inheritance.
For further information see the JS documentation set.
These can be used in many ways to extend the page authoring functionality in your AEM instance. A selection are covered below (at a high level).
For further information see:
This topic is also covered in the AEM Gems session - User interface customization for AEM 6.0.
You must not change anything in the /libs
path.
This is because the content of /libs
is overwritten the next time you upgrade your instance (and may well be overwritten when you apply either a hotfix or feature pack).
The recommended method for configuration and other changes is:
/libs
) under /apps
/apps
When you are editing a page, there are various modes available. These modes are implemented using layers. These allow access to differing types of functionality for the same page content. The standard layers are: edit, preview, annotate, developer, and targeting.
A standard AEM instance provides the MSM layer. This accesses data related to multi site management and highlights it in the layer.
To see it in action you may edit any We.Retail language copy page (or any other live copy page) and select the Live Copy Status mode.
You can find the MSM layer definition (for reference) in:
/libs/wcm/msm/content/touch-ui/authoring/editor/js/msm.Layer.js
This is a sample package showing how to create a new layer (mode), which is a new layer for MSM view.
CODE ON GITHUB
You can find the code of this page on GitHub
The asset browser shows assets of various types/categories (e.g. image, documents, etc). The assets can also be filtered by these asset categories.
aem-authoring-extension-assetfinder-flickr
is a sample package showing how to add a new group to the asset finder. This example connects to Flickr’s public stream and shows them in the sidepanel.
CODE ON GITHUB
You can find the code of this page on GitHub
When authoring pages, the user must often select from resources (e.g. pages, components, assets, etc.). This can take the form of a list for example from which the author must choose an item.
In order to keep the list to a reasonable size and also relevant to the use case, a filter can be implemented in the form of a custom predicate. For example, if the pathbrowser
Granite component is used to allow the user to select the path to a particular resource, the paths presented can be filtered in the following way:
com.day.cq.commons.predicate.AbstractNodePredicate
interface.pathbrowser
.For further detail on creating a custom predicate, see this article.
Implementing a custom predicate by implementing com.day.cq.commons.predicate.AbstractNodePredicate
interface works in the classic UI as well.
See this knowledge base article for an example of implementing a custom predicate in the classic UI.
Each components (usually) has a toolbar that provides access to a range of actions that can be taken on that component.
aem-authoring-extension-toolbar-screenshot
is a sample package showing how to create a custom toolbar action to render components.
CODE ON GITHUB
You can find the code of this page on GitHub
In a standard AEM installation:
/libs/cq/gui/components/authoring/editors/clientlibs/core/js/editors/editorExample.js
Holds definitions of the various editors available.
There is a connection between the editor and each resource type (as in component) that can use it:
cq:inplaceEditing
for example:
/libs/foundation/components/text/cq:editConfig
/libs/foundation/components/image/cq:editConfig
property: editorType
Defines the type of inline editor that will be used when the in-place editing is triggered for that component; e.g. text
, textimage
, image
, title
.
Additional configuration details of the editor can be configured using a config
node containing configurations as well as a further plugin
node to contain necessary plugin configuraiton details.
The following is an example of defining aspect ratios for the image cropping plugin of the image component. Note that because of the potential of very limited screen size, the crop apect ratios were moved to full screen editor and can only be seen there.
<cq:inplaceEditing
jcr:primaryType="cq:InplaceEditingConfig"
active="{Boolean}true"
editorType="image">
<config jcr:primaryType="nt:unstructured">
<plugins jcr:primaryType="nt:unstructured">
<crop jcr:primaryType="nt:unstructured">
<aspectRatios jcr:primaryType="nt:unstructured">
<_x0031_6-10
jcr:primaryType="nt:unstructured"
name="16 : 10"
ratio="0.625"/>
</aspectRatios>
</crop>
</plugins>
</config>
</cq:inplaceEditing>
Note that in AEM crop ratios, as set by the ratio
property, are defined as height/width. This differs from the conventional definition of width/height and is done for legacy compatability reasons. The authoring users will not be aware of any difference provided you define the name
property clearly since this is what is displayed in the UI.
To implement a new in-place editor (within your clientlib):
For example, see:
/libs/cq/gui/components/authoring/editors/clientlibs/core/js/editors/editorExample.js
Implement:
setUp
tearDown
Register the editor (includes the constructor):
editor.register
Provide the connection between the editor and every resource type (as in component) that can use it.
aem-authoring-extension-inplace-editor
is a sample package showing how to create new in-place editor in AEM.
CODE ON GITHUB
You can find the code of this page on GitHub
It is possible to configure a component so that it has multiple in-place editors. When multiple in-place editors are configured, you can select the appropriate content and open the appropriate editor. See the Configuring Multiple In-Place Editors documentation for more information.
To add a new page action to the page toolbar, for example a Back to Sites (console) action.
aem-authoring-extension-header-backtosites
is a sample package showing how to create a custom header bar action to jump back to the Sites console.
CODE ON GITHUB
You can find the code of this page on GitHub
The out-of-the-box workflow, Request for Activation, is automatically triggered when a content author does not have the appropriate replication rights.
To have customized behavior upon such activation you can overlay the Request for Activation workflow:
In /apps
overlay the Sites wizard:
/libs/wcm/core/content/common/managepublicationwizard
This itself, overrides the common instance of:
/libs/cq/gui/content/common/managepublicationwizard
Update the workflow model and related configurations/scripts as required.
Remove the right to the replicate
action from all appropriate users for all relevant pages; to have this workflow triggered as a default action when any of the users try to publish (or replicate) a page.