Sie sehen sich Hilfeinhalte der folgenden Version an:

Einführung

In Versionen vor AEM 6.4 wurde Kundencode teilweise in Bereichen des JCR bereitgestellt, die bei Aktualisierungen geändert werden konnten. Daher kam es bei offiziellen AEM-Releases (Hauptversionen, Feature Packs, Service Packs oder Hotfixes) häufig vor, dass benutzerdefinierter Code, Konfigurationen oder Inhalte überschrieben wurden. Darüber hinaus kam es vor, dass durch Kunden vorgenommene Änderungen den AEM-Produktcode oder AEM-Inhalte überschrieben und die Produktfunktion beeinträchtigt haben.

Solche Konflikte konnten nicht immer automatisch aufgelöst werden, das Kennzeichnen verbrauchte sehr viel Verarbeitungszeit und es musste manuell eingegriffen werden, wobei die Lösung nicht immer eindeutig war. Durch klare Abgrenzungshierarchien für AEM-Produktcode und Kundencode können diese Konflikte vermieden werden. 

Aus diesem Grund wird ab AEM 6.4 und in zukünftigen Versionen der Inhalt aus /etc in andere Ordner im Repository verschoben und es gibt Richtlinien dafür, welcher Inhaltwohin gehört,wobei folgende allgemeine Regeln angewendet werden:

  • AEM-Produktcode wird immer im Ordner /libs abgelegt, der nicht durch benutzerdefinierten Code überschrieben werden darf.
  • BenutzerdefinierterCode sollte in /apps, /content und /conf gespeichert werden.

Dieser Artikel ist in drei Bereiche unterteilt, die den Inhaltstypen entsprechen, die aus /etc entfernt wurden:

  1. Konfiguration
  2. Client-seitige Bibliotheken
  3. Sonstiges

Jeder Abschnitt enthält:

  • Eine Tabelle mit den neu strukturierten Speicherorten und zusätzlichem Kontext. Die Tabellen werden in naher Zukunft umformatiert, um die Lesbarkeit zu verbessern.
  • Eine Erweiterbarkeitsstrategie, die das erfolgreiche Erweitern von unter /libs gespeichertem AEM-Anwendungscode durch benutzerdefinierten Code ermöglicht.

Abwärtskompatibilität

In den meisten Fällen bleibt dieAbwärtskompatibilitätzu den alten Speicherorten nach der Aktualisierung auf AEM 6.4 erhalten. Dies wird erreicht, indem die alten Speicherorte neben den neuen Speicherorten erhalten bleiben und durch den Produktcode berücksichtigt werden. In den meisten Fällen wird anhand von Bedingungen geprüft, ob der alte Ordner vorhanden ist und ob Inhalt von dort statt aus den neuen Speicherorten gelesen werden muss.

Kunden wird empfohlen, die alten Speicherorte nach der Aktualisierung auf 6.4 zu entfernen, damit die neuen Speicherorte verwendet werden. Kunden können den Zeitpunkt dieser Änderung nach eigenem Ermessen planen. Die folgende TabelleenthältAnleitungen für die Umstellung auf die am Speicherort orientierte neue Inhaltsstruktur.

Hinweis:

Eine aktualisierte Instanz wird neben den neuen Speicherorten auch alte Inhaltsspeicherorte einbeziehen. Bei einer Neuinstallation werden nur die neuen Speicherorte berücksichtigt.

Anleitung für die Tabellen

Die Tabellen in den einzelnen Abschnitten enthalten:
  • Die AEM-Lösung (Sites, Assets, Forms usw.), für die der Inhalt relevant ist.
  • Den alten Speicherort (6.3 und früher).
  • Den neuen Speicherort ab 6.4.
  • Anleitungen für die Umstellung auf die neue Inhaltsstruktur. So kann es z. B. in den Wochen oder Monaten nach der Aktualisierung auf 6.4 notwendig sein, ein Skript auszuführen oder Dateien manuell zu verschieben.
  • Den von AEM verwendeten Ansatz für die Erhaltung der Abwärtskompatibilität mit alten Inhaltsspeicherorten für Kunden, die eine Aktualisierung von einer früheren Version auf AEM 6.4 durchführen.

Konfiguration

Die in diesem Abschnitt angesprochenen Inhaltsspeicherorte beziehen sich in der Regel auf Inhalt, der unter dem Ordner /settings in /libs, /apps oder /conf gespeichert ist.

Erweiterbarkeitsstrategie

In der Regel, allerdings mit einigen Ausnahmen, kann in diesem Abschnitt behandelter Inhalt über die FunktionContext AwareConfiguration von Apache Sling erweitert werden.

Kurz gesagt erlaubt einekontextsensitiveKonfiguration, dass Inhalt in einem Teil des Repositorys mehrmals durch Inhalt in anderen Teilen des Repositorys überlagert wird. So kann z. B. Inhalt in /libs überlagert werden vonInhaltin /apps, der dann vonInhaltin /conf überlagert werden kann. Darüber hinaus kann Inhalt in einem globalen Ordner unter /conf durch einen bestimmten „Mandanten“ oder eine „Site“ überlagert werden (z. B. /conf/we-retail/settings). 

In der Regel werdenkontextsensitiveKonfigurationen als Strategie für die Erweiterung von Funktionskonfigurationen verwendet. Es gibt jedoch auch Fälle, in denen sie von anderen Inhaltstypen verwendet werden.

Die folgende Tabelle enthält eine zusätzliche Spalte mit dem Konfigurationstyp, um den Umfang zu erläutern, in dem eineKonfigurationüberlagert werden kann. Hier finden Sie weitere Details zu diesen Konfigurationstypen:

Nicht kontextsensitiv

  • Ressourcen befinden sich möglicherweise in kontextsensitiven Ordnerstrukturen (z. B. /libs/settings), werden aber immer über absolute Pfade referenziert, weshalb keine Kontextsensitivität wirkt.
  • Ressourcen können sich überall befinden. So können sich z. B. Assets DRM-Lizenzen in /content/my-customer/licenses/creative-commons.html befinden.
  • Beispiele:
    • Workflow-Skripte -> /apps/settings/workflow/scripts/noop.ecma
    • Assets DRM-Lizenzen -> /apps/settings/dam/drm/my-license

