Du får vist hjælpeindhold for version:

Introduction

Prior to AEM 6.4, customer code was deployed in unpredictable areas of the JCR that were subject to change on upgrades. Because of this, it was common for formal AEM releases (Major Versions, Feature Packs, Service Packs or Hotfixes) to overwrite custom code, configuration or content. In addition, customer changes sometimes overwrote AEM product code or content, breaking product functionality.

These conflicts were not always auto-resolvable, requiring significant processing time to flag, and required human intervention to resolve, the resolution of which was not always clear. By clearly delineating hierarchies for AEM product code and customer code, these conflicts can be avoided. 

To that end, beginning in AEM 6.4 and to be continued in future releases, content is being restructured out of /etc to other folders in the repository, along with guidelines on what content goes where, adhering to the following high-level rules:

  • AEM product code will always be placed in /libs, which must not be overwritten by custom code
  • Custom code should be placed in /apps, /content, and /conf

This article is organized into three sections, representing the type of content that has been moved out of /etc:

  1. Configuration
  2. Client-Side Libraries
  3. Miscellaneous

Each section includes:

  • a table with the restructured locations and additional context. In the near future, it is expected that the tables will be formatted into a flatter structure for improved readability.
  • an extensibility strategy allowing custom code to successfully extend AEM application code residing under /libs.

Backwards Compatibility

In most cases, backwards compatibility to the old locations is maintained after upgrading to AEM 6.4. This is achieved by the old locations being preserved and respected by product code, in addition to the new locations being added. In most cases, conditional logic is used to check if the legacy folder exists and to read content from there instead of the new location.

On their own timeline after the 6.4 upgrade, customers are encouraged to remove the old locations so content in the new locations is used. The tables below includes instructions to adhere to the new content structure per-location.

Bemærk:

An in-place upgraded instance will include old content locations in addition to the new locations. A fresh developer install will only include the new locations.

How to Read the Tables

The table in each section includes:
  • the AEM solution (Sites, Assets, Forms, etc) for which this content is relevant
  • the old (6.3 and earlier) location
  • the new 6.4 location
  • Instructions to align with the new content structure. For example, it may be necessary to execute a script or to move files manually in the weeks or months after a 6.4 upgrade
  • The approach that AEM has used to maintain backwards compatibility of old content locations for customers upgrading to AEM 6.4 from a previous version

Configuration

The content locations in this section generally refer to content that resides under a /settings folder under /libs, /apps, or /conf.

Extensibility Strategy

In general, but with a few exceptions, content under this section can be extended using Apache Sling's Context Aware Configuration feature.

In a nutshell, Context Aware Configuration allows content in one part of the repository to be overlayed multiple times by content in other parts of the repository. For example, content in /libs can be overlayed by content in /apps, which can then be overlayed by content in /conf. Moreover, content in a global folder under /conf can be overlayed by a specific "tenant" or "site" (e.g. /conf/we-retail/settings). 

Typically, Context Aware Configuration is used as a strategy for extending feature configurations, but there are cases where it's used by other content types.

The table below includes an additional column named "Configuration Type" to explain the extent to which a configuraiton can be overlayed. Here is additional detail on these configuration types:

not context-aware

  • Resources happen to be in context-aware folder structures (like /libs/settings) but always referenced via absolute path so context awareness is not in effect.
  • Resources could be anywhere. For example, Assets DRM Licenses could be at /content/my-customer/licenses/creative-commons.html
  • Examples:
    • Workflow scripts -> /apps/settings/workflow/scripts/noop.ecma
    • Assets DRM Licenses -> /apps/settings/dam/drm/my-license

only global

  • Feature with only Global Configuration
  • As a reference point, take the precedence of settings in this example: /libs/settings < /apps/settings < /conf/global
  • AEM supports only global configuration, and not tenant-ized configurations
  • AEM will always begin to look up configurations at the /conf/global level first
  • Examples:
    • Workflow Launchers -> /libs/settings/workflow/launcher
    • Workflow Models -> /conf/global/settings/workflow/models

