Expand my Community achievements bar.

Don’t miss the AEM Skill Exchange in SF on Nov 14—hear from industry leaders, learn best practices, and enhance your AEM strategy with practical tips.
SOLVED

Migrating to Cloud Manager (with AMS) what to do with /etc

Avatar

Level 7

hi guys,

I'm doing  the above migration (we have 6.5)  and I have moved the /etc/clientlibs to the ui.apps as required.

 

I have a bunch of other custom stuff in a directory called /etc/<our site> 

These are some "Pages" that contain configuration used by some of our components i.e. not ordinary pages for Editors to use. Also some files used by the robots/sitemap etc

 

My question is :

Is it o.k. to leave them in /etc/ ?   I know that Adobe seems to be encouraging people to stop making /etc a catch-all place for random stuff.

 

I don't want to move them to /content because they mess up the sites page.

 

Any ideas?

 

Thanks

Fiona

 

 

1 Accepted Solution

Avatar

Correct answer by
Community Advisor

Try keeping them under apps/urproject folder.

View solution in original post

12 Replies

Avatar

Community Advisor

@fionas76543059 i think it is ok to keep stuff in /etc untill they are identified by Adobe to be moved to a different location such as clientlibs, designs to /apps, workflows to /conf etc.

Avatar

Level 7
Thanks for your swift response ! Ankur sugged to put them under apps so I'll try that.

Avatar

Correct answer by
Community Advisor

Try keeping them under apps/urproject folder.

Avatar

Level 4

For customers with existing code bases, it is critical to go through the repository restructuring exercise described in AEM documentation to ensure that content formerly under the /etc is moved to the right location.

https://experienceleague.adobe.com/docs/experience-manager-cloud-service/implementing/deploying/over...

 

-Praveen

Avatar

Employee Advisor

Hi,

I would not move stuff to /apps, because that's normally read-only and not writeable (except for administrator group by default); in AEM as a Cloud Service it's not writable at all during runtime.

If your configuration is supposed to be changed during runtime I would store it either in /content or /conf.

Avatar

Employee Advisor
We tried moving the component design dialog stuff to /conf but it didn't work. We have not yet migrated to editable templates yet and therefore we will have to continue with the design dialogs. Also, if we keep the design in /etc then how we can activate the design as there is no miscadmin UI and I could not find any Touch UI equivalent.

Avatar

Level 7
Thanks Jorg. In fact, we don't change them during runtime. Mostly they are internal lists and a few email templates, robot files etc. and a page of "paths" - servlet resource type mappings. Maybe it was originally thought that they would be changed on-the-fly. They all have primary types cqPaths, but don't really render. I will try putting them in /apps and see how I get on.!

Avatar

Level 7
Hi Kunal, We also don't have editable templates. In the JCR, they are stored in /etc/designs. However we don't have them in the source code as the end customers can change them. (via the Design mode in the pages.)

Avatar

Level 7
Hi Kunal, Just to clarify, I mean the designs are stored in /etc/designs and they are not kept in our code base/source control

Avatar

Level 7
hi folks, I moved some stuff from /etc/ to /conf. It is a "Page" with nodes of resourceType of various servlets. However, although the servlets are called fine in Author, in publish there are 404s.

Avatar

Level 7
I added the /conf/... path to SlingAuthenticator sling.auth.requirements parameter with a "-" in front . Didn't seem to help though.

Avatar

Level 7
If I explicitly give read permission to anonymous to the page in /conf, it does seem to work. I am not sure how the SlingAuthenticator fits in, I'll try throwing it away and see if makes a difference.