What is the best way to remove/add/modify node struct...

[karthik4]

My AEM platform contains 3 websites of which contains lots of content. I need to remove/add/modify content nodes in production without affecting content authors and their daily tasks. What is the best practice and best way to remove/add/modify content nodes without affecting production content authors? How should I test this and go live?

[Vish_dhaliwal]

I believe you can update the content on Stage/dev and then install the packages on production. That way, you can also test the pages before going live.

[karthik4]

Say what happens if I only want to add a mixinType for 30 pages. How would we achieve this?

[VeenaVikraman]

@karthik4 I don't think and won't recommend content editing or any node manipulation directly in PROD. I don't think it is a best practice to start with. As @Vish_dhaliwal mentioned , it would be better to do the same in lower region , test and install the package back to PROD. 

From your question I am not clear how are you planning to remove/add/modify the content. Even if it is manually or programmatically, always do it in lower regions.

[karthik4]

for example, a simple task to add the "mixinType" property for 30 pages for each live website (3 websites). The website cannot be idle for too long.

What is the best way to achieve this?

Is it best to stop content authoring, download content, make changes, install new content package?

OR, should I run a servlet to add mixinType, then re-publish all the pages?

Please advise. By the time we download 30 pages (from each site, so 90 pages), moments later during development, some pages may be updated. Re-uploading a content package into AEM will show old content.

[VeenaVikraman]

Okay. Got your point. Like you want to add a particular property to say 100 pages. Something we used to do in one of our project is to write a script using Fiddle ( btw it is a utility provided by ACS Commons check here) and run it in the author directly. We never used to do this directly in PROD for sure. As usual local-> DEV->QA-> STAGE (mostly stage is our pre prod content). And content used to be backed up from STAGE to PROD for scenarios like this. But if you want to run it in PROD , make sure the script is 100% error free and won't crash anything with proper testing in lower regions. Do keep a copy of your content before doing any change directly in PROD. 

[karthik4]

Thank you for replying. Is there another way for me to do this that is not that risky? Is this the best less risky to add mixinType to nodes?

1. 1. Alert content authors to stop authoring.
2. 2. Create new content package in production-live, as mixinType-to-add.1.0.0.zip
3. 3. Download mixinType-to-add.1.0.0.zip.
4. 4. on desktop, mixinType-to-add.1.0.0.zip to unzip.
5. 5. add all changes to node in Local AEM using ACS Commons Tool.
6. 6. Export ZIP with version mixinType-to-add.1.0.1.zip ffrom Local AEM.
7. 7. ZIP the package.
8. 8. upload &install mixinType-to-add.1.0.1.zip to QA for testing.
9. 9. upload &install mixinType-to-add.1.0.1.zip to Stage for testing.
10. 10. upload & install mixinType-to-add.1.0.1.zip to Production & Replicate.
11. 11. Total 2 hours.

[VeenaVikraman]

Do you have ACS Commons Tool installed in your DEV , QA , STAGE ? We had the same and so it was easy for me to run the script directly in these env

[karthik4]

What ACS Commons Tool are you speaking about? and what's the best way to add "mixinType"? Can you please provide me with your procedure to add "mixinType" to many nodes in AEM content?

[VeenaVikraman]

You can find the ACS commons tool I was mentioning in https://adobe-consulting-services.github.io/acs-aem-tools/features/aem-fiddle/index.html . It is basically a utility provided by Adobe Consulting Services. If you install this in your AEM server , you actually don't need to stop or install bundles for running a script or servlet.

[Theo_Pendle · Accepted solution]

Hi @karthik4 ,

I am going through this right now actually as we are doing an upgrade from 6.3 -> 6.5 and EVERYTHING is changing (using Core Components, upgrading to Editable templates, changing all our front-en, etc). This means that almost every node under /content is going to be transformed one way or another.

We have several environments of which PROD and UAT (one below PROD, also known as "staging"). The way we are performing the modifications is that we've developed a separate project called JCR Patcher which (as the name suggests) will traverse the JCR and patch every node that needs it At the moment it is triggered via servlet, but it could also be done via command-line.

The plan is this: 

1. Copy all content from PROD to UAT
2. Run JCR Patcher in UAT, test, get validation that all is okay.
3. Content freeze (authors stop working)
4. Copy all content from PROD to UAT (again, to get the delta, as step 2 will take weeks to validate)
5. Patch PROD
6. Validate
7. Publish
8. Un-freeze, authors can continue working on their new, patched content  

The idea it to do as much testing in UAT as possible so that we can patch in PROD with high confidence. This way, step 6 (validation in PROD) is really just a "sanity check" that can be done in one or two days.

In your case, if you're only patching 30 pages (which is a matter of seconds), you wouldn't need a content freeze. You could do all your tests in your UAT environment and the schedule the patching at night. 

[karthik4]

Patch PROD, are you calling the patch servlet from PROD?

[karthik4]

5. Patch PROD, are you calling the patch servlet from PROD?

[karthik4]

5. Patch PROD, are you calling the patch servlet on PROD? What happens if I have two PROD authors?