Sie sehen sich Hilfeinhalte der folgenden Version an:
- 6.4
- Ältere Versionen
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 Inhalt
- AEM-Produktcode wird immer im Ordner /libs abgelegt, der nicht durch benutzerdefinierten Code überschrieben werden darf.
Benutzerdefinierter Code sollte in /apps, /content und /conf gespeichert werden.
Dieser Artikel ist in drei Bereiche unterteilt, die den Inhaltstypen entsprechen, die aus /etc entfernt wurden:
- Konfiguration
- Client-seitige Bibliotheken
- 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.
In den meisten Fällen bleibt die
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 Tabelle
Hinweis:
Eine aktualisierte Instanz wird neben den neuen Speicherorten auch alte Inhaltsspeicherorte einbeziehen. Bei einer Neuinstallation werden nur die neuen Speicherorte berücksichtigt.
- 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.
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.
In der Regel, allerdings mit einigen Ausnahmen, kann in diesem Abschnitt behandelter Inhalt über die Funktion
Kurz gesagt erlaubt eine
In der Regel werden
Die folgende Tabelle enthält eine zusätzliche Spalte mit dem Konfigurationstyp, um den Umfang zu erläutern, in dem eine
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. |
/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:
|
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.
|
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.
|
Für die Anpassung an das aktuelle Modell ist eine manuelle Migration erforderlich. Führen Sie hierzu die folgenden Schritte aus:
|
| 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.
|
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:
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:
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:
Es gibt jedoch Schritte, die nach der Aktualisierung und vor der verzögerten Migration manuell ausgeführt werden müssen:
Einschränkung:
|
| 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:
|
Zur Anpassung an das aktuelle Modell muss das unter folgendem Link verfügbare Skript ausgeführt werden:
|
| 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:
Ä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:
|
| 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:
|
| 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.
|
Sie müssen das Migrationsskript ausführen, damit eine Anpassung an das aktuelle Modell erfolgt. Sie finden das Skript unter folgendem Link:
|
| 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.
|
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 enthalten JavaScript- und CSS-Code, der im Browser verarbeitet wird.
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. |
In den Tabellenzeilen werden alle unterstützten Erweiterbarkeitsmodelle angegeben. In diesem Abschnitt enthaltener Inhalt wird in der Regel nicht erweitert.
| 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/ |
/var/ |
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/ |
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:
|
| 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:
|
| 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:
Die von der Aufgabe betroffenen Speicherorte:
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:
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. |
Twitter™- und Facebook-Beiträge fallen nicht unter die Bedingungen der Creative Commons-Lizenz.