Your achievements

Level 1

0% to

Level 2

Tip /
Sign in

Sign in to Community

to gain points, level up, and earn exciting badges like the new
Bedrock Mission!

Learn more

View all

Sign in to view all badges

SOLVED

How can I change content instances in batch?

Avatar

Level 1

Hi everyone!

I needed to change a component and one of its properties in dialog is a select box and I have a lot of instances of this component on my site. Now I'm needing to change all content value of this component, example, "if value old option 1 change to value old option 2"

 

I'm trying to figure out a smart solution instead of creating a package for almost all my site, change the values and upload again...

I found the ACS On-Deploy Scripts, but it is not compatible with Cloud Service, that is my case.

https://adobe-consulting-services.github.io/acs-aem-commons/features/on-deploy-scripts/index.html

 

Do you know some smart solution that I can do in batch or some like this?

1 Accepted Solution

Avatar

Correct answer by
Community Advisor

I did almost similar exercise using groovy script.

 

Steps are given below -

 

1. You need to create a groovy to identify list of pages where you have used that particular component with that old value. In that groovy script you can use a JCR SQL2 query just like the below one -

 

SELECT * FROM [nt:unstructured] AS s WHERE ISDESCENDANTNODE([/content/we-retail]) and [sling:resourceType] = 'weretail/components/content/heroimage' and [fileReference] = '/content/dam/we-retail/en/experiences/wester-australia-by-camper-van/camping-in-western-australia.jpg'

 

Just imagine you want to identify list of pages with heroimage component instance with a specific value against that property.

 

You can consider this as a dry run process to identify list of pages or generate a report with list of pages and share the same with business for their review and approval [I did the same thing].

 

2. I would request to please execute the dry run on author and publish instance separately. Sometimes authors do authoring on pages but save few pages as draft [it means they will activate or publish it later].

 This dry run will help identify the difference on count between author and publish.

3. Then I add add a logic to replace the old value with new value in the same script.

4. Please don't add the logic to replicate pages from author after updating the all content value of that component. Rather execute the script on author and publish instances individually.

This won't publish the draft pages and avoid the replication queue getting piled up also.

5. To expedite the process you can create a custom index associated with that component property as we are using query mentioned in step-1.

View solution in original post

1 Reply

Avatar

Correct answer by
Community Advisor

I did almost similar exercise using groovy script.

 

Steps are given below -

 

1. You need to create a groovy to identify list of pages where you have used that particular component with that old value. In that groovy script you can use a JCR SQL2 query just like the below one -

 

SELECT * FROM [nt:unstructured] AS s WHERE ISDESCENDANTNODE([/content/we-retail]) and [sling:resourceType] = 'weretail/components/content/heroimage' and [fileReference] = '/content/dam/we-retail/en/experiences/wester-australia-by-camper-van/camping-in-western-australia.jpg'

 

Just imagine you want to identify list of pages with heroimage component instance with a specific value against that property.

 

You can consider this as a dry run process to identify list of pages or generate a report with list of pages and share the same with business for their review and approval [I did the same thing].

 

2. I would request to please execute the dry run on author and publish instance separately. Sometimes authors do authoring on pages but save few pages as draft [it means they will activate or publish it later].

 This dry run will help identify the difference on count between author and publish.

3. Then I add add a logic to replace the old value with new value in the same script.

4. Please don't add the logic to replicate pages from author after updating the all content value of that component. Rather execute the script on author and publish instances individually.

This won't publish the draft pages and avoid the replication queue getting piled up also.

5. To expedite the process you can create a custom index associated with that component property as we are using query mentioned in step-1.