AEM authoring dialog fields types sample

Adobe Experience Manager(AEM) authoring dialog is the combination of different form fields, these fields are required to make the content editable so author can easily add or update the AEM component content. Below are the few frequently use dialog fileds that AEM provides.

1. Textfield:

<text

jcr:primaryType="nt:unstructured"

sling:resourceType="granite/ui/components/coral/foundation/form/textfield"

fieldDescription="The text to display on the button."

fieldLabel="Text"

name="./jcr:title"/>

2. Browse path:

<link

jcr:primaryType="nt:unstructured"

sling:resourceType="cq/gui/components/coral/common/form/pagefield"

fieldDescription="Link to a content page, external URL or page anchor."

fieldLabel="Link"

name="./link"/>

3. Select/option field:

<headingElement

jcr:primaryType="nt:unstructured"

sling:resourceType="granite/ui/components/coral/foundation/form/select"

fieldDescription="The accordion item heading HTML element."

fieldLabel="Heading Element"

name="./headingElement"

ordered="{Boolean}true"

wrapperClass="foundation-toggleable">

<datasource

jcr:primaryType="nt:unstructured"

sling:resourceType="core/wcm/components/commons/datasources/allowedheadingelements/v1"/>

<granite:data

jcr:primaryType="nt:unstructured"

cmp-accordion-v1-dialog-edit-hook="headingElement"/>

</headingElement>

4. Hidden element:

<expandedHint

jcr:primaryType="nt:unstructured"

sling:resourceType="granite/ui/components/coral/foundation/form/hidden"

name="./expandedHint"

value="String[]" />

5. File upload:

<file

jcr:primaryType="nt:unstructured"

sling:resourceType="cq/gui/components/authoring/dialog/fileupload"

allowUpload="${not empty cqDesign.allowUpload ? cqDesign.allowUpload : false}"

class="cq-droptarget"

fieldLabel="Download Asset"

fileNameParameter="./fileName"

fileReferenceParameter="./fileReference"

mimeTypes="[image/*,video/*,audio/*,.pdf,.doc,.zip,.txt]"

name="./file"

title="Upload Asset"/>

6. Content fragment picker:

<fragmentPath

jcr:primaryType="nt:unstructured"

sling:resourceType="dam/cfm/components/cfpicker"

name="./fragmentPath"

fieldDescription="Path to the Content Fragment to display."

fieldLabel="Content Fragment"

emptyText="Enter or select Content Fragment"

pickerTitle="Select Content Fragment"

rootPath="/content/dam"/>

7. Radio Button Group:

<displayMode

jcr:primaryType="nt:unstructured"

sling:resourceType="granite/ui/components/coral/foundation/form/radiogroup"

deleteHint="{Boolean}false"

fieldDescription="Single Text Element mode allows selection of one multiline text element and enables paragraph control options. Multiple Elements mode allows selection of one or more elements of the Content Fragment."

fieldLabel="Display Mode"

name="./displayMode"

vertical="{Boolean}false">

<items jcr:primaryType="nt:unstructured">

<singleText

jcr:primaryType="nt:unstructured"

text="Single Text Element"

value="singleText"/>

<multi

jcr:primaryType="nt:unstructured"

checked="{Boolean}true"

text="Multiple Elements"

value="multi"/>

</items>

</displayMode>

8. Checkbox element:

<paragraphHeadings

jcr:primaryType="nt:unstructured"

sling:resourceType="granite/ui/components/coral/foundation/form/checkbox"

text="Handle headings as paragraphs"

name="./paragraphHeadings"

value="true"/>

9. Color picker

<color

jcr:primaryType="nt:unstructured"

sling:resourceType="/libs/granite/ui/components/coral/foundation/form/colorfield"

fieldLabel="Select button color"

name="./color"/>

10. Tabs

<tabs

jcr:primaryType="nt:unstructured"

sling:resourceType="granite/ui/components/coral/foundation/tabs"

maximized="{Boolean}true">

<items jcr:primaryType="nt:unstructured">

<!-- add items here -->

</items>

</tabs>