tenant-aware

  • For tenant-aware configurations, see this example for the precedence of configuration paths: /libs/settings < /apps/settings < /conf/global < /conf/we-retail, where we-retail is the tenant name. Tenant-aware configurations also support sub-tenants.
  • AEM supports tenantized configurations. It respects cq:conf property on hierarchy
  • Examples:
    • Editable Templates -> /conf/we-retail/settings/wcm/templates
    • Cloud Configs -> /conf/we-retail/settings/cloudsettings
Solution Previous Location
New Location Context Aware Configuration Type
Backward Compatibility Approach Requirements to align to latest model
AEM Sites / AEM Forms

/etc/cloudservices/typekit

/etc/cloudservices/recaptcha

/etc/cloudservices/echosign

/conf/<tenant>/settings/cloudconfigs/typekit

/conf/<tenant>/settings/cloudconfigs/recaptcha

/conf/<tenant>/settings/cloudconfigs/echosign

tenant-aware

Legacy cloudservices.

Persisted on an in-place upgrade. Code to list and read them still present in AEM as a fallback.

Lazy content migration utility can be triggered by Forms Migration UI, in order to automatically convert to the new path.
AEM Forms /etc/cloudservices/fdm /conf/<tenant>/settings/cloudconfigs/fdm tenant-aware

Legacy cloudservices.

Persisted on an in-place upgraded setup. Code to list and read them still present in AEM as a fallback.

Lazy content migration utility can be triggered by Forms Migration UI, in order to automatically convert to the new path.
AEM Assets /etc/dam/adhocassetshare /libs/settings/dam/adhocassetshare tenant-aware Legacy content structures are honored with a higher priority than new, OOTB ones. Project level customizations need to be cut and pasted into the equivalent /apps or /conf paths as applicable.
AEM Assets /etc/dam/workflow/notification/email/downloadasset /libs/settings/dam/workflow tenant-aware Legacy content structures are honored with a higher priority than new, OOTB ones. Project level customizations need to be cut and pasted into the equivalent /apps or /conf paths as applicable.
AEM Assets /etc/dam/drm/licenses/ /libs/settings/dam/drm not context-aware Legacy content structures are honored with a higher priority than new, OOTB ones. Project level customizations need to be cut and pasted into the equivalent /apps or /conf paths as applicable.
AEM Assets /etc/dam/indesign/scripts /libs/settings/dam/indesign tenant-aware Legacy content structures are honored with a higher priority than new, OOTB ones.

Project level customizations need to be cut and pasted under the equivalent /apps or /conf paths as applicable.

When running customized Asset Ingestion workflow, references to the old location in /etc would still exist in the Media Extraction Process Configuration. Along with moving the scripts out of /etc to the equivalent /apps and /conf paths, customized Media Extraction process arguments need to be changed from absolute to relative paths, to accommodate for the changes.

For more info, see this page.

 

AEM Assets /etc/dam/video /libs/settings/dam/video tenant-aware Legacy content structures are honored with a higher priority than new, out of the box ones. Project level customizations need to be cut and pasted into the equivalent /apps or /conf paths as applicable.
All /etc/notification/email/default /libs/settings/dam/notification tenant-aware Legacy content structures are honored with a higher priority than new, out of the box ones. Project level customizations need to be cut and pasted into the equivalent /apps or /conf paths as applicable.
AEM Sites / AEM Assets /etc/designs
/libs/settings/wcm/designs not context-aware

Consuming Services are aware of old location.

Configurations from the legacy location are considered


Move custom content from /etc/design to /apps/settings/wcm/design for alignment with the new repository structure. In the future, consider upgrading your sites to use editable templates functionality, which replaces the need for design mode and thus this content.
AEM Sites /etc/scaffolding

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

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

not contex-aware The components in the old location under /etc/scaffolding will continue to function, but have been deprecated. Adobe recommends you use the new scaffold components under the new location.
AEM Sites /etc/blueprints

/libs/msm for out of the box Screens and Commerce blueprint configurations

 

not context-aware

Consuming Services are aware of the old location.

Configurations from the legacy location are considered.