Nur global

  • Funktion mit ausschließlich globaler Konfiguration
  • Sehen Sie sich zur Orientierung den Vorrang der Einstellungen in diesem Beispiel an: /libs/settings < /apps/settings < /conf/global
  • AEM unterstützt nur eine globale Konfiguration, keine Konfigurationen mit Mandanten.
  • AEM sucht nach Konfigurationen immer zuerst auf der Ebene /conf/global.
  • Beispiele:
    • Workflow-Starter -> /libs/settings/workflow/launcher
    • Workflow-Modelle -> /conf/global/settings/workflow/models

Mandantenabhängig

  • Sehen Sie sich für mandantenabhängige Konfigurationen dieses Beispiel für den Vorrang von Konfigurationspfaden an: /libs/settings < /apps/settings < /conf/global < /conf/we-retail, in dem „we-retail“ der Name des Mandanten ist. Mandantenabhängige Konfigurationen unterstützen außerdem untergeordnete Mandanten.
  • AEM unterstützt mandantenabhängige Konfigurationen. Die Eigenschaft cq:conf wird in der Hierarchie beachtet.
  • Beispiele:
    • Bearbeitbare Vorlagen -> /conf/we-retail/settings/wcm/templates
    • Cloud-Konfigurationen -> /conf/we-retail/settings/cloudsettings
Lösung Vorheriger Speicherort
Neuer Speicherort Kontextsensitiver Konfigurationstyp
Abwärtskompatibilitätsansatz Anforderungen für die Ausrichtung am aktuellsten Modell
AEM Sites/AEM Forms

/etc/cloudservices/typekit

/etc/cloudservices/recaptcha

/etc/cloudservices/echosign

/conf/<Mandant>/settings/cloudconfigs/typekit

/conf/<Mandant>/settings/cloudconfigs/recaptcha

/conf/<Mandant>/settings/cloudconfigs/echosign

Mandantenabhängig

Alte Cloudservices.

Bei einer Aktualisierung erhalten geblieben. Code zum Auflisten und Lesen ist in AEM weiterhin als Fallback vorhanden.

Das Dienstprogramm für die Lazy-Content-Migration kann über die Migrationsbenutzeroberfläche von Forms ausgelöst werden, um eine automatische Umwandlung in den neuen Pfad durchzuführen.
AEM Forms /etc/cloudservices/fdm /conf/<Mandant>/settings/cloudconfigs/fdm Mandantenabhängig

Alte Cloudservices.

In einem aktualisierten Setup erhalten geblieben. Code zum Auflisten und Lesen ist in AEM weiterhin als Fallback vorhanden.

Das Dienstprogramm für die Lazy-Content-Migration kann über die Migrationsbenutzeroberfläche von Forms ausgelöst werden, um eine automatische Umwandlung in den neuen Pfad durchzuführen.
AEM Assets /etc/dam/adhocassetshare /libs/settings/dam/adhocassetshare Mandantenabhängig Veraltete Inhaltsstrukturen erhalten eine höhere Priorität als neue OOTB-Strukturen. Anpassungen auf Projektebene müssen ausgeschnitten und in die entsprechenden Pfade von /apps oder /conf eingefügt werden.
AEM Assets /etc/dam/workflow/notification/email/downloadasset /libs/settings/dam/workflow Mandantenabhängig Veraltete Inhaltsstrukturen erhalten eine höhere Priorität als neue OOTB-Strukturen. Anpassungen auf Projektebene müssen ausgeschnitten und in die entsprechenden Pfade von /apps oder /conf eingefügt werden.
AEM Assets /etc/dam/drm/licenses/ /libs/settings/dam/drm Nicht kontextsensitiv Veraltete Inhaltsstrukturen erhalten eine höhere Priorität als neue OOTB-Strukturen. Anpassungen auf Projektebene müssen ausgeschnitten und in die entsprechenden Pfade von /apps oder /conf eingefügt werden.
AEM Assets /etc/dam/indesign/scripts /libs/settings/dam/indesign Mandantenabhängig Veraltete Inhaltsstrukturen erhalten eine höhere Priorität als neue OOTB-Strukturen.

Anpassungen auf Projektebene müssen ausgeschnitten und in die entsprechenden Pfade von /apps oder /conf eingefügt werden.

Beim Ausführen eines Workflows mit Asset-Verarbeitung können weiterhin Verweise auf den alten Speicherort in /etc in der Media Extraction Process-Konfiguration vorhanden sein. Neben dem Verschieben der Skripte aus /etc in die entsprechenden Pfade unter /apps und /conf müssen angepasste Media Extraction Process-Argumente angepasst werden, indem absolute in relative Pfade geändert werden.

Weitere Informationen finden Sie auf dieser Seite.

 

AEM Assets /etc/dam/video /libs/settings/dam/video Mandantenabhängig Veraltete Inhaltsstrukturen erhalten eine höhere Priorität als neue OOTB-Strukturen. Anpassungen auf Projektebene müssen ausgeschnitten und in die entsprechenden Pfade von /apps oder /conf eingefügt werden.
Alle /etc/notification/email/default /libs/settings/dam/notification Mandantenabhängig Veraltete Inhaltsstrukturen erhalten eine höhere Priorität als neue OOTB-Strukturen. Anpassungen auf Projektebene müssen ausgeschnitten und in die entsprechenden Pfade von /apps oder /conf eingefügt werden.
AEM Sites/AEM Assets /etc/designs
/libs/settings/wcm/designs Nicht kontextsensitiv

Verarbeitende Dienste berücksichtigen den alten Speicherort.

Konfigurationen vom alten Speicherort werden berücksichtigt.


Verschieben Sie benutzerdefinierte Inhalte aus /etc/design in /apps/settings/wcm/design, um die neue Repository-Struktur einzuhalten. In Zukunft können Sie Ihre Sites dahingehend aktualisieren, dass diese bearbeitbare Vorlagen verwenden, die den Designmodus und somit diesen Inhalt überflüssig machen.
AEM Sites /etc/scaffolding

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

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