Note: Out of the box (OOTB) components/fields can be find under these directories.

• /libs/granite/ui/components/coral/foundation/form
• /libs/granite/ui/components/coral/foundation
• /libs/granite/ui/components/foundation
• /libs/cq/gui/components
• /libs/foundation/components 

How to bulk activate or publish the content pages in AEM aa CS

AEM Bulk Replication Process in AEM aa Cloud Service

1. Publish using content tree workflow
1. For bulk publishing content, use the Publish Content Tree Workflow. This workflow step is specifically designed for Cloud Service and efficiently handles large payloads. Avoid building custom bulk publishing code unless necessary. You can trigger this workflow via existing Workflow APIs.
2. For this, login to AEM >> Tools >> Workflow >> Models and copying the Publish Content Tree out-of-the-box workflow model, as shown below:

References:

1. https://experienceleague.adobe.com/docs/experience-manager-cloud-service/content/operations/replication.html%3Flang%3Den#publish-content-tree-workflow

What is processing profile in AEM

AEM cloud service supports processing profiles feature, using this we can create custom renditions for assets. This rendition could be the predefined as well as renditions craeted or generated by third party application or system.

To integrate the third party generated rendition we need to integrate with the AEM asset compute feature that is avaialble in Adobe I/O runtime and easily connect with AEM a a cloud serivce. 

Note: Processing profile option is not avaiable in local AEM cloud service SDK.

References:

• https://experienceleague.adobe.com/docs/experience-manager-learn/assets/configuring/processing-profiles.html 
• https://github.com/adobe/asset-compute-sdk
• https://experienceleague.adobe.com/docs/asset-compute/using/home.html

Difference between AEM publish and preview servers | Adobe AEM

AEM as a Cloud Service come with an add on preview server feature to preview and experience the content as end-user. 

1. The preview server is not accessible for public users, this is stricted with the allowed IP list in AEM Cloud Manager. Hence, only those users can access whose IPs are allowed.
2. Publish content to preview server, we have to go to manage publication > then select the destination as preview

References:

• AEM aa CS preview server fundamentals | previewing content
• Access preview service

Check render condition is not valid

*ERROR* [[0:0:0:0:0:0:0:1] [1692119460991] GET /editor.html/content/venia/us/fr.html HTTP/1.1] com.adobe.cq.msm.ui.servlet.IsSourceRenderCondition path /content/venia/us/fr.html to check render condition is not valid 

Rapid Development Environment (RDE) in AEM as a Cloud Service

Rapid Development Environment (RDE) in AEM as a Cloud Service is a new environment that you could include in your dev or prod instance on demand for quick deployment, this helps the AEM developers to quickly deploy the changes from local machine build just like we are doing package and bundle install using package manager.

Since AEM as CS package manage doesn't allow to deploy the code changes due to immutability of the system, but AEM as CS package manager allow to upload and install the content packages that includes paths like /content, /etc. 

Here, instead of using package manager for deployment RDE is using AppBuilder and pushing the locally build zip, jar files in AEM as CS RDE instance. Below are the detail about the Rapid Development Environment in AEM as CS development environment setup and uses of it.

How to setup Rapid Development Environment in AEM as CS?

1. First we need to enable the RDE instance for that you have to contact Adobe CSE/Support to get that enable under your license.

2. We need to install node and adobe cli to make the development setup and running in local machine.  

To enable and setup follow the steps given here: How to set up Rapid Development Environment | Adobe Experience Manager

How to use Rapid Development Environment in AEM as CS?

Using Rapid Development Environment is easy using adobe cli, for every task we have to just run one liner command on cli. To learn more and see the steps and action that is possible with RDE please follow the steps given in this document; How to use Rapid Development Environment | Adobe Experience Manager

Rapid Development Environment is going to make the developer life easy and this could be use by a developer at a time. Multiple developers could also use but that required very frequent sync between developers code. The biggest advantage of rapid development environment is that; we now use a full AEM as cloud service instance as a local. Where one can make the changes and deploy the code on cloud service without commit, and running the cloud manager CICD pipeline which taking approximately 40 minutes to make our code live on any AEM CS instance. 

