This document describes how to customize consoles in the modern, touch-enabled UI and does not apply to the classic UI.
AEM provides various mechanisms to enable you to customize the consoles (and the page authoring functionality) of your authoring instance.
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. For example it can hold the code required for your custom component.
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.
These can be used in many ways to extend your AEM consoles. A small selection are covered below (at a high level).
You must not change anything in the
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:
Recreate the required item (i.e. as it exists in
Make any changes within
For example, the following locations within the
/libs structure can be overlaid:
consoles (any consoles based on Granite UI pages); for example:
See the Knowledge Base article, Troubleshooting AEM TouchUI issues, for further tips and tools.
You can customize the default view (column, card, list) for a console:
You can reorder the views by overlaying the required entry from under:
The first entry will be the default.
The nodes available correlate to the view options available:
For example, in a overlay for list:
Define the following property:
You can build your own components and include the corresponding client libraries for custom actions. For example, a Promote to Twitter action at:
This can then be connected to a toolbar item on your console:
For example, in selection mode:
You can use a custom rendering condition to overlay the standard action and impose specific conditions that must be fulfilled before it is rendered.
For example, create a component to control the renderconditions according to group:
To apply these to the Create Site action on the Sites console:
Create the overlay:
Then add the rendercondition for the action:
Using properties on this node you can define the
groups allowed to perform the specific action; for example,
This feature is optimized for columns of text fields; for other data types it is possible to overlay
To customize the columns in the list view:
Overlay the list of available columns.
On the node:
Add your new columns - or remove existing ones.
See Using Overlays (and the Sling Resource Merger) for more information.
If you want to plug additional data, you need to write a
[PageInforProvider](https://helpx.adobe.com/experience-manager/6-4/sites/developing/using/reference-materials/javadoc/com/day/cq/wcm/api/PageInfoProvider.html) with a
For example, see the class/bundle attached (from GitHub) below.
You can now select the column in the column configurator of list view.
When using a console, a common use case is when the user must 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. See this article for details.