Nicht kontextsensitiv Die Komponenten am alten Speicherort unter /etc/scaffolding funktionieren weiterhin, sind aber veraltet. Adobe empfiehlt die Verwendung der neuen Gerüstkomponenten am neuen Speicherort.
AEM Sites /etc/blueprints

/libs/msm für vorkonfigurierte Blueprint-Konfigurationen von Screens und Commerce

 

Nicht kontextsensitiv

Verarbeitende Dienste berücksichtigen den alten Speicherort.

Konfigurationen vom alten Speicherort werden berücksichtigt.

Die Konfigurationen müssen an die neuen Speicherorte kopiert werden.
AEM Sites /etc/mobile /libs/settings/mobile Mandantenabhängig Die Funktion nutzt den Configuration Manager und unterstützt den alten Speicherort weiterhin als Fallback.
  1. Verschieben Sie die Konfigurationen aus /etc nach /conf/<Mandant>/settings/mobile
  2. Aktualisieren Sie dann den Verweis im Inhalt wie folgt:

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

AEM Sites /etc/msm/rolloutConfigs /libs/msm/wcm/rolloutconfigs Nicht zutreffend

Verarbeitende Dienste berücksichtigen den alten Speicherort.

Wenn am alten Speicherort Konfigurationen gefunden werden, werden diese verwendet.

Für eine Ausrichtung am neuen Modell müssen Konfigurationen an den neuen Speicherorten erstellt werden und die unter /etc vorhandenen alten Konfigurationen müssen gelöscht werden.
AEM Sites /etc/segmentation/contexthub /conf/we-retail/settings/wcm/segments Mandantenabhängig

Segmente vom alten Speicherort:

  • Verbleiben schreibgeschützt in der Zielgruppenkonsole.
  • Werden weiterhin auf der Seite geladen (wenn der angegebene Pfad unter Seiteneigenschaften > Personalisierung > Segmentpfad ausgewählt wird).
  • Können für Content-Targeting verwendet werden.
Sie können das Tool für die Segmentmigration verwenden, um zum neuen Speicherort zu migrieren.
AEM Communities /etc/social/config/languageOpts /libs/social/translation/languageOpts Nicht zutreffend    
AEM Communities /etc/community/templates /libs/settings/community/templates  

Der Code berücksichtigt den Speicherort der alten Vorlage. Vorhandene Vorlagen werden weiterhin referenziert und aus bzw. in /etc gelesen/geschrieben.


Wenn ein Kunde bereits benutzerdefinierte E-Mail-Vorlagen unter einem anderen Pfad verwendet, den er als Stammverzeichnis für Vorlagen in der Konfiguration für das Beantworten von E-Mails in AEM Communities konfiguriert hat, sollten keine Änderungen vorgenommen werden.

Ein Migrationsdienstprogramm kann eine Anpassung an das Modell für die aktuellen AEM Communities-Vorlagen durchführen.

AEM Communities /etc/community/badging

Badge-Regeln:

/libs/settings/community/badging

Badge-Bilder:

Die am alten Speicherort unter /etc/community/badging/images vorkonfigurierten Bilder werden nach /libs/community/badging/images verschoben. 

 

Eigene Bilder werden nach /content/community/badging/images verschoben.

 

Mandantenabhängig

Der Code berücksichtigt die alten Badging-Pfade.


Er prüft zuerst, ob ältere Pfade
vorhanden sind. Wenn keine Pfade vorhanden sind, werden die neuen Pfade verwendet.