References

How to use Rapid Development Environment | Adobe Experience Manager

How to set up Rapid Development Environment | Adobe Experience Manager

Package contains application content which isn't supported at runtime

Problem statement

Error while uploading the package in AMasCS; Package (or it's subpackage(s)) contains application content which isn't supported at runtime.

Possible reason

The package which you are trying to upload is not allowed. If that is your project code package, please use the cloud manager pipeline to build and deploy the code to AEMasCS env.

AEM as Cloud Service does not support custom runmode config

Adobe Experience Manager as Cloud Service (AEM as CS) doesn't support custom run mode configuration. The supported runmode configurations are:

• config (The default, applies to all AEM Services)
• config.author (Applies to all AEM Author service)
• config.author.dev (Applies to AEM Dev Author service)
• config.author.stage (Applies to AEM Staging Author service)
• config.author.prod (Applies to AEM Production Author service)
• config.publish (Applies to AEM Publish service)
• config.publish.dev (Applies to AEM Dev Publish service)
• config.publish.stage (Applies to AEM Staging Publish service)
• config.publish.prod (Applies to AEM Production Publish service)
• config.dev (Applies to AEM Dev services)
• config.stage (Applies to AEM Staging services)
• config.prod (Applies to AEM Production services)

AEM Environment Variables | AEM as Cloud Service

The Adobe I/O CLI plays an integral role in development on AEM as a Cloud Service as it provides developers the ability to manage Cloud Manager environment & pipeline variables from the CLI

Pipeline Variables

Your build process may depend upon specific configuration variables which would be inappropriate to place in the git repository or you may need to vary them between pipeline executions using the same branch.

Cloud Manager allows for these variables to be configured through the Cloud Manager API or Cloud Manager CLI on a per-pipeline basis. Variables may be stored as either plain text or encrypted at rest. In either case, variables are made available inside the build environment as an environment variable which can then be referenced from inside the pom.xml file or other build scripts.

Uses example

• Used to vary behavior of build process
• Accessible inside the build process
• Dev minification is set differently on Dev vs Stage or Prod
• Disable caching on Dev

Standard Environment Variables

Changing application behavior based on standard environment variables

Uses example:

• Provided to the runtime environment
• Used in OSGi configuration
• Store passwords outside of version control, instead use a reference.
• Connect your AEM application with different external endpoints

Types of environment variables

1. Inline values. e.g. { "keyName" : "jorvee" }
2. Environment specific values. e.g. { "endpoint" : "$[env:JORVEE_ENDPOINT]" }
3. Environment secrets. e.g. { "authToken" : "$[secret:J_AUTH_TOKEN]" }

Variable naming conventions

• Variable names must observe the following conventions.
• Variables may only contain alphanumeric characters and the underscore (_).
• The names should be all upper-case.
• There is a limit of 200 variables per pipeline.
• Each name must be less than 100 characters.
• Each string variable value must be less than 2048 characters.
• Each secretString type variable value must be less than 500 characters.

References:

•  AEM environment variables

AEM as cloud service, /apps and /libs directories are in ready only mode

AEM cloud service makes the out of the box and custom codes immutable. Once we deployed the code in AEM server, we will not be able to modify or create any content or node under the /apps and /libs directories using CRXDE Lite. When we try to do so, then it will throw an error "Could not save changes. Received 500 () for saving changes in workspace crx.default. Unknown error (Error Code: 500) OR Could not save changes. Received 409 () for saving changes in workspace crx.default. org.apache.jackrabbit.oak.spi.state.ReadyOnlyBuilderException: This builder is read-only.". Below is the screenshot, when we tried creating a folder "myProject" under /apps folder.

The only way to change the code is go for a fresh build and deploy the code. You may read more about mutable and immutable concept and could service project structure in our previous post Package shouldn't contain mutable and Immutable content. [https://rashidjorvee.blogspot.com/2020/07/aem-cloud-service-ImmutableMutableMixedPackage.html]

Hope this helps you!

References:

1. AEM as cloud service archetype
2. How aem as a cloud service scales?