The configurations need to be copied over to the new locations.
AEM Sites /etc/mobile /libs/settings/mobile tenant-aware The feature leverages the Configuration Manager and still supports the old location as fallback.
  1. Relocate the configurations from /etc to /conf/<tenant>/settings/mobile
  2. Then, update the reference in the content as follows:

/content/<tenant>/jcr:content/cq:deviceGroups{String[]}=mobile/groups/responsive

AEM Sites /etc/msm/rolloutConfigs /libs/msm/wcm/rolloutconfigs N/A

Consuming services are aware of the old location.

If configurations are detected in the legacy location, they will be used.

To align with the new model, configurations need to be created in the new locations, and the old ones under /etc must be deleted.
AEM Sites /etc/segmentation/contexthub /conf/we-retail/settings/wcm/segments tenant-aware

Segments from the old location:

  • Remain in read-only mode in audience console.
  • Still loaded on the page (if the given path is selected in Page Properties > Personalization > Segments Path).
  • Can be used for content targetting.
You can use the Segments Migration Tool to migrate to the new location.
AEM Communities /etc/social/config/languageOpts /libs/social/translation/languageOpts N/A    
AEM Communities /etc/community/templates /libs/settings/community/templates  

The code is aware of the location of the old template. Existing templates will continue to be referred and read/write from /etc.


For e-mail templates, if the customer was already having his custom templates at another path by configuring Templates root path in AEM Communities Email Reply Configuration then it would stay as it is.

A migration utility can align to the latest AEM Communities templates model.

AEM Communities /etc/community/badging

Badge Rules:

/libs/settings/community/badging

Badge Images:

The out of the box images in the old location at /etc/community/badging/images are moved to /libs/community/badging/images  

 

Custom images are moved to /content/community/badging/images.

 

tenant-aware

The code is aware of the old badging paths.


It will check the existence of older paths
first. If they are not present, it will use the new paths.

