I've added a new field to a component dialog used across ~500 pages in our AEM instance.
Issue:
New field appears correctly on newly created pages
For existing pages, field only appears after reopening/closing the dialog
Manually reauthoring 500+ pages isn't feasible. Need efficient solution to add this property to all existing component instances without manual intervention.
Looking for an out-of-the-box AEM solution or existing feature that can handle this dialog property update without extensive scripting. Prefer a configuration-based approach if available.
Environment:
AEM version: 6.5
Has anyone solved this problem at scale? Sample scripts would be appreciated!
Solved! Go to Solution.
Topics help categorize Community content and increase your ability to discover relevant content.
Views
Replies
Total Likes
Hi @sai_charanAr,
Before jumping to the conclusion that you need to make changes to the content, I would like to understand the reason why you don't see your new property in the dialog? It is a very common scenario to add new fields to existing dialogs. This, for sure, needs to work if you are using the same resource type. It should be enough to just provide a default value for old content where the value is not defined.
Secondly, a personal opinion, I don't like to install 3rd party packages on Production as they often cause issues later when we update to new versions. Therefore, I don't use Groovy or even ACS Commons. Everything you can achieve with the Groovy console can easily be done using the available HTTP APIs like SlingPostServlet and a bit of custom scripting in Node.js or Python.
Good luck,
Daniel
Hi @sai_charanAr,
I think the easiest and most effective option is to use Groovy console.
Below is sample script create for we.retail but it can be changed for your purposes:
import javax.jcr.query.Query
import org.apache.sling.api.resource.ModifiableValueMap
def DRY_RUN = true
def QUERY = """SELECT * FROM [nt:unstructured] AS s WHERE ISDESCENDANTNODE([/content/we-retail])
AND s.[sling:resourceType] = "weretail/components/content/heroimage"
AND s.[newProp] IS NULL"""
resourceResolver.findResources(QUERY, Query.JCR_SQL2)?.each { resource ->
def valueMap = resource?.adaptTo(ModifiableValueMap)
if (valueMap) {
valueMap.put("newProp", "newPropValue")
println "Component ${resource.path} has been updated"
if (!DRY_RUN) {
resourceResolver.commit()
}
}
}
You can DRY_RUN flag value to control if changes will be saved or not.
Hi @lukasz-m , Thanks for your quick response , is this approach recommended for prod environment?
Views
Replies
Total Likes
I would say yes. With one important note. You should run script on author only, and next propagate changes from author to publish via publication. Publication can also be run from script as well.
In general as you may see in Groovy Console documentation due to some security issues it should not be used on prod publish.
Hi @sai_charanAr ,
Try below solution:
Groovy Console (Author-only)
The most effective and safe way—without manual editing or full republishing—is to use the AEM Groovy Console on Author to update the JCR nodes programmatically.
Sample Groovy Script
Adjust the following script to your specific paths, component type, and field name:
import javax.jcr.query.Query
import org.apache.sling.api.resource.ModifiableValueMap
def DRY_RUN = true
def QUERY = """
SELECT * FROM [nt:unstructured] AS s
WHERE ISDESCENDANTNODE([/content/your-site-path])
AND s.[sling:resourceType] = 'your/components/mycomponent'
AND s.[newField] IS NULL
"""
resourceResolver.findResources(QUERY, Query.JCR_SQL2)?.each { resource ->
def valueMap = resource?.adaptTo(ModifiableValueMap)
if (valueMap) {
valueMap.put("newField", "defaultValue")
println "Updated: ${resource.path}"
if (!DRY_RUN) {
resourceResolver.commit()
}
}
}
Note:
- Run this on Author only
- Never run Groovy Console on Publish
- Use DRY_RUN = true first to preview the paths
- After verification, set DRY_RUN = false and commit
- Use Manage Publication to push updates to Publish
Why Not Just Configuration?
Unfortunately, AEM doesn’t provide an out-of-the-box config-only way to backfill dialog field values on existing nodes. Dialog fields reflect persisted properties—so if the field wasn’t authored before, it won’t appear unless either:
- The dialog definition includes a defaultValue (shown but not persisted), or
- The value is saved to JCR explicitly (e.g., via this script)
Regards,
Amit
Views
Replies
Total Likes
Hi @sai_charanAr,
Before jumping to the conclusion that you need to make changes to the content, I would like to understand the reason why you don't see your new property in the dialog? It is a very common scenario to add new fields to existing dialogs. This, for sure, needs to work if you are using the same resource type. It should be enough to just provide a default value for old content where the value is not defined.
Secondly, a personal opinion, I don't like to install 3rd party packages on Production as they often cause issues later when we update to new versions. Therefore, I don't use Groovy or even ACS Commons. Everything you can achieve with the Groovy console can easily be done using the available HTTP APIs like SlingPostServlet and a bit of custom scripting in Node.js or Python.
Good luck,
Daniel
@sai_charanAr Just checking in — were you able to resolve your issue?
We’d love to hear how things worked out. If the suggestions above helped, marking a response as correct can guide others with similar questions. And if you found another solution, feel free to share it — your insights could really benefit the community. Thanks again for being part of the conversation!
Views
Replies
Total Likes
Views
Likes
Replies
Views
Likes
Replies