Sites Repository Restructuring in AEM 6.5 sites-repository-restructuring-in-aem

/apps/settings/wcm/segments

/conf/settings/settings/wcm/segments

/conf/<tenant>/settings/wcm/segments

If any new or modified ContextHub Segments are edited in source control rather than being edited in AEM, they must be migrated to the new location:

1. Copy any new or modified ContextHub Segments from the previous location to the appropriate new location (https://experienceleague.adobe.com/%3Ccode%3Eapps%3C/code%3E,%20%3Ccode%3E/conf/global%3C/code%3E%20or%20%3Ccode%3E/conf/<tenant>%3C/code%3E?lang=en)
2. Update references to ContextHub Segments in the previous location to the migrated ContextHub Segments in the new locations (/apps, /conf/global, /conf/<tenant>).

The following QueryBuilder query locates all references to ContextHub Segments in the Previous Locations.

\

\

path=/content property=cq:segments property.operation=like property.value=/etc/segmentation/contexthub/%

\

\

This can be executed via

AEM QueryBuilder Debugger UI

. Note that this is a traversing query, so do not run it against production, and ensure traversal limits adjusted as needed.

ContextHub Segments persisted to the previous location display as read-only in AEM > Personalization > Audiences.

If ContextHub Segments are to be editable in AEM, they must be migrated to the new location (/conf/global or /conf/<tenant>). Any new ContentHub Segments segments created in AEM are persisted to the new location (/conf/global or /conf/<tenant>).

AEM Sites Page Properties only allow either the Previous Location (/etc) or a single new location (/apps, /conf/global or /conf/<tenant>) to be selected, thus ContextHub Segments must be migrated accordingly.

Any unused ContextHub Segments from AEM reference sites can be removed and not migrated to the New Location:

• /etc/segmentation/geometrixx/
• /etc/segmentation/geometrixx-outdoors

Note: If ClientContext is in use, it is recommended to convert to ContextHub.

Any custom use of these Client Libraries should reference the Client Library by category, and not by path:

1. Any references to the Client Library by path at the Previous Location should be updated to use AEM's Client Library referencing framework.

2. If AEM's Client Library referencing framework cannot be used, the absolute path of the Client Libraries can be referenced via AEM's Client Library Proxy servlet.

   • /etc.clientlibs/cq/analytics/clientlibs/sitecatalyst/appmeasurement.js
   • /etc.clientlibs/cq/analytics/clientlibs/sitecatalyst/plugins.js
   • /etc.clientlibs/cq/analytics/clientlibs/sitecatalyst/sitecatalyst.js
   • /etc.clientlibs/cq/analytics/clientlibs/sitecatalyst/tracking.js
   • /etc.clientlibs/cq/analytics/clientlibs/sitecatalyst/util.js

Editing of these Client Libraries was never supported.

To obtain the Client Library categories, visit each cq:ClientLIbraryFolder node via CRXDELite and inspect the categories property.

• /libs/cq/analytics/clientlibs/sitecatalyst/appmeasurement
• /libs/cq/analytics/clientlibs/sitecatalyst/plugins
• /libs/cq/analytics/clientlibs/sitecatalyst/sitecatalyst
• /libs/cq/analytics/clientlibs/sitecatalyst/tracking
• /libs/cq/analytics/clientlibs/sitecatalyst/util

/libs/settings/wcm/designs/wordDesign

/apps/settings/wcm/designs/wordDesign

For any Designs that are managed in SCM, and not written to at run-time via Design Dialogs.

1. Copy the designs from the Previous Location to the New Location (/apps).
2. Convert any CSS, JavaScript and static resources in the Design to a Client Library with allowProxy = true.
3. Update references to the Previous Location in the cq:designPath property.
4. Update any Pages referencing the Previous Location to use the new Client Library category (this requires updating Page implementation code).
5. Update AEM Dispatcher rules to allow serving of Client Libraries via the /etc.clientlibs/ proxy servlet.

For any Designs that NOT managed in SCM, and modified run-time via Design Dialogs:

• Do not move author-able Designs out of /etc.

N/A

/libs/settings/mobile

/apps/settings/mobile

/conf/global/settings/mobile

/conf/<tenant>/settings/mobile

Any new Mobile Device Emulator Configurations must be migrated to the New Location.

1. Copy any new Mobile Device Emulator Configurations from the Previous Location to the new location (/apps, /conf/global, /conf/<tenant>).
2. For any AEM Sites Pages that depend on these Mobile Device Emulator Configurations, update the Page's jcr ``:content node:
   [cq:Page]/jcr:content@cq: deviceGroups = String[ mobile/groups/responsive ]
3. For any Editable Templates that depend on these Mobile Device Emulator Configurations, update the Editable Templates, pointing the cq : deviceGroups to the New Location.

Mobile Device Emulator Configurations resolution occurs in the following order:

1. /conf/<tenant>/settings/mobile
2. /conf/global/settings/mobile
3. /apps/settings/mobile
4. /libs/settings/mobile
5. /etc/mobile

/apps/msm (Customer Blueprint configurations)

/libs/msm (Out Of the Box Blueprint configurations for Screens, Commerce)

Any new or modified Multi-site Manager Blueprint Configurations must be migrated to the New Location (/apps).

1. Copy any new or modified Multi-site Manager Blueprint Configurations from the Previous Location to the New Location (/apps).
2. Remove any migrated Multi-site Manager Blueprint Configurations from the Previous Location.

All AEM provided Multi-site Manager Blueprint Configurations exist in the New Location in /libs.

Content does not reference the Multi-site Manager Blue Configurations therefore there are not content references to adjust.

/libs/msm/wcm/rolloutconfigs

/apps/msm/wcm/rolloutconfigs

Any new or modified Multi-site Manager Rollout Configurations must be migrated to the New Location.

1. Copy any new or modified Multi-site Manager Rollout Configurations from the Previous Location to the new location (/apps).
2. Update any references on AEM Pages to Multi-site Manager Rollout Configurations in the Previous Location, to point to their counterparts in the New Locations (/libs or /apps).

Remove migrated Multi-site Manager Rollout Configurations from the Previous Location.

Failing to remove migrated Multi-site Manager Rollout Configurations from the Previous Location results in duplicate rollout options displayed to AEM authors.

/libs/settings/notification-templates/com.day.cq.wcm.core.page

/apps/settings/notification-templates/com.day.cq.wcm.core.page

The only supported new Page Event Notification E-mail Templates are to support new locales.

Page Event E-mail Template resolution occurs in the following order:

1. /etc/notification/email/default/com.day.cq.wcm.core.page
2. /apps/settings/notification-templates/com.day.cq.wcm.core.page
3. /libs/settings/notification-templates/com.day.cq.wcm.core.page

Any new or modified Page Event Notification E-mail Templates must be migrated to the new location under /apps:

1. Copy any new or modified Page Event Notification E-mail Templates from the Previous Location to the new location (/apps).
2. Remove any migrated Page Event Notification E-mail Templates from the Previous Location.

/libs/settings/ wcm /template-types/scaffolding/scaffolding/apps/settings/ wcm /template-types/scaffolding/scaffolding

Scaffolding created under the Previous Location uses the legacy Scaffolding framework and cannot be migrated to the New Location. To align with the New Location any legacy Scaffolding must be re-developed using the supported Scaffolding framework.

N/A

Any references to the Previous Location in custom LESS files must be updated to import from the New Location.

• Update any referencing custom LESS files that reference grid_base.less in the Previous Location to reference the new location.

Referencing a non-existing grid_base.less file results in the Layout Mode of the Page and Template Editor not working, and a disruption of page layout.

For any Designs that are managed in SCM, and not written to at run-time via Design Dialogs.

1. Copy the designs from the Previous Location to the New Location (/apps).
2. Convert any CSS, JavaScript and static resources in the Design to a Client Library with allowProxy = true.
3. Update references to the Previous Location in the cq:designPath property via AEM > Sites > Custom Site Pages > Page Properties > Advanced Tab > Design Field.
4. Update any Pages referencing the Previous Location to use the new Client Library category (this requires updating Page implementation code).
5. Update AEM Dispatcher rules to allow the serving of Client Libraries via the /etc.clientlibs/ proxy servlet.

For any Designs that NOT managed in SCM, and modified run-time via Design Dialogs:

• Do not move author-able Designs out of /etc.

The recommended approach is to build AEM Sites and Pages using Editable Templates which use Structure Content and Policies in lieu of Designs.

Any custom use of these Client Libraries should reference the Client Library by category, and not by path.

1. Any references to the Client Library by path at the Previous Location should be updated to use AEM's Client Library referencing framework.
2. If AEM's Client Library referencing framework cannot be used, the absolute path of the Client Libraries can be referenced via AEM's Client Library Proxy servlet:

• /etc.clientlibs/cq/testandtarget/clientlibs/testandtarget/testandtarget.js
• /etc.clientlibs/cq/testandtarget/clientlibs/testandtarget/atjs.js
• /etc.clientlibs/cq/testandtarget/clientlibs/testandtarget/atjs-integration.js
• /etc.clientlibs/cq/testandtarget/clientlibs/testandtarget/init.js
• /etc.clientlibs/cq/testandtarget/clientlibs/testandtarget/mbox.js
• /etc.clientlibs/cq/testandtarget/clientlibs/testandtarget/parameters.js
• /etc.clientlibs/cq/testandtarget/clientlibs/testandtarget/util.js

Editing of these Client Libraries was never supported.

To obtain the Client Library categories, visit each cq:ClientLIbraryFolder node via CRXDELite and inspect the categories property:

• /libs/cq/testandtarget/clientlibs/testandtarget/testandtarget
• /libs/cq/testandtarget/clientlibs/testandtarget/atjs
• /libs/cq/testandtarget/clientlibs/testandtarget/atjs-integration
• /libs/cq/testandtarget/clientlibs/testandtarget/init
• /libs/cq/testandtarget/clientlibs/testandtarget/mbox
• /libs/cq/testandtarget/clientlibs/testandtarget/parameters
• /libs/cq/testandtarget/clientlibs/testandtarget/util

Any custom use of these Client Libraries should reference the Client Library by category, and not by path.

1. Any references to the Client Library by path at the Previous Location should be updated to use AEM's Client Library referencing framework.
2. If AEM's Client Library referencing framework cannot be used, the absolute path of the Client Libraries can be referenced via AEM's Client Library Proxy servlet.

• /etc.clientlibs/wcm/foundation/clientlibs/accessibility.css
• /etc.clientlibs/wcm/foundation/clientlibs/main.css
• /etc.clientlibs/wcm/foundation/clientlibs/main.js

Editing of these Client Libraries was never supported.

To obtain the Client Library categories, visit each cq:ClientLIbraryFolder node via CRXDELite and inspect the categories property:

• /libs/wcm/foundation/clientlibs/accessibility
• /libs/wcm/foundation/clientlibs/main