Manual Migration is required in order to align to the latest model. Follow the steps below in order to achieve this:

  1. Create a site context bucket using the configuration browser under Tools
  2. Go to the site root
  3. Set the cq:conf property to the bucket path where you want to store all the configurations. The same can be set via the Site Edit Wizard - Set Cloud Config Input, and then saving the changes
  4. Move the relevant badging rules and scoring rules from etc/community/* to the site context bucket created in the previous step
  5. Adjust the badgingRules and scoringRules properties on the site root to have relative references to the new rule locations. As an example, if cq:conf is set to /conf/we-retail, the value for badgingRules  will be community/badging/rules if rules are now moved to this new bucket
  6. Similarly, adjust the references to scoring rules in a badging rule node to have a relative path.
AEM Sites

/etc/cloudservices/facebookconnect

/etc/cloudservices/twitterconnect

/etc/cloudservices/pinterestconnect

/conf/<tenant>/settings/cloudconfigs/facebookconnect

/conf/<tenant>/settings/cloudconfigs/twitterconnect

/conf/<tenant>/settings/cloudconfigs/pinterestconnect

tenant-aware    
AEM Communities /etc/community/scoring /libs/settings/community/scoring  

The code is aware of the old badging paths.


It will check the existence of older paths
first. If they are not present, it will use the new paths.

Manual migration steps are required to align with the latest model.

The steps are the same in the badging rules above.

AEM Communities /etc/community/notifications /libs/settings/community/notifications not context-aware

These configurations are not backward compatible. See the "Requirements to align to the latest model" column for steps on how to migrate to the new locations.


A manual migration is required to align to the latest model. You can use the Granite Configuration Manager to move the configurations to the new path under /apps/settings.

Therefore, you need to set the mergeList property to true on the /libs/settings/community/subscriptions node and then add an nt:unstructured child node.

AEM Communities /etc/community/subscriptions /libs/settings/community/subscriptions not context-aware These configurations are not backward compatible. See the "Requirements to align to the latest model" column for steps on how to migrate to the new locations.

A manual migration is required to align to the latest model. You can use the Granite Configuration Manager to move the configurations to the new path under /apps/settings.

Therefore, you need to set the mergeList property to true on the /libs/settings/community/subscriptions node and then add an nt:unstructured child node.

AEM Communities /etc/socialconfig/srpc/defaultconfiguration /conf/global/settings/community/srpc/defaultconfiguration global These configurations are backwards compatible. If the old paths are detected they will be used. Otherwise, the new paths will take precedence.

Lazy Content Migration Task is available in the form of CQ64CommunitiesConfigsCleanupTask.

For more info, see the Lazy Migration documentation.

AEM Communities /etc/watchwords /libs/community/watchwords N/A These configurations are backwards compatible. If the old paths are detected they will be used. Otherwise, the new paths will take precedence.

Lazy Content Migration Task is available in the form of CQ64CommunitiesConfigsCleanupTask.

Watchwords will have to be manually moved from /etc/watchwords to /conf/global/settings/community/watchwords.

All /etc/workflow/models

/libs/settings/workflow/models

/conf/global/settings/workflow/models

/var/workflow/models

global

Legacy location is used if present and no configuration exists in /libs or /conf.

When editing OOTB workflow models, context-aware overlays must be created under /conf to allow them to be modifiable.

Package export needs to include the model in /libs or /conf and the runtime model in /var/workflow/models.

Newly created models will be created in the /conf/global/settings location.

Any edits in /etc or /libs require you to explicitly create an override in /conf/global/settings before editing can be done. The Edit button has to be selected, and it will cause the override in /conf to be created and editing allowed.

All /etc/workflow/launcher

/libs/settings/workflow/launcher

/conf/global/settings/workflow/launcher

global Legacy location is used if present and no configuration
exists in /libs or /conf locations. This way, custom launchers are preserved.

Newly created or edited launcher configurations are located in the /conf location.

All launchers should be moved from the legacy /etc location to /conf/global/settings/workflow/launcher.

All /etc/workflow/models

/libs/settings/workflow/models

/conf/global/settings/workflow/models

global Legacy location is used if present and no configuration
exists in /libs or /conf locations. This way, custom workflow models are preserved.

All workflow models should be moved from the legacy /etc location to /conf/global/settings/workflow/models.

 

All /etc/workflow/notification

/libs/settings/workflow/notification

/conf/global/settings/workflow/notification

not context-aware

For backwards compatibility, the legacy location is used if present.

Previously, out of the box templates had to be overridden by editing them in /etc. Now, override should be stored in /conf/global.

For more info, please consult the Workflow documentation.
All /etc/cloudservices/translation

/libs/settings/cloudconfigs/translation/translationcfg

/conf/<tenant>/settings/cloudconfigs/translation/translationcfg

 

tenant-aware Legacy cloudservices. Will be persisted on an in-place upgraded set up. Code to list them and read them is still present in the product as a fallback.

In order to move cloud configurations to /conf, you can either:

  • Create configurations using the new Touch UI
    or
  • Copy the configurations from /etc/cloudservices/translation to their respective new location(s)

Once this is done, the configurations need to be associated with Sites via Sites → Properties in the user interface.

Note: Translation connectors must be compatible with AEM 6.4 for this to work.

All /etc/cloudservices/msft-translation

/libs/settings/cloudconfigs/translation/msft-translation

/conf/<tenant>/settings/cloudconfigs/translation/msft-translation

tenant-aware Legacy cloudservices. Will be persisted on an in-place upgraded set up. Code to list them and read them is still present in the product as a fallback.

In order to move cloud configurations to /conf, you can either:

  • Create configurations using the new Touch UI or
  • Copy older configurations from /etc/cloudservices/translation to their respective new location(s)

Once this is done, the configurations need to be associated with Sites via Sites → Properties in the user interface.

All /etc/cloudsettings

/libs/settings/cloudsettings

/conf/<tenant>/settings/cloudsettings

tenant-aware

Existing entries under /etc remain in place on upgrading the instance.

Accessing the cloud settings UI after the upgrade will copy over the existing cloud settings to the new repository structure while preserving the existing content for backward compatibility.

Content models are the same, only the location has been changed to align with context-aware configurations.

The Lazy Migration task covering these cloud settings will perform the following actions:

  • Copy existing cloud settings in /etc/cloudsettings to /conf/global/settings/cloudsettings
  • Remove all children of /etc/cloudsettings

There are, however, manual steps that are required after the upgrade and before running the lazy migration tasks:

  • All references pointing to /etc/cloudsettings/* need to be updated to point to /conf/global

Caveat:

  • The /etc/cloudsettings container needs to be preserved
AEM Assets /etc/cloudservices/dmscene7 /conf/global/settings/cloudservices/dmscene7 only global

Cloud configuration for Dynamic Media - Scene7 (dynamicmedia_scene7 runmode) setup will stay at the same location. The process is working as is. If you need to adjust the cloud configuration value, then there are two options for doing that:

  1. Update an existing configuration via the old cloud configuration UI.
  2. Create a new cloud configuration via new Touch UI. This will have higher precedence than the old one.

In order to align to the latest model, you need to run the script located at:

  • http://serveraddress:serverport/libs/settings/dam/dm/presets.migratedmcontent.json
AEM Assets /etc/dam/presets/viewer

/libs/settings/dam/dm/presets/viewer

/conf/global/settings/dam/dm/presets/viewer

only global

The OOTB viewer presets will only be available in the new location, while the custom viewer preset will still be under /etc until a modification is incurred.

After it has been modified, it will be saved in the new location via Lazy Migration. The embed image server will look at both the legacy path and the new path upon receiving a request. Therefore, there is no need to change their embed code or URL.

The out of the box viewer preset will only available in the new location. For the custom viewer preset, you need to run the migration script at this location:

  • http://serveraddress:serverport/libs/settings/dam/dm/presets.migratedmcontent.json

Similar to the backward compatibility case, you don't have to adjust the copyURL/embed code to point to /conf. The existing request to /etc will be re-routed under the hood to the correct content from /conf.

AEM Assets /etc/dam/imageserver/macros /conf/global/settings/dam/dm/presets/macro only global The macro under /etc is still valid. If modify it, the modified node will be moved to the new location under /conf via a Lazy Migration task.

You need to run the migration script at this location:

  • http://serveraddress:serverport/libs/settings/dam/dm/presets.migratedmcontent.json

 

AEM Assets /etc/dam/video/dynamicmedia/Adaptive Video Encoding /libs/settings/dam/dm/presets/video/jcr:content/Adaptive Video Encoding N/A

The out of the box video profile will be removed without updating the asset folders property to link to the profile.

The encoding process has built-in translation between the old and new location. It will convert the old path to look into the new profile path.

No changes required.
AEM Assets /etc/dam/video/dynamicmedia /conf/global/settings/dam/dm/presets/video/jcr:content only global

The custom video profile will be kept as is until you modify it.

Then, it will be moved to the new location via a Lazy Migration task. This is similar to the out of the box video preset on encoding look-up. The encoding process has a built-in path translator to look into old location first and then the new location for video profile.

In order to align to the latest model, you can run the migration script under:

  • http://serveraddress:serverport/libs/settings/dam/dm/presets.migratedmcontent.json

 

AEM Assets /etc/cloudservices/dynamicmediaservices /conf/global/settings/dam/dm/cloudservices/dynamicmediaservices only global

This cloud configuration for Dynamic Media hybrid setup (dynamicmedia runmode) will stay at the same location. The process is working as-is. If you need to adjust the config value, you can do it in two ways.

  1. Update an existing config via the old cloud configuration UI.
  2. Create a new cloud configuration via the new touch UI. This will have higher precedence than the old one.

You need to run the migration script in order to align to the latest model. You can find the script at this location:

  • http://serveraddress:serverport/libs/settings/dam/dm/presets.migratedmcontent.json
AEM Assets /etc/cloudservices/youtube /libs/settings/dam/dm/youtube only global

The cloud config for the DM-Youtube setup will stay at the same location. The process is working as-is. If you need to adjust the cloud config value, you can do it in two ways:

  1. Update an existing config via the old cloud config UI.
  2. Create a new cloud config via the new touch UI. This will have higher precedence than the old one.

You can run a migration script to align with the latest model. The script can be found at this location:

http://serveraddress:serverport/libs/settings/dam/dm/presets.migratedmcontent.json

 

 

AEM Assets /etc/dam/presets/analytics /libs/settings/dam/dm/analytics only global No action required.

You can run a migration script to align to the latest mode. The script can be found at this location:

http://serveraddress:serverport/libs/settings/dam/dm/presets.migratedmcontent.json

All

/etc/notification/email/default/com.day.cq.replication

/etc/notification/email/default/com.day.cq.wcm.core.page

/libs/settings/notification-templates only global The templates in /etc/notification/email/default/ are given precedence over the ones in /libs/settings/notification-templates. In order to align to the latest model, you can create new templates under /apps/settings/notification-templates and perform new modifications there.
AEM Sites

/etc/msm/rolloutconfigs/launch

/etc/msm/rolloutconfigs/pushonmodifyshallow

/libs/msm/launches/rolloutconfigs/launch

/libs/msm/launches/rolloutconfigs/pushonmodifyshallow

N/A

Consuming Services are aware of the old location.

If configurations are detected in the legacy location, they will be used.

To align with the new model, configurations need to be created in the new locations, and the old ones under /etc must be deleted.
All /etc/translation/supportedLanguages

/libs/settings/translation/supportedLanguages

/apps/settings/translation/supportedLanguages

not context-aware A caveat is that customized languages need to be added to the list.
Overlay and update the new list with additional languages (if any). Alternatively, copying the old list to /apps location would also work.
All /etc/workflow/models/translation/translation_rules.xml

/libs/settings/translation/rules/translation_rules.xml

/apps/settings/translation/rules/translation_rules.xml

/conf/global/settings/translation/rules/translation_rules.xml

only global Will be persisted on an inplace upgraded set up. Code to list them and read them still present in the product. To persist the changes, copy the XML file from /etc to /libs or /conf. Alternatively, remove file from /etc.

Client-Side Libraries

Client-Side Libraries are javascript and CSS code processed in the browser.

Extensibility Strategy

AEM provides an extensibility framework to append multiple JavaScript files. Any file with the same "categories" property will be appended, allowing custom code to extend AEM code that resides under /libs.

Solution Previous Location

New Location Backward Compatibility Approach Requirements to align to latest model
AEM Forms /etc/clientlibs/fd/fp /libs/fd/fp/components

Legacy clientlib that will be persisted on an instance that has been upgraded via an in-place upgrade.

New clientlibs have the same category names along with the "replaces" property to avoid merging of old and new clientlibs.

No action required.
AEM Forms /etc/clientlibs/fd/rte /libs/fd/rte

Legacy clientlibs that will be persisted on an instance that has been upgraded via an inplace upgrade.

New clientlibs have the same category names along with the "replaces" property to avoid merging of old and new clientlibs.

No action required.
AEM Forms /etc/clientlibs/fd/af /libs/fd/af/authoring/clientlibs Legacy clientlibs. Will be persisted on an instance that has been upgraded via an inplace upgrade. New clientlibs have the same category names along with the "replaces" property to avoid merging of old and new clientlibs. No action required.
AEM Forms /etc/clientlibs/fd/themes/themeLibrary This no longer features as part of the AEM 6.4 out of the box package.

Out of the box themes in Adaptive Forms.

Will be persisted on an inplace upgraded set up.

This is partly user-generated content. This will be delivered as a reference content package with the aem-forms-reference-themes name.
AEM Forms /etc/clientlibs/fd/expeditor /libs/fd/expeditor/clientlibs Legacy clientlibs. Will be persisted on an instance that has been upgraded via an inplace upgrade. New clientlibs have the same category names along with the "replaces" property to avoid merging of old and new clientlibs. No action required.

 

AEM Forms /etc/clientlibs/fd/fmaddon /libs/fd/fmaddon Legacy Analytics and Target clientlibs which are not meant to be directly consumed.  Cleaned up post-upgrade using a cleanup filter.
AEM Assets

/etc/clientlibs/foundation/asseteditor

/etc/clientlibs/foundation/assetshare

/etc/clientlibs/foundation/assetinsights

/libs/dam/clientlibs Legacy clientlibs have different client category names. No action required.
  /etc/clientlibs/ckeditor /libs/clientlibs/ckeditor These are legacy clientlibs. They will be persisted on an inplace upgraded set up. New clientlibs have the same category names along with the "replaces" property to avoid the merging of old and new clientlibs. No action required.
AEM Sites /etc/clientlibs/foundation/sitecatalyst /libs/cq/analytics/clientlibs/analytics

These are legacy clientlibs. Will be persisted on an inplace upgraded set up.

New clientlibs have the same category names.

No action required.
AEM Sites /etc/clientlibs/foundation/personalization /libs/cq/personalization/clientlibs/personalization

These are legacy clientlibs. Will be persisted on an inplace upgraded set up.

New clientlibs have the same category names.

No action required.
AEM Sites /etc/clientlibs/foundation/searchpromote /libs/cq/searchpromote/clientlibs/searchpromote

These are legacy clientlibs. Will be persisted on an inplace upgraded set up.

New clientlibs have the same category names

No action required.
AEM Sites /etc/clientlibs/foundation/target /libs/cq/target/clientlibs/target

These are legacy clientlibs. Will be persisted on an inplace upgraded set up.

New clientlibs have the same category names.

No action required.
AEM Sites /etc/clientlibs/address /libs/cq/address/clientlibs New clientlibs have the same category names. No action required.
AEM Sites /etc/clientlibs/wcm/foundation /libs/wcm/foundation/clientlibs Legacy clientlibs. Will be persisted on an inplace upgraded set up. New clientlibs have the same category names along with the "replaces" property to avoid merging of old and new clientlibs. No action required.
AEM Sites /etc/clientlibs/wcm/foundation/grid/grid_base.less

/libs/wcm/foundation/clientlibs/grid/grid_base.less

On an inplace upgrade the legacy file (/etc/clientlibs/wcm/…_) will remain and not be automatically removed, so references to the legacy /etc/clientlibs/wcm/foundation/grid/grid_base.less will continue to be stasified.

Note that the is is an outlier case where this LESS file is referenced by absolute path via LESS @import statements, and NOT by clientlib category.

If customer LESS referencing the `grid_base.less` is pointing to a non-existing file, the Editable Template Layout mode will break, and any adjustments made with it will not be present (ie. all components will be the full width of the page).

Update any references in custom code (i.e. in any LESS files that reference the moved grid_base.less file) to point to the new location, and remove the legacy location.

These are other restructurings that don't fall under the previous sections.

Extensibility Strategy

See each table row for any supported extensibility model. Content in this section is not typically extended.

Miscellaneous

Solution Previous Location
New Location Backward Compatibility Approach Requirements to align to latest model
AEM Forms /etc/designs/fd/fp /libs/fd/fp

Legacy AEM Forms Portal OOTB templates. These templates will remain in /etc after an in-place upgraded setup.

In the template listing, the word "deprecated" will be added to the template title to differentiate them with the newer templates.

No action required.
AEM Forms /etc/aep /var/fd/content/annotations Legacy Correspondence Management annotation files. Not meant to be directly consumed. Will be cleaned up after upgrade using a cleanup filter. Legacy location cleaned-up post-upgrade using a cleanup filter.
All /etc/tags /content/cq:tags The Tag Manager API supports both the legacy and the new location. When the JCR Tag Manager Factory OSGi Component starts, it detects if it is running on an upgraded instance or a legacy one, and uses the appropriate location.

In order to properly align with the new model:

  1. Replace the references to the old model (/etc/tags) with the new one (/content/cq:tags) by using the tagID.
  2. Log in to CRXDE Lite
  3. Move the tags from /etc/tags to /content/cq:tags
  4. Restart the OSGi Component com.day.cq.tagging.impl.JcrTagManagerFactoryImpl.

 

All /etc/workflow/instances /var/workflow/instances Legacy location used in processing of
in-flight workflows. New workflows use the new location in /var.
No action required.
All /etc/workflow/scripts

/libs/workflow/scripts

/apps/workflow/scripts

Existing Workflow Model Steps that reference workflow scripts in the legacy location at /etc/workflow/scripts will continue to point to these scripts after the upgrade, and execute properly.

Note the AEM UI for authoring the workflow steps’ (Process, Splits, etc.) no longer lists scripts under /etc/workflow/scripts in the drop-down used select to workflow scripts.

Workflows leveraging these scripts will continue to work as expected if the associated workflow process step isn't edited in AEM.

However, for full backward compatibility, including when steps are edited, requires manual action by the customer post-upgrade:

  • The scripts must be moved from /etc/workflow/scripts to /apps/workflow/scripts.
  • Any references to /etc/workflow/scripts in workflow model steps must be updated to reference the new /apps/workflow/scripts location.
All /etc/replication/treeactivation /libs/replication/treeactivation ClassicUI utility page remains in place on upgrade. No action required.
AEM Assets /etc/dam/jobs /var/dam/jobs

Temporary location to hold zip files generated for AEM Assets download action invocation.

There is no need to update since when the client requests to download the asset, It will generate the file in the new location.

No action required.
AEM Commerce /etc/commerce/products /var/commerce/products

The old content remains in place and usable after the upgrade.

A Lazy Migration task is provided for migration to the new location.

The migration is performed via a Lazy Migration task: CQ64CommerceMigrationTask.

It performs the following steps:

  • Adjusts references from the old location to point to the new location
  • Moves content from the old location to new location
  • Removes the old location to eventually activate the usage of the new location in the whole system

The locations covered by the task are:

  • /etc/commerce/products
  • /etc/commerce/collections
  • /etc/commerce/orders
  • /etc/commerce/payment-methods
  • /etc/commerce/shipping-methods

For larger catalogs it's recommended to run the commerce migration task individually by passing the following Java system property to AEM:

  • property name: com.adobe.upgrade.forcemigration
  • property value: com.day.cq.compat.codeupgrade.impl.cq64.CQ64CommerceMigrationTask

After migration AEM requires a restart.

AEM Commerce /etc/commerce/orders /var/commerce/orders

The old content remains in place and usable after the upgrade.

A Lazy Migration task is provided for migration to the new location.

See the description above for /etc/commerce/products.
AEM Commerce /etc/commerce/collections /var/commerce/collections

The old content remains in place and usable after the upgrade.

A Lazy Migration task is provided for migration to the new location.

See the description above for /etc/commerce/products.
AEM Commerce /etc/commerce/classifications /var/commerce/classifications No action required. No action required.
AEM Commerce /etc/commerce/shipping-methods /var/commerce/shipping-methods

The old content remains in place and usable after the upgrade.

A Lazy Migration task is provided for migration to the new location.

See the description above for /etc/commerce/products.
AEM Commerce /etc/commerce/payment-methods /var/commerce/payment-methods

The old content remains in place and usable after the upgrade.

A Lazy Migration task is provided for migration to the new location.

See the description above for /etc/commerce/products.
All /etc/taskmanagement /var/taskmanagement

New tasks are created under /var/taskmanagement

Existing tasks in the legacy location will still visible in the AEM inbox.

No action required.
All /etc/workflow/packages /var/workflow/packages

AEM Packages created through AEM Package Manager are still stored in /etc/workflow/packages.

Other Packages created via AEM Sites and Workflows continue to be stored in/var/workflow/packages.

Packages found in both /etc/workflow/packages and /var/workflow/packages can still be edited via AEM's Package Manager. 

No action required.

 

All /etc/workflow/instances /var/workflow/instances New workflow instances will be created under /var automatically. No action required.
All /etc/commerce/searchpromote /var/cq/searchpromote

New location for Search and Promote feed content.

The old URL continues to work and the request is forwarded by a ServletFilter to the new location.

No action required.

All /etc/dtm-hook /var/cq/dtm/web-hook

New location for DTM Web-Hooks.

The old URL continues to work and the request is forwarded by a ServletFilter to the new location.

No action required.

Dette arbejde har licens under en Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License  Opslag på Twitter™ og Facebook er ikke omfattet af vilkårene for Creative Commons.

Juridiske meddelelser   |   Politik for beskyttelse af personlige oplysninger online