Für die Anpassung an das aktuelle Modell ist eine manuelle Migration erforderlich. Führen Sie hierzu die folgenden Schritte aus:

  1. Erstellen Sie unter Tools mit dem Konfigurationsbrowser einen Behälter für den Site-Kontext.
  2. Wechseln Sie zum Stammordner der Site.
  3. Legen Sie für die Eigenschaft cq:conf den Behälterpfad fest, unter dem Sie alle Konfigurationen speichern möchten. Dieselbe Einstellung kann über den Assistenten für die Seitenbearbeitung als Eingabe für die Cloud-Konfiguration festgelegt und gespeichert werden.
  4. Verschieben Sie die relevanten Badging- und Scoring-Regeln aus etc/community/* in den im vorigen Schritt erstellten Site-Kontext-Behälter.
  5. Passen Sie die Eigenschaften badgingRules und scoringRules an das Site-Stammverzeichnis an, um relative Verweise auf den neuen Speicherort der Regeln zu erhalten. Beispiel: Wenn cq:conf auf /conf/we-retail festgelegt wird, lautet der Wert für badgingRules community/badging/rules, wenn die Regeln jetzt in diesen neuen Behälter verschoben werden.
  6. Passen Sie auf die gleiche Weise die Verweise auf Scoring-Regeln in einem Badging-Regel-Knoten an, um einen relativen Pfad zu erhalten.
AEM Sites

/etc/cloudservices/facebookconnect

/etc/cloudservices/twitterconnect

/etc/cloudservices/pinterestconnect

/conf/<Mandant>/settings/cloudconfigs/facebookconnect

/conf/<Mandant>/settings/cloudconfigs/twitterconnect

/conf/<Mandant>/settings/cloudconfigs/pinterestconnect

Mandantenabhängig    
AEM Communities /etc/community/scoring /libs/settings/community/scoring  

Der Code berücksichtigt die alten Badging-Pfade.


Er prüft zuerst, ob ältere Pfade
vorhanden sind. Wenn keine Pfade vorhanden sind, werden die neuen Pfade verwendet.

Für die Anpassung an das aktuelle Modell sind manuelle Migrationsschritte erforderlich.

Diese Schritte stimmen mit den oben für die Badging-Regeln beschriebenen Schritten überein.

AEM Communities /etc/community/notifications /libs/settings/community/notifications Nicht kontextsensitiv

Diese Konfigurationen sind nicht abwärtskompatibel. In der Spalte mit den Anforderungen für die Anpassung an das aktuelle Modell finden Sie die für die Migration zu den neuen Speicherorten erforderlichen Schritte.


Für die Anpassung an das aktuelle Modell ist eine manuelle Migration erforderlich. Sie können den Granite Configuration Manager verwenden, um die Konfigurationen in den neuen Pfad unter /apps/settings zu verschieben.

Hierzu müssen Sie für die Eigenschaft mergeList im Knoten /libs/settings/community/subscriptions „true“ festlegen und dann einen untergeordneten Knoten nt:unstructured hinzufügen.

AEM Communities /etc/community/subscriptions /libs/settings/community/subscriptions Nicht kontextsensitiv Diese Konfigurationen sind nicht abwärtskompatibel. In der Spalte mit den Anforderungen für die Anpassung an das aktuelle Modell finden Sie die für die Migration zu den neuen Speicherorten erforderlichen Schritte.

Für die Anpassung an das aktuelle Modell ist eine manuelle Migration erforderlich. Sie können den Granite Configuration Manager verwenden, um die Konfigurationen in den neuen Pfad unter /apps/settings zu verschieben.

Hierzu müssen Sie für die Eigenschaft mergeList im Knoten /libs/settings/community/subscriptions „true“ festlegen und dann einen untergeordneten Knoten nt:unstructured hinzufügen.

AEM Communities /etc/socialconfig/srpc/defaultconfiguration /conf/global/settings/community/srpc/defaultconfiguration Global Diese Konfigurationen sind abwärtskompatibel. Wenn alte Pfade gefunden werden, werden diese verwendet. Andernfalls haben die neuen Pfade Vorrang.

Die Aufgabe für die Lazy-Content-Migration ist als CQ64CommunitiesConfigsCleanupTask verfügbar.

Weitere Informationen finden Sie in der Dokumentation zur verzögerten Migration.

AEM Communities /etc/watchwords /libs/community/watchwords Nicht zutreffend Diese Konfigurationen sind abwärtskompatibel. Wenn alte Pfade gefunden werden, werden diese verwendet. Andernfalls haben die neuen Pfade Vorrang.

Die Aufgabe für die Lazy-Content-Migration ist als CQ64CommunitiesConfigsCleanupTask verfügbar.

Schlagwörter müssen manuell von /etc/watchwords nach /conf/global/settings/community/watchwords verschoben werden.

Alle /etc/workflow/models

/libs/settings/workflow/models

/conf/global/settings/workflow/models

/var/workflow/models

Global

Der alte Speicherort wird verwendet, sofern er vorhanden ist und in /libs oder /conf keine Konfiguration gefunden wird.

Wenn Sie OOTB-Workflow-Modelle bearbeiten, müssen unter /conf kontextsensitive Überlagerungen erstellt werden, damit diese geändert werden können.

Der Paketexport muss das Modell in /libs oder /conf umfassen sowie das Laufzeitmodell in /var/workflow/models.

Neu erstellte Modelle werden unter /conf/global/settings gespeichert.

Für alle Bearbeitungsvorgänge in /etc oder /libs müssen Sie eine explizite Außerkraftsetzung in /conf/global/settings erstellen, damit die Bearbeitung möglich ist. Mit der Schaltfläche „Bearbeiten“ wird die Außerkraftsetzung in /conf erstellt und die Bearbeitung erlaubt.

Alle /etc/workflow/launcher

/libs/settings/workflow/launcher

/conf/global/settings/workflow/launcher

Global Der alte Speicherort wird verwendet, sofern er vorhanden ist und in
/libs oder /conf keine Konfiguration gefunden wird. Auf diese Weise bleiben benutzerdefinierte Starter erhalten.

Neu erstellte oder bearbeitete Starterkonfigurationen befinden sich in /conf.

Alle Starter müssen vom alten Speicherort /etc nach /conf/global/settings/workflow/launcher verschoben werden.

Alle /etc/workflow/models

/libs/settings/workflow/models

/conf/global/settings/workflow/models

Global Der alte Speicherort wird verwendet, sofern er vorhanden ist und in
/libs oder /conf keine Konfiguration gefunden wird. Auf diese Weise bleiben benutzerdefinierte Workflow-Modelle erhalten.

Alle Workflow-Modelle müssen vom alten Speicherort /etc nach /conf/global/settings/workflow/models verschoben werden.

 

Alle /etc/workflow/notification

/libs/settings/workflow/notification

/conf/global/settings/workflow/notification

Nicht kontextsensitiv

Aus Gründen der Abwärtskompatibilität wird der alte Speicherort verwendet, sofern er vorhanden ist.

Bisher mussten Standardvorlagen außer Kraft gesetzt werden, indem sie in /etc bearbeitetet wurden. Jetzt muss die Außerkraftsetzung in /conf/global gespeichert werden.

Weitere Informationen finden Sie in der Workflow-Dokumentation.
Alle /etc/cloudservices/translation

/libs/settings/cloudconfigs/translation/translationcfg

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

 

Mandantenabhängig Alte Cloudservices. Werden in einem aktualisierten Setup beibehalten. Code zum Auflisten und Lesen ist im Produkt weiterhin als Fallback vorhanden.

Cloud-Konfigurationen können Sie mit einem der folgenden Verfahren nach /conf verschieben:

  • Erstellen Sie Konfigurationen über die neue Touch-optimierte Benutzeroberfläche
    oder
  • Kopieren Sie die Konfigurationen aus /etc/cloudservices/translation an ihre jeweiligen neuen Speicherorte.

Anschließend müssen die Konfigurationen auf der Benutzeroberfläche über Sites > Eigenschaften Sites zugeordnet werden.

Hinweis: Damit dies funktioniert, müssen Übersetzungs-Connectors mit AEM 6.4 kompatibel sein.

Alle /etc/cloudservices/msft-translation

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

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

Mandantenabhängig Alte Cloudservices. Werden in einem aktualisierten Setup beibehalten. Code zum Auflisten und Lesen ist im Produkt weiterhin als Fallback vorhanden.

Cloud-Konfigurationen können Sie mit einem der folgenden Verfahren nach /conf verschieben:

  • Erstellen Sie Konfigurationen über die neue Touch-optimierte Benutzeroberfläche oder
  • Kopieren Sie die alten Konfigurationen aus /etc/cloudservices/translation an ihre jeweiligen neuen Speicherorte.

Anschließend müssen die Konfigurationen auf der Benutzeroberfläche über Sites > Eigenschaften Sites zugeordnet werden.

Alle /etc/cloudsettings

/libs/settings/cloudsettings

/conf/<Mandant>/settings/cloudsettings

Mandantenabhängig

Unter /etc vorhandene Einträge bleiben beim Aktualisieren der Instanz erhalten.

Wenn Sie nach der Aktualisierung auf die Benutzeroberfläche mit den Cloud-Einstellungen zugreifen, werden die vorhandenen Cloud-Einstellungen in die neue Repository-Struktur kopiert. Der vorhandene Inhalt bleibt dabei erhalten, um die Abwärtskompatibilität sicherzustellen.

Die Inhaltsmodelle sind identisch, es wird nur der Speicherort geändert und an kontextsensitive Konfigurationen angepasst.

Die Aufgabe für die verzögerte Migration für diese Cloud-Einstellungen führt die folgenden Aktionen durch:

  • Kopieren der in /etc/cloudsettings vorhandenen Cloud-Einstellungen nach /conf/global/settings/cloudsettings.
  • Löschen aller Unterordner unter /etc/cloudsettings.

Es gibt jedoch Schritte, die nach der Aktualisierung und vor der verzögerten Migration manuell ausgeführt werden müssen:

  • Alle Verweise auf /etc/cloudsettings/* müssen so aktualisiert werden, dass sie auf /conf/global verweisen.

Einschränkung:

  • Der Container /etc/cloudsettings muss beibehalten werden.
AEM Assets /etc/cloudservices/dmscene7 /conf/global/settings/cloudservices/dmscene7 Nur global

Die Cloud-Konfiguration für das Setup „Dynamic Media - Scene7“ (Ausführungsmodus dynamicmedia_scene7) bleibt am ursprünglichen Speicherort. Der Prozess wird unverändert ausgeführt. Falls Sie den Wert für die Cloud-Konfiguration anpassen müssen, gibt es hierzu zwei Möglichkeiten:

  1. Aktualisieren einer vorhandenen Konfiguration über die alte Benutzeroberfläche für die Cloud-Konfiguration.
  2. Erstellen einer neuen Cloud-Konfiguration über die neue Touch-optimierte Benutzeroberfläche. Diese hat gegenüber der alten Vorrang.

Zur Anpassung an das aktuelle Modell muss das unter folgendem Link verfügbare Skript ausgeführt werden:

  • 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

Nur global

Die Voreinstellungen für die Standardanzeige sind nur am neuen Speicherort verfügbar. Benutzerdefinierte Voreinstellungen für die Anzeige befinden sich so lange weiterhin unter /etc, bis sie geändert werden.

Nach einer Änderung werden sie über die Lazy-Migration am neuen Speicherort gespeichert. Wenn der Bildserver eine Einbettungsanforderung erhält, sucht er sowohl unter dem alten als auch unter dem neuen Pfad. Es ist daher nicht erforderlich, den Einbettungscode oder die URLs zu ändern.

Die Voreinstellungen für die Standardanzeige sind nur am neuen Speicherort verfügbar. Für die benutzerdefinierten Voreinstellungen für die Anzeige müssen Sie das Migrationsskript unter folgendem Link ausführen:

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

Ähnlich wie im Fall der Abwärtskompatibilität ist es nicht erforderlich, dass Sie den Code für copyURL/embed anpassen und auf /conf verweisen lassen. Die vorhandene Anforderung an /etc wird zum richtigen Inhalt aus /conf umgeleitet.

AEM Assets /etc/dam/imageserver/macros /conf/global/settings/dam/dm/presets/macro Nur global Das Makro unter /etc ist weiterhin gültig. Wenn es geändert wird, wird der geänderte Knoten durch die Lazy-Migration an den neuen Speicherort unter /conf verschoben.

Das Migrationsskript muss über den folgenden Link ausgeführt werden:

  • 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 Nicht zutreffend

Das Standardvideoprofil wird entfernt, ohne dass die Eigenschaft des Asset-Ordners mit einer Verknüpfung mit dem Profil aktualisiert wird.

Im Codierungsprozess ist eine Übersetzung des alten in den neuen Speicherort integriert. Der alte Pfad wird in den neuen Profilpfad umgewandelt.

Keine Änderungen erforderlich
AEM Assets /etc/dam/video/dynamicmedia /conf/global/settings/dam/dm/presets/video/jcr:content Nur global

Das benutzerdefinierte Videoprofil bleibt so lange unverändert an seinem Speicherort, bis es bearbeitet wird.

Nach einer Bearbeitung wird es über die Lazy-Migration an den neuen Speicherort verschoben. Dies ist ähnlich wie die standardmäßige Videovoreinstellung bei der Codierungssuche. Der Codierungsprozess besitzt eine integrierte Pfadübersetzung, die zuerst am alten Speicherort und anschließend am neuen Speicherort nach dem Videoprofil sucht.

Für die Anpassung an das aktuelle Modell können Sie das folgende Migrationsskript ausführen:

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

 

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

Diese Cloud-Konfiguration für ein hybrides Setup für dynamische Medien (Ausführungsmodus dynamicmedia) verbleibt am selben Speicherort. Der Prozess funktioniert wie bisher. Falls Sie den Konfigurationswert anpassen müssen, ist dies auf zwei Wegen möglich.

  1. Aktualisieren einer vorhandenen Konfiguration über die alte Benutzeroberfläche für die Cloud-Konfiguration.
  2. Erstellen einer neuen Cloud-Konfiguration über die neue Touch-optimierte Benutzeroberfläche. Diese hat gegenüber der alten Vorrang.

Sie müssen das Migrationsskript ausführen, damit eine Anpassung an das aktuelle Modell erfolgt. Sie finden das Skript unter folgendem Link:

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

Die Cloud-Konfiguration für das DM-Youtube-Setup verbleibt am selben Speicherort. Der Prozess funktioniert wie bisher. Falls Sie den Cloud-Konfigurationswert anpassen müssen, ist dies auf zwei Wegen möglich.

  1. Aktualisieren einer vorhandenen Konfiguration über die alte Benutzeroberfläche für die Cloud-Konfiguration.
  2. Erstellen einer neuen Cloud-Konfiguration über die neue Touch-optimierte Benutzeroberfläche. Diese hat gegenüber der alten Vorrang.

Sie können ein Migrationsskript ausführen, damit eine Anpassung an das aktuelle Modell erfolgt. Sie finden das Skript unter folgendem Link:

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

 

 

AEM Assets /etc/dam/presets/analytics /libs/settings/dam/dm/analytics Nur global Keine Aktion erforderlich.

Sie können ein Migrationsskript ausführen, damit eine Anpassung an das aktuelle Modell erfolgt. Sie finden das Skript unter folgendem Link:

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

Alle

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

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

/libs/settings/notification-templates Nur global Die Vorlagen in /etc/notification/email/default/ haben Vorrang vor denen in /libs/settings/notification-templates. Für eine Anpassung an das aktuelle Modell können Sie neue Vorlagen unter /apps/settings/notification-templates erstellen und dort Anpassungen vornehmen.
AEM Sites

/etc/msm/rolloutconfigs/launch

/etc/msm/rolloutconfigs/pushonmodifyshallow

/libs/msm/launches/rolloutconfigs/launch

/libs/msm/launches/rolloutconfigs/pushonmodifyshallow

Nicht zutreffend

Verarbeitende Dienste berücksichtigen den alten Speicherort.

Wenn am alten Speicherort Konfigurationen gefunden werden, werden diese verwendet.

Für eine Ausrichtung am neuen Modell müssen Konfigurationen an den neuen Speicherorten erstellt werden und die unter /etc vorhandenen alten Konfigurationen müssen gelöscht werden.
Alle /etc/translation/supportedLanguages

/libs/settings/translation/supportedLanguages

/apps/settings/translation/supportedLanguages

Nicht kontextsensitiv Voraussetzung ist, dass angepasste Sprachen zur Liste hinzugefügt werden.
Überlagern und aktualisieren Sie die neue Liste mit zusätzlichen Sprachen (sofern vorhanden). Alternativ können Sie auch die alte Liste nach /apps kopieren.
Alle /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

Nur global Werden in einem aktualisierten Setup beibehalten. Code zum Auflisten und Lesen ist weiterhin im Produkt vorhanden. Um die Änderungen beizubehalten, kopieren Sie die XML-Datei aus /etc nach /libs oder /conf. Alternativ können Sie die Datei aus /etc entfernen.

Client-seitige Bibliotheken

Client-seitige Bibliotheken enthalten JavaScript- und CSS-Code, der im Browser verarbeitet wird.

Erweiterbarkeitsstrategie

AEM bietet ein erweiterbares Framework, um mehrere JavaScript-Dateien anzufügen. Alle Dateien mit derselben Eigenschaft „Kategorien“ werden angefügt, wodurch benutzerdefinierter Code den AEM-Code erweitern kann, der sich unter /libs befindet.

Lösung Vorheriger Speicherort


Neuer Speicherort Abwärtskompatibilitätsansatz Anforderungen für die Ausrichtung am aktuellsten Modell
AEM Forms /etc/clientlibs/fd/fp /libs/fd/fp/components

Alte Client-Bibliothek, die auf einer Instanz weiterbesteht, die durch ein direktes Upgrade aktualisiert wurde.

Neue Client-Bibliotheken haben dieselben Kategorienamen zusammen mit der Eigenschaft ersetzt, um ein Vermischen alter und neuer Client-Bibliotheken zu vermeiden.

Keine Aktion erforderlich.
AEM Forms /etc/clientlibs/fd/rte /libs/fd/rte

Alte Client-Bibliotheken, die auf einer Instanz weiterbestehen, die durch ein direktes Upgrade aktualisiert wurde.

Neue Client-Bibliotheken haben dieselben Kategorienamen zusammen mit der Eigenschaft ersetzt, um ein Vermischen alter und neuer Client-Bibliotheken zu vermeiden.

Keine Aktion erforderlich.
AEM Forms /etc/clientlibs/fd/af /libs/fd/af/authoring/clientlibs Alte Client-Bibliotheken. Bestehen auf einer Instanz weiter, die durch ein direktes Upgrade aktualisiert wurde. Neue Client-Bibliotheken haben dieselben Kategorienamen zusammen mit der Eigenschaft ersetzt, um ein Vermischen alter und neuer Client-Bibliotheken zu vermeiden. Keine Aktion erforderlich.
AEM Forms /etc/clientlibs/fd/themes/themeLibrary Nicht mehr im Standardpaket von AEM 6.4 enthalten.

Standarddesigns in adaptiven Formularen.

Werden in einem aktualisierten Setup beibehalten.

Dies ist teilweise vom Benutzer generierter Inhalt. Wird mit dem Namen aem-forms-reference-themes als Referenzinhaltspaket bereitgestellt.
AEM Forms /etc/clientlibs/fd/expeditor /libs/fd/expeditor/clientlibs Alte Client-Bibliotheken. Bestehen auf einer Instanz weiter, die durch ein direktes Upgrade aktualisiert wurde. Neue Client-Bibliotheken haben dieselben Kategorienamen zusammen mit der Eigenschaft ersetzt, um ein Vermischen alter und neuer Client-Bibliotheken zu vermeiden. Keine Aktion erforderlich.

 

AEM Forms /etc/clientlibs/fd/fmaddon /libs/fd/fmaddon Alte Analytics- und Target-Client-Bibliotheken die nicht für die direkte Verarbeitung vorgesehen sind.  Werden nach der Aktualisierung mit einem Cleanup-Filter bereinigt.
AEM Assets

/etc/clientlibs/foundation/asseteditor

/etc/clientlibs/foundation/assetshare

/etc/clientlibs/foundation/assetinsights

/libs/dam/clientlibs Alte Client-Bibliotheken haben unterschiedliche Client-Kategorienamen. Keine Aktion erforderlich.
  /etc/clientlibs/ckeditor /libs/clientlibs/ckeditor Dies sind alte Client-Bibliotheken. Sie werden in einem aktualisierten Setup beibehalten. Neue Client-Bibliotheken haben dieselben Kategorienamen zusammen mit der Eigenschaft ersetzt, um ein Vermischen alter und neuer Client-Bibliotheken zu vermeiden. Keine Aktion erforderlich.
AEM Sites /etc/clientlibs/foundation/sitecatalyst /libs/cq/analytics/clientlibs/analytics

Dies sind alte Client-Bibliotheken. Werden in einem aktualisierten Setup beibehalten.

Neue Client-Bibliotheken haben dieselben Kategorienamen.

Keine Aktion erforderlich.
AEM Sites /etc/clientlibs/foundation/personalization /libs/cq/personalization/clientlibs/personalization

Dies sind alte Client-Bibliotheken. Werden in einem aktualisierten Setup beibehalten.

Neue Client-Bibliotheken haben dieselben Kategorienamen.

Keine Aktion erforderlich.
AEM Sites /etc/clientlibs/foundation/searchpromote /libs/cq/searchpromote/clientlibs/searchpromote

Dies sind alte Client-Bibliotheken. Werden in einem aktualisierten Setup beibehalten.

Neue Client-Bibliotheken haben dieselben Kategorienamen.

Keine Aktion erforderlich.
AEM Sites /etc/clientlibs/foundation/target /libs/cq/target/clientlibs/target

Dies sind alte Client-Bibliotheken. Werden in einem aktualisierten Setup beibehalten.

Neue Client-Bibliotheken haben dieselben Kategorienamen.

Keine Aktion erforderlich.
AEM Sites /etc/clientlibs/address /libs/cq/address/clientlibs Neue Client-Bibliotheken haben dieselben Kategorienamen. Keine Aktion erforderlich.
AEM Sites /etc/clientlibs/wcm/foundation /libs/wcm/foundation/clientlibs Alte Client-Bibliotheken. Werden in einem aktualisierten Setup beibehalten. Neue Client-Bibliotheken haben dieselben Kategorienamen zusammen mit der Eigenschaft ersetzt, um ein Vermischen alter und neuer Client-Bibliotheken zu vermeiden. Keine Aktion erforderlich.
AEM Sites /etc/clientlibs/wcm/foundation/grid/grid_base.less

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

Bei einem direkten Upgrade verbleibt die veraltete Datei (/etc/clientlibs/wcm/…_) und kann nicht automatisch entfernt werden, damit Verweise auf die alte /etc/clientlibs/wcm/foundation/grid/grid_base.less weiterhin funktionieren.

Beachten Sie, dass es sich hierbei um einen Sonderfall handelt, in dem diese LESS-Datei über LESS @import-Anweisungen über einen absoluten Pfad referenziert wird und NICHT über die clientlib-Kategorie.

Wenn der LESS-Verweis des Kunden auf grid_base.less auf eine nicht vorhandene Datei zeigt, schlägt der Modus für das bearbeitbare Vorlagenlayout fehl und daran vorgenommenen Anpassungen sind nicht vorhanden (d. h. alle Komponenten erscheinen in voller Breite auf der Seite).

Aktualisieren Sie alle Verweise im benutzerdefinierten Code (d. h. in allen LESS-Dateien, die auf die verschobene Datei grid_base.less verweisen) so, dass sie auf den neuen Speicherort zeigen, und entfernen Sie den alten Speicherort.

Dies sind weitere Neustrukturierungen, die in den vorherigen Abschnitten nicht behandelt wurden.

Erweiterbarkeitsstrategie

In den Tabellenzeilen werden alle unterstützten Erweiterbarkeitsmodelle angegeben. In diesem Abschnitt enthaltener Inhalt wird in der Regel nicht erweitert.

Sonstiges

Lösung Vorheriger Speicherort
Neuer Speicherort Abwärtskompatibilitätsansatz Anforderungen für die Ausrichtung am aktuellsten Modell
AEM Forms /etc/designs/fd/fp /libs/fd/fp

Alte OOTB-Vorlagen des AEM Forms Portal. Diese Vorlagen verbleiben nach einer Aktualisierung in /etc.

In der Vorlagenauflistung wird das Wort veraltet zum Vorlagentitel hinzugefügt, um sie von den neueren Vorlagen zu unterscheiden.

Keine Aktion erforderlich.
AEM Forms /etc/aep /var/fd/content/annotations Alte Correspondence Management-Kommentardatei. Nicht für die direkte Verarbeitung vorgesehen. Wird nach der Aktualisierung mit einem Cleanup-Filter bereinigt. Der alte Speicherort wird nach der Aktualisierung mit einem Cleanup-Filter bereinigt.
Alle /etc/tags /content/cq:tags Die Tag-Manager-API unterstützt sowohl den alten als auch den neuen Speicherort. Wenn die OSGi-Komponente JcrTagManagerFactory gestartet wird, erkennt sie, ob sie auf einer aktualisierten Instanz oder einer alten Instanz läuft, und verwendet den entsprechenden Speicherort.

Für eine korrekte Anpassung an das neue Modell:

  1. Ersetzen Sie die Verweise auf das alte Modell (/etc/tags) durch Verweise auf das neue (/content/cq:tags), indem Sie die tagID verwenden.
  2. Melden Sie sich bei CRXDE Lite an.
  3. Verschieben Sie die Tags aus /etc/tags nach /content/cq:tags.
  4. Starten Sie die OSGi-Komponente com.day.cq.tagging.impl.JcrTagManagerFactoryImpl
    neu.

 

Alle /etc/workflow/instances /var/workflow/instances Alter Speicherort, der bei der Verarbeitung von
laufenden Workflows verwendet wird. Neue Workflows verwenden den neuen Speicherort unter /var.
Keine Aktion erforderlich.
Alle /etc/workflow/scripts

/libs/workflow/scripts

/apps/workflow/scripts

Vorhandene Workflow-Modellschritte, die auf Skripte am alten Speicherort unter /etc/workflow/scripts verweisen, zeigen nach der Aktualisierung weiterhin auf diese Skripte und werden ordnungsgemäß ausgeführt.

Beachten Sie, dass die AEM-Benutzeroberfläche für die Bearbeitung der Workflow-Schritte (Verarbeiten, Aufteilen usw.) in der Dropdown-Liste für die Auswahl von Workflow-Skripten unter /etc/workflow/scripts vorhandene Skripte nicht mehr auflistet.

Workflows, die diese Skripte nutzen, funktionieren weiterhin wie erwartet, solange der zugehörige Workflow-Verarbeitungsschritt nicht in AEM bearbeitet wurde.

Für eine vollständige Abwärtskompatibilität, die auch bestehen bleibt, wenn Schritte bearbeitet werden, muss der Kunde nach der Aktualisierung manuell eingreifen:

  • Die Skripte müssen aus /etc/workflow/scripts nach /apps/workflow/scripts verschoben werden.
  • Alle Verweise auf /etc/workflow/scripts in Workflow-Modellschritten müssen dahingehend aktualisiert werden, dass sie auf den neuen Speicherort /apps/workflow/scripts verweisen.
Alle /etc/replication/treeactivation /libs/replication/treeactivation Die Seite mit dem Dienstprogramm ClassicUI bleibt bei der Aktualisierung erhalten. Keine Aktion erforderlich.
AEM Assets /etc/dam/jobs /var/dam/jobs

Temporärer Speicherort für ZIP-Dateien, die für das Aufrufen der Downloadaktion von AEM Assets generiert werden.

Hier ist keine Aktualisierung erforderlich, da die Dateien am neuen Speicherort erstellt werden, sobald der Client das Herunterladen des Assets anfordert.

Keine Aktion erforderlich.
AEM Commerce /etc/commerce/products /var/commerce/products

Der alte Inhalt verbleibt an seinem Speicherort und kann nach der Aktualisierung verwendet werden.

Für die Migration an den neuen Speicherort ist eine Lazy-Migration verfügbar.

Die Migration erfolgt über eine Lazy-Migration-Aufgabe: CQ64CommerceMigrationTask.

Diese führt folgende Schritte aus:

  • Anpassung der Verweise auf den alten Speicherort an den neuen Speicherort.
  • Verschieben des Inhalts vom alten Speicherort an den neuen Speicherort
  • Entfernen des alten Speicherorts, um die Verwendung des neuen Speicherorts im gesamten System zu aktivieren.

Die von der Aufgabe betroffenen Speicherorte:

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

Für größere Kataloge empfiehlt es sich, die Aufgabe für die Commerce-Migration einzeln auszuführen, indem die folgende Java-Systemeigenschaft an AEM übergeben wird:

  • Name der Eigenschaft: com.adobe.upgrade.forcemigration
  • Wert der Eigenschaft: com.day.cq.compat.codeupgrade.impl.cq64.CQ64CommerceMigrationTask

Nach der Migration muss AEM neu gestartet werden.

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

Der alte Inhalt verbleibt an seinem Speicherort und kann nach der Aktualisierung verwendet werden.

Für die Migration an den neuen Speicherort ist eine Lazy-Migration verfügbar.

Siehe die obige Beschreibung für /etc/commerce/products.
AEM Commerce /etc/commerce/collections /var/commerce/collections

Der alte Inhalt verbleibt an seinem Speicherort und kann nach der Aktualisierung verwendet werden.

Für die Migration an den neuen Speicherort ist eine Lazy-Migration verfügbar.

Siehe die obige Beschreibung für /etc/commerce/products.
AEM Commerce /etc/commerce/classifications /var/commerce/classifications Keine Aktion erforderlich. Keine Aktion erforderlich.
AEM Commerce /etc/commerce/shipping-methods /var/commerce/shipping-methods

Der alte Inhalt verbleibt an seinem Speicherort und kann nach der Aktualisierung verwendet werden.

Für die Migration an den neuen Speicherort ist eine Lazy-Migration verfügbar.

Siehe die obige Beschreibung für /etc/commerce/products.
AEM Commerce /etc/commerce/payment-methods /var/commerce/payment-methods

Der alte Inhalt verbleibt an seinem Speicherort und kann nach der Aktualisierung verwendet werden.

Für die Migration an den neuen Speicherort ist eine Lazy-Migration verfügbar.

Siehe die obige Beschreibung für /etc/commerce/products.
Alle /etc/taskmanagement /var/taskmanagement

Neue Aufgaben werden unter /var/taskmanagement erstellt.

Am alten Speicherort vorhandene Aufgaben werden weiterhin im AEM-Posteingang angezeigt.

Keine Aktion erforderlich.
Alle /etc/workflow/packages /var/workflow/packages

Mit dem AEM Package Manager erstellte AEM-Pakete werden weiterhin in /etc/workflow/packages gespeichert.

Andere über AEM Sites und Workflows erstellte Pakete werden weiterhin in /var/workflow/packages gespeichert.

Pakete, die sich sowohl in /etc/workflow/packages als auch in /var/workflow/packages befinden, können weiterhin mit dem AEM Package Manager bearbeitet werden. 

Keine Aktion erforderlich.

 

Alle /etc/workflow/instances /var/workflow/instances Neue Workflow-Instanzen werden automatisch unter /var erstellt. Keine Aktion erforderlich.
Alle /etc/commerce/searchpromote /var/cq/searchpromote

Neuer Speicherort für Search&Promote-Feedinhalt.

Die alte URL funktioniert weiterhin und die Anforderung wird durch einen ServletFilter an den neuen Speicherort weitergeleitet.

Keine Aktion erforderlich.

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

Neuer Speicherort für DTM Web-Hooks.

Die alte URL funktioniert weiterhin und die Anforderung wird durch einen ServletFilter an den neuen Speicherort weitergeleitet.

Keine Aktion erforderlich.

Dieses Werk unterliegt den Bedingungen der Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.  Twitter™- und Facebook-Beiträge fallen nicht unter die Bedingungen der Creative Commons-Lizenz.

Rechtliche Hinweise   |   Online-Datenschutzrichtlinie