Repository-Neustrukturierung für alle Lösungen in AEM 6.5
Wie auf der übergeordneten Seite Repository-Umstrukturierung in AEM 6.5 beschrieben, sollten Kunden, die auf AEM 6.5 aktualisieren, diese Seite verwenden, um den Arbeitsaufwand zu bewerten, der mit Repository-Änderungen verbunden ist, die sich möglicherweise auf alle Lösungen auswirken. Einige Änderungen erfordern Arbeitsaufwand während des AEM 6.5-Aktualisierungsprozesses, während andere bis zu einem zukünftigen Upgrade verschoben werden können.
Mit der Aktualisierung auf 6.5
Vor der zukünftigen Aktualisierung
Mit der Aktualisierung auf 6.5
ContextHub-Konfigurationen
Ab AEM 6.4 gibt es keine ContextHub-Standardkonfiguration mehr. Daher sollte auf der Stammebene der Site ein cq:contextHubPathproperty
eingestellt werden, um anzugeben, welche Konfiguration verwendet werden soll.
- Navigieren Sie zum Stammverzeichnis der Site.
- Öffnen Sie die Seiteneigenschaften der Stammseite und wählen Sie die Registerkarte Personalisierung aus.
- Geben Sie im Feld ContextHub-Pfad Ihren Pfad zur ContextHub-Konfiguration ein.
Zusätzlich muss bei der ContextHub-Konfiguration das sling:resourceType
aktualisiert werden, um relativ und nicht absolut zu sein.
- Öffnen Sie die Eigenschaften des ContextHub-Konfigurationsknotens in CRX DE Lite, z. B.
/apps/settings/cloudsettings/legacy/contexthub
- Ändern Sie
sling:resourceType
von /libs/granite/contexthub/cloudsettings/components/baseconfiguration
in granite/contexthub/cloudsettings/components/baseconfiguration
Der sling:resourceType
-Pfad der ContextHub-Konfiguration muss relativ sein.
Workflow-Modelle
Vorheriger Speicherort |
/etc/workflow/models |
Neuer Speicherort |
/libs/settings/workflow/models /conf/global/settings/workflow/models /var/workflow/models |
Leitfaden für die Neustrukturierung |
Alle neuen oder geänderten Workflow-Modelle müssen nach /conf/global/workflow/models migriert werden.
- Stellen Sie die geänderten Workflow-Modelle in einer lokalen AEM 6.5-Entwicklungsinstanz bereit, sodass sie im vorherigen Speicherort vorhanden sind.
- Bearbeiten Sie das Workflow-Modell unter Verwendung des Editors für AEM Workflow-Modelle unter „AEM > Tools > Workflow > Modelle“.
- Migration von modifizierten, von AEM bereitgestellten Workflow-Modellen
- Öffnen Sie den Editor für Workflow-Modelle, ändern Sie die Browser-URL und ersetzen Sie das Pfadsegment /libs/settings/workflow/models durch /etc/workflow/models.
- Ändern Sie beispielsweise: http://localhost:4502/editor.html/libs/settings/workflow/models/dam/update_asset.html zu http://localhost:4502/editor.html/etc/workflow/models/dam/update_asset.html
- Aktivieren Sie den Bearbeitungsmodus im Editor für Workflow-Modelle, wodurch die Definition des Workflow-Modells nach /conf/global/workflow/models kopiert wird.
- Tippen Sie auf die Synchronisierungsschaltfläche, um die Änderungen am Laufzeit-Workflow-Modell unter /var/workflow/models zu synchronisieren.
- Exportieren Sie sowohl das Workflow-Modell (/conf/global/workflow/models/<Workflow-Modell>?lang=de) als auch das Laufzeit-Workflow-Modell (/var/workflow/models/<Workflow-Modell>?lang=de) und integrieren Sie beide in das AEM-Projekt.
- Zum Beispiel, exportieren Sie:
/config/settings/workflow/models/dam/my_workflow_model und
/var/workflow/models/dam/my_workflow_model
|
Hinweise |
Die Auflösung des Workflow-Modells geschieht in der folgenden Reihenfolge:
/conf/global/settings/workflow/models
/libs/settings/workflow/models
/etc/workflow/models
Daher müssen alle Anpassungen zu den von AEM bereitgestellten Workflow-Modellen, die am vorherigen Speicherort bestehen bleiben, nach /conf/global/settings/workflow/models verschoben werden, wenn sie beibehalten werden sollen. Andernfalls werden sie durch die von AEM bereitgestellte Definition des Workflow-Modells in /libs/settings/workflow/models ersetzt. |
Workflow-Instanzen
Vorheriger Speicherort |
/etc/workflow/instances |
Neuer Speicherort |
/var/workflow/instances |
Leitfaden für die Neustrukturierung |
Für die Anpassung an den neuen Speicherort ist keine Aktion erforderlich. Bisherige Workflow-Instanzen können weiterhin am vorherigen Speicherort erhalten bleiben und neue Workflow-Instanzen werden am neuen Speicherort erstellt. |
Hinweise |
Alle expliziten Pfadverweise in
custom
-Code zum vorherigen Speicherort sollte auch den neuen Speicherort berücksichtigen. Dies ist zu empfehlen, denn dieser Code wurde für die Verwendung in Verbindung mit AEM-Workflow-APIs überarbeitet. |
Workflow-Starter
Vorheriger Speicherort |
/etc/workflow/launcher/config |
Neuer Speicherort |
/libs/settings/workflow/launcher/config /conf/global/settings/workflow/launcher/config |
Leitfaden für die Neustrukturierung |
Alle neuen oder geänderten Workflow-Starter müssen zu /conf/global/workflow/launcher/config migriert werden.
- Kopieren Sie alle neuen oder geänderten Workflow-Starter Konfigurationen vom bisherigen Speicherort an den neuen Speicherort (
/conf/global ).
|
Hinweise |
Die Auflösung des Workflow-Starters geschieht in der folgenden Reihenfolge:
/conf/global/settings/workflow/launcher
/libs/settings/workflow/launcher
/etc/workflow/launcher
Daher müssen alle Anpassungen AEM bereitgestellten Workflow-Starters, die im vorherigen Speicherort beibehalten werden, an den neuen Speicherort (/conf/global/settings/workflow/launcher , wenn sie beibehalten werden sollen, verschoben werden. Andernfalls werden sie durch die AEM bereitgestellte Workflow-Starter-Definition in /libs/settings/workflow/launcher ersetzt. |
Workflow-Skripte
Vorheriger Speicherort |
/etc/workflow/scripts |
Neuer Speicherort |
/libs/workflow/scripts /apps/workflow/scripts |
Leitfaden für die Neustrukturierung |
Alle neuen oder geänderten Workflow-Skripte müssen an den neuen Speicherort migriert werden und referenzierte Workflow-Modelle müssen migriert werden, sodass sie den neuen Speicherort enthalten.
- Kopieren Sie jedes neue oder modifizierte Workflow-Skript vom vorherigen Speicherort zum neuen Speicherort.
/apps/workflow/scripts sollten in SCM beibehalten werden.
- Aktualisieren Sie alle Verweise auf die Workflow-Skripte in den Workflow-Modellen am vorherigen Speicherort, sodass sie auf die neuen Speicherorte verweisen.
|
Hinweise |
AEM 6.4 SP1 macht es nach der Freigabe so, dass diese Umstrukturierung bis 6.5 verschoben werden kann
upgrade
. Wenn Sie auf AEM 6.4 aktualisieren möchten, bevor AEM 6.4 SP1 veröffentlicht wurde, sollte diese Neustrukturierung als Teil der Aktualisierung ausgeführt werden. Ohne das Bearbeiten und Abspeichern von Workflow-Schritten werden die Referenz-Skripte vom vorherigen Speicherort vollständig aus den Workflow-Schritten entfernt und nur die Workflow-Schritte vom neuen Speicherort sind in der Dropdown-Liste „Skriptauswahl“ verfügbar. |
Vor der zukünftigen Aktualisierung
ContextHub-Konfigurationen
Vorheriger Speicherort |
/etc/cloudsettings |
Neuer Speicherort |
/libs/settings/cloudsettings /conf/global/settings/cloudsettings /conf/<tenant>/settings/cloudsettings |
Leitfaden für die Neustrukturierung |
Alle neuen oder modifizierten ContextHub Konfigurationen müssen an den neuen Speicherort migriert werden und die referenzierenden AEM Sites-Seiten müssen so aktualisiert werden, dass sie den neuen Speicherort enthalten.
- Kopieren Sie alle neuen oder modifizierten ContextHub-Konfigurationen vom vorherigen Speicherort zum neuen Speicherort.
- Verknüpfen Sie die entsprechenden AEM-Konfigurationen mit den AEM-Inhaltshierarchien.
- Die Seitenhierarchien von AEM Sites über AEM Sites > Seite > Seiteneigenschaften > Erweitert > Cloud-Konfiguration.
- Trennen Sie alle migrierten ContextHub-Konfigurationen von den oben aufgeführten AEM-Inhaltshierarchien.
|
Hinweise |
Nicht zutreffend |
Klassische Designs für Cloud-Services
Vorheriger Speicherort |
/etc/designs/cloudservices |
Neuer Speicherort |
/libs/settings/wcm/designs/cloudservices /apps/settings/wcm/designs/cloudservices |
Leitfaden für die Neustrukturierung |
Für alle Designs, die in SCM verwaltet werden und in die nicht zur Laufzeit über Design-Dialogfelder geschrieben wird.
- Kopieren Sie die Designs vom bisherigen Speicherort an den neuen Speicherort (
/apps ).
- Wandeln Sie die gesamten CSS-, JavaScript- und statischen Ressourcen im Design in eine Client-Bibliothek mit
allowProxy = true um.
- Aktualisieren Sie die Verweise auf den vorherigen Speicherort in
cq
:
designPath
-Eigenschaft.
- Aktualisieren Sie alle Seiten, die auf den vorherigen Speicherort verweisen, sodass sie die neue Kategorie der Client-Bibliothek verwenden (dies erfordert auf der Seite eine Aktualisierung des Implementierungscodes).
- Aktualisieren Sie AEM Dispatcher-Regeln, um die Unterstützung für Client-Bibliotheken über das Proxy-Servlet /etc.clientlibs/... zuzulassen .
Für alle Designs, die NICHT in SCM verwaltet werden und die über Design-Dialogfelder zur Laufzeit angepasst werden.
- Entfernen Sie keine bearbeitbaren Designs aus
/etc .
|
Hinweise |
Nicht zutreffend |
Klassische Dashboard-Designs
Vorheriger Speicherort |
/etc/designs/dashboards |
Neuer Speicherort |
/libs/settings/wcm/designs/dashboards /apps/settings/wcm/designs/dashboards |
Leitfaden für die Neustrukturierung |
Für alle Designs, die in SCM verwaltet werden und in die nicht zur Laufzeit über Design-Dialogfelder geschrieben wird.
- Kopieren Sie die Designs vom bisherigen Speicherort an den neuen Speicherort (/apps?lang=de).
- Wandeln Sie die gesamten CSS-, JavaScript- und statischen Ressourcen im Design in eine Client-Bibliothek mit
allowProxy = true um.
- Aktualisieren Sie die Verweise auf den vorherigen Speicherort im
cq
:
designPath
-Eigenschaft.
- Aktualisieren Sie alle Seiten, die auf den vorherigen Speicherort verweisen, sodass sie die neue Kategorie der Client-Bibliothek verwenden (dies erfordert auf der Seite eine Aktualisierung des Implementierungscodes).
- Aktualisieren Sie AEM Dispatcher-Regeln, um die Unterstützung für Client-Bibliotheken über das Proxy-Servlet /etc.clientlibs/... zuzulassen .
Für alle Designs, die NICHT in SCM verwaltet werden und die über Design-Dialogfelder zur Laufzeit angepasst werden.
- Entfernen Sie keine bearbeitbaren Designs aus
/etc .
|
Hinweise |
Nicht zutreffend |
Klassische Bericht-Designs
Vorheriger Speicherort |
/etc/designs/reports |
Neuer Speicherort |
/libs/settings/wcm/designs/reports /apps/settings/wcm/designs/reports |
Leitfaden für die Neustrukturierung |
Für alle Designs, die in SCM verwaltet werden und in die nicht zur Laufzeit über Design-Dialogfelder geschrieben wird.
- Kopieren Sie die Designs vom bisherigen Speicherort an den neuen Speicherort (/apps?lang=de).
- Wandeln Sie die gesamten CSS-, JavaScript- und statischen Ressourcen im Design in eine Client-Bibliothek mit
allowProxy = true um.
- Aktualisieren Sie die Verweise auf den vorherigen Speicherort im
cq
:
designPath
-Eigenschaft.
- Aktualisieren Sie alle Seiten, die auf den vorherigen Speicherort verweisen, sodass sie die neue Kategorie der Client-Bibliothek verwenden (dies erfordert auf der Seite eine Aktualisierung des Implementierungscodes).
- Aktualisieren Sie AEM Dispatcher-Regeln, um die Unterstützung für Client-Bibliotheken über das Proxy-Servlet /etc.clientlibs/... zuzulassen .
Für alle Designs, die NICHT in SCM verwaltet werden und die über Design-Dialogfelder zur Laufzeit angepasst werden.
- Entfernen Sie keine bearbeitbaren Designs aus
/etc .
|
Hinweise |
Nicht zutreffend |
Standard-Designs
Vorheriger Speicherort |
/etc/designs/default |
Neuer Speicherort |
/libs/settings/wcm/designs/default /apps/settings/wcm/designs/default |
Leitfaden für die Neustrukturierung |
Für alle Designs, die in SCM verwaltet werden und in die nicht zur Laufzeit über Design-Dialogfelder geschrieben wird.
- Kopieren Sie die Designs vom bisherigen Speicherort an den neuen Speicherort (/apps?lang=de).
- Wandeln Sie die gesamten CSS-, JavaScript- und statischen Ressourcen im Design in eine Client-Bibliothek mit
allowProxy = true um.
- Aktualisieren Sie die Verweise auf den vorherigen Speicherort im
cq
:
designPath
-Eigenschaft.
- Aktualisieren Sie alle Seiten, die auf den vorherigen Speicherort verweisen, sodass sie die neue Kategorie der Client-Bibliothek verwenden (dies erfordert auf der Seite eine Aktualisierung des Implementierungscodes).
- Aktualisieren Sie AEM Dispatcher-Regeln, um die Unterstützung für Client-Bibliotheken über das Proxy-Servlet /etc.clientlibs/... zuzulassen .
Für alle Designs, die NICHT in SCM verwaltet werden und die über Design-Dialogfelder zur Laufzeit angepasst werden.
- Entfernen Sie keine bearbeitbaren Designs aus
/etc .
|
Hinweise |
Nicht zutreffend |
Adobe DTM-JavaScript-Endpunkt
Vorheriger Speicherort |
/etc/clientlibs/dtm |
Neuer Speicherort |
/var/cq/dtm/clientlibs |
Leitfaden für die Neustrukturierung |
Es ist keine Aktion erforderlich. Der vorherige öffentliche Speicherort fungiert als Proxy-Endpunkt für den privaten neuen Speicherort. |
Hinweise |
Nicht zutreffend |
Adobe DTM-Web-Hook-Endpunkt
Vorheriger Speicherort |
/etc/dtm-hook |
Neuer Speicherort |
/var/cq/dtm/web-hook |
Leitfaden für die Neustrukturierung |
Es ist keine Aktion erforderlich. Der vorherige öffentliche Speicherort fungiert als Proxy-Endpunkt für den privaten neuen Speicherort. |
Hinweise |
Nicht zutreffend |
Aufgaben des Posteingangs
Vorheriger Speicherort |
/etc/taskmanagement |
Neuer Speicherort |
/var/taskmanagement |
Leitfaden für die Neustrukturierung |
Verwenden Sie die Wartungsaufgabe zum Bereinigen des Posteingangs, um alte Aufgaben vom vorherigen Speicherort zu entfernen. |
Hinweise |
Für die Migration von Aufgaben an den neuen Speicherort sind keine Maßnahmen erforderlich.
- Aufgaben, die am vorherigen Speicherort vorhanden sind, sind weiterhin verfügbar und funktionieren.
- Neue Aufgaben werden im neuen Speicherort erstellt.
|
Blueprint-Konfigurationen für den Multi-Site-Manager
Vorheriger Speicherort |
/etc/blueprints |
Neuer Speicherort |
/libs/msm /apps/msm |
Leitfaden für die Neustrukturierung |
- Kopieren Sie benutzerdefinierte Konfigurationen von
/etc/blueprints nach /apps/msm .
- Remove
/etc/blueprints .
|
Hinweise |
Nicht zutreffend |
Dashboard-Gadget-Konfigurationen für AEM-Projekte
Vorheriger Speicherort |
/etc/projects/dashboard/gadgets |
Neuer Speicherort |
/libs/cq/core/content/projects/dashboard/gadgets /apps/cq/core/content/projects/dashboard/gadgets |
Leitfaden für die Neustrukturierung |
Alle neuen oder geänderten AEM Project Dashboard Gadget-Konfigurationen müssen an den neuen Speicherort (/apps ) migriert werden.
- Kopieren Sie alle neuen oder modifizierten Dashboard-Gadget-Konfigurationen für AEM-Projekte vom vorherigen an den neuen Speicherort (
/apps ).
- Kopieren Sie nicht die nicht geänderten AEM Dashboard Gadget-Konfigurationen von Projekten, da diese nun am neuen Speicherort (
/libs ) vorhanden sind.
- Aktualisieren Sie alle AEM-Projektvorlagen, die auf den vorherigen Speicherort verweisen, sodass sie auf den neuen Speicherort verweisen.
|
Hinweise |
Wenn das AEM 6.4-Kompatibilitätspaket verwendet wird, muss die Anpassung des Repositorys zum Zeitpunkt der Entfernung des Kompatibilitätspaket durchgeführt werden. |
E-Mail-Vorlage für die Replikationsbenachrichtigung
Vorheriger Speicherort |
/etc/notification/email/default/com.day.cq.replication |
Neuer Speicherort |
/libs/settings/notification-templates/com.day.cq.replication /apps/settings/notification-templates/com.day.cq.replication |
Leitfaden für die Neustrukturierung |
Alle neuen oder geänderten E-Mail-Vorlagen für Replikationsbenachrichtigungen müssen an den neuen Speicherort (/apps ) migriert werden.
- Kopieren Sie alle neuen oder modifizierten E-Mail-Vorlagen für die Replikationsbenachrichtigung vom vorherigen Speicherort an den neuen Speicherort (
/apps ).
- Entfernen Sie alle migrierten E-Mail-Vorlagen für die Replikationsbenachrichtigung vom vorherigen Speicherort.
|
Hinweise |
Die einzigen neuen unterstützten E-Mail-Vorlagen für die Replikationsbenachrichtigung sind solche, die neue Lokalisationen unterstützen. Die Auflösung für die E-Mail-Vorlage für die Replikationsbenachrichtigung geschieht in der folgenden Reihenfolge:
/etc/notification/email/default/com.day.cq.replication
/apps/settings/notification-templates/com.day.cq.replication
/libs/settings/notification-templates/com.day.cq.replication
|
Vorheriger Speicherort |
/etc/tags |
Neuer Speicherort |
/content/cq:tags |
Leitfaden für die Neustrukturierung |
Alle Tags müssen zu /content/cq:tags migriert werden.
- Kopieren Sie alle Tags vom vorherigen Speicherort an den neuen Speicherort.
- Entfernen Sie alle Tags aus dem vorherigen Speicherort.
- Starten Sie über die AEM Web-Konsole das Day Communique 5 Tagging OSGi-Bundle unter https://serveraddress:serverport/system/console/bundles/com.day.cq.cq-tagging neu, damit AEM erkennen kann, dass die neue Position Inhalte enthält und verwendet werden sollte.
|
Hinweise |
Beim Neustart des Day Communique Tagging OSGi-Bundles wird der neue Speicherort nur als Tag-Stammverzeichnis registriert, wenn der vorherige Speicherort leer ist. Verweise auf den vorherigen Speicherort bleiben nach der Migration an den neuen Speicherort weiterhin für alle Funktionen erhalten, die die TagManager-API von AEM für die Tag-Auflösung unterstützen. Jeder benutzerspezifische Code, der explizit auf den Pfad /etc/tags verweist, muss auf /content/ aktualisiert werden
cq
:tags
oder vorzugsweise umgeschrieben, um die TagManager Java-API gemeinsam mit dieser Migration zu nutzen. |
Cloud-basierte Übersetzungsdienste
Vorheriger Speicherort |
/etc/cloudservices/translation |
Neuer Speicherort |
/libs/settings/cloudconfigs/translation/translationcfg /apps/settings/cloudconfigs/translation/translationcfg /conf/global/settings/cloudconfigs/translation/translationcfg /conf/<tenant>/settings/cloudconfigs/translation/translationcfg |
Leitfaden für die Neustrukturierung |
Neue Cloud Services für Übersetzungen müssen an den neuen Speicherort (/apps , /conf/global oder /conf/<tenant> ) migriert werden.
- Migrieren Sie vorhandene Konfigurationen im bisherigen Speicherort an den neuen Speicherort.
- Erstellen Sie manuell neue Konfigurationen der Cloud-basierten Übersetzungsdienste über die AEM-Benutzeroberfläche unter Tools > Cloud-Dienste > Übersetzungs-Cloud-Services.
ODER
- Kopieren Sie alle neuen Konfigurationen von Translation Cloud Services vom vorherigen Speicherort zum neuen Speicherort (
/apps , /conf/global oder /conf/<tenant> ).
- Verknüpfen Sie die entsprechenden AEM-Konfigurationen mit den AEM-Inhaltshierarchien.
- Die Seitenhierarchien von AEM Sites über AEM Sites > Seite > Seiteneigenschaften > Erweitert > Cloud-Konfiguration.
- Hierarchien von AEM-Experience-Fragments über AEM-Experience-Fragments > Experience Fragments > Eigenschaften > Cloud-Services > Cloud-Konfiguration.
- Ordnerhierarchien von AEM-Experience-Fragments über AEM-Experience-Fragments > Ordner > Eigenschaften > Cloud-Services > Cloud-Konfiguration.
- AEM Assets-Ordnerhierarchien über AEM Assets > Ordner > Ordnereigenschaften > Registerkarte "Cloud Services"> "Konfiguration".
- AEM Projekte über AEM Projekte > Projekt > Projekteigenschaften > Erweiterte Registerkarte > Cloud-Konfiguration.
- Trennen Sie alle migrierten alten Cloud-basierten Übersetzungsdienste von den oben genannten AEM-Inhaltshierarchien.
|
Hinweise |
Die Auflösung der Cloud-basierten Übersetzungsdienste geschieht in der folgenden Reihenfolge:
/conf/<tenant>/settings/cloudconfigs/translations/translationcfg
/conf/global/settings/cloudconfigs/translations/translationcfg
/apps/settings/cloudconfigs/translations/translationcfg
/libs/settings/cloudconfigs/translations/translationcfg
Migrierte Cloud-basierte Übersetzungsdienste müssen mit AEM 6.4 kompatibel sein. |
Übersetzungssprachen
Vorheriger Speicherort |
/etc/translation/supportedLanguages |
Neuer Speicherort |
/libs/settings/translation/supportedLanguages /apps/settings/translation/supportedLanguages |
Leitfaden für die Neustrukturierung |
Alle neuen oder modifizierten Definitionen für Übersetzungssprachen erfordern eine Migration der Definitionen für Übersetzungssprachen an den neuen Speicherort (/apps ).
- Wenn an den Definitionen für die Übersetzungssprache Ergänzungen oder Änderungen vorgenommen wurden, kopieren Sie alle Übersetzungssprachdefinitionen vom vorherigen Speicherort an den neuen Speicherort (
/apps ).
|
Hinweise |
Die Auflösung des Pfads für Übersetzungssprachen geschieht in der folgenden Reihenfolge:
/etc/translation/supportedLanguages
/apps/settings/translation/supportedLanguage
/libs/settings/translation/supportedLanguages
Diese Lösung unterstützt kein Zusammenführen von Überlagerungen, der aufgelöste Pfad muss also alle unterstützten Sprachen enthalten und übernimmt nicht unterstützte Sprachen von übergeordneten Auflösungen. |
Übersetzungsregeln
Vorheriger Speicherort |
/etc/workflow/models/translation/translation_rules.xml |
Neuer Speicherort |
/libs/settings/translation/rules/translation_rules.xml /apps/settings/translation/rules/translation_rules.xml /conf/global/settings/translation/rules/translation_rules.xml |
Leitfaden für die Neustrukturierung |
Eine geänderte XML-Datei für Übersetzungsregeln muss an den neuen Speicherort (/apps oder /conf/global ) migriert werden. 1. Kopieren Sie die modifizierte XML-Datei für Übersetzungsregeln vom bisherigen Speicherort an den neuen Speicherort. |
Hinweise |
Die XML-Auflösung der Replikation der Übersetzungsregeln geschieht in der folgenden Reihenfolge:
/conf/global/settings/translation/rules/translation_rules.xml
/apps/settings/translation/rules/translation_rules.xml
/etc/workflow/models/translation/translation_rules.xml
/libs/settings/translation/rules/translation_rules.xml
|
Vorheriger Speicherort |
/etc/designs/translation/translationwidget |
Neuer Speicherort |
/libs/settings/wcm/designs/translation/translationwidget /apps/settings/wcm/designs/translation/translationwidget |
Leitfaden für die Neustrukturierung |
Für alle Designs, die in SCM verwaltet werden und in die nicht zur Laufzeit über Design-Dialogfelder geschrieben wird.
- Kopieren Sie die Designs vom bisherigen Speicherort an den neuen Speicherort (/apps?lang=de).
- Wandeln Sie die gesamten CSS-, JavaScript- und statischen Ressourcen im Design in eine Client-Bibliothek mit
allowProxy = true um.
- Aktualisieren Sie die Verweise auf den vorherigen Speicherort im
cq
:
designPath
-Eigenschaft.
- Aktualisieren Sie alle Seiten, die auf den vorherigen Speicherort verweisen, sodass sie die neue Kategorie der Client-Bibliothek verwenden (dies erfordert auf der Seite eine Aktualisierung des Implementierungscodes).
- Aktualisieren Sie AEM Dispatcher-Regeln, um die Unterstützung für Client-Bibliotheken über das Proxy-Servlet /etc.clientlibs/... zuzulassen .
Für alle Designs, die NICHT in SCM verwaltet werden und die über Design-Dialogfelder zur Laufzeit angepasst werden.
- Entfernen Sie keine bearbeitbaren Designs aus
/etc .
|
Hinweise |
Nicht zutreffend |
Web-Konsole für Strukturaktivierung
Vorheriger Speicherort |
/etc/replication/treeactivation |
Neuer Speicherort |
/libs/replication/treeactivation |
Leitfaden für die Neustrukturierung |
Es ist keine Aktion erforderlich. |
Hinweise |
Die Web-Konsole für die Strukturaktivierung ist jetzt über Tools > Bereitstellung > Replikation > Tree aktivieren verfügbar. |
Connector-Cloud-Services für Übersetzungsanbieter
Vorheriger Speicherort |
/etc/cloudservices/<vendor> |
Neuer Speicherort |
/libs/settings/cloudconfigs/translation/<vendor> /apps/settings/cloudconfigs/translation/<vendor>
/conf/global/settings/cloudconfigs/translation/<vendor>
/conf/<tenant>/settings/cloudconfigs/translation/<vendor> |
Leitfaden für die Neustrukturierung |
Alle neuen Cloud Services des Übersetzungs-Connectors müssen an den neuen Speicherort (/apps , /conf/global oder /conf/<tenant> ) migriert werden.
- Migrieren Sie vorhandene Konfigurationen im bisherigen Speicherort an den neuen Speicherort.
- Erstellen Sie manuell neue Konfigurationen der Connector-Cloud-Services für Übersetzungsanbieter über die AEM-Benutzeroberfläche unter Tools > Cloud-Dienste > Übersetzungs-Cloud-Services.
ODER
- Kopieren Sie alle neuen Konfigurationen des Übersetzungs-Connector-Cloud Services vom vorherigen Speicherort an den neuen Speicherort (
/apps , /conf/global oder /conf/<tenant> ).
- Verknüpfen Sie die entsprechenden AEM-Konfigurationen mit den AEM-Inhaltshierarchien.
- Die Seitenhierarchien von AEM Sites über AEM Sites > Seite > Seiteneigenschaften > Erweitert > Cloud-Konfiguration.
- Hierarchien von AEM-Experience-Fragments über AEM-Experience-Fragments > Experience Fragments > Eigenschaften > Cloud-Services > Cloud-Konfiguration.
- Ordnerhierarchien von AEM-Experience-Fragments über AEM-Experience-Fragments > Ordner > Eigenschaften > Cloud-Services > Cloud-Konfiguration.
- AEM Assets-Ordnerhierarchien über AEM Assets > Ordner > Ordnereigenschaften > Registerkarte "Cloud Services"> "Konfiguration".
- AEM Projekte über AEM Projekte > Projekt > Projekteigenschaften > Erweiterte Registerkarte > Cloud-Konfiguration.
- Trennen Sie alle migrierten alten Cloud-basierten Übersetzungsdienste von den oben genannten AEM-Inhaltshierarchien.
|
Hinweise |
Die Auflösung der Cloud-basierten Übersetzungsdienste geschieht in der folgenden Reihenfolge:
/conf/<tenant>/settings/cloudconfigs/translations/<vendor>
/conf/global/settings/cloudconfigs/translations/<vendor>
/apps/settings/cloudconfigs/translations/<vendor>
/libs/settings/cloudconfigs/translations/<vendor>
|
E-Mail-Vorlagen für die Workflow-Benachrichtigung
Vorheriger Speicherort |
/etc/workflow/notification |
Neuer Speicherort |
/libs/settings/workflow/notification /conf/global/settings/workflow/notification |
Leitfaden für die Neustrukturierung |
Alle geänderten E-Mail-Vorlagen für Workflow-Benachrichtigungen müssen an den neuen Speicherort (/conf/global ) migriert werden.
- Kopieren Sie alle modifizierten E-Mail-Vorlagen für die Workflow-Benachrichtigung vom bisherigen Speicherort an den neuen Speicherort.
- Entfernen Sie migrierte E-Mail-Vorlagen für die Workflow-Benachrichtigung vom vorherigen Speicherort.
|
Hinweise |
Die Auflösung für die E-Mail-Vorlage für die Workflow-Benachrichtigung geschieht in der folgenden Reihenfolge:
/etc/workflow/notification
/conf/global/settings/workflow/notification
/libs/settings/workflow/notification
|
Workflow-Pakete
Vorheriger Speicherort |
/etc/workflow/packages |
Neuer Speicherort |
/var/workflow/packages |
Leitfaden für die Neustrukturierung |
Bestehende Workflow-Pakete sollten vom vorherigen Speicherort an den neuen Speicherort migriert werden.
- Entfernen Sie alle Workflow-Pakete vom vorherigen Speicherort, die durch andere Inhalte nicht referenziert werden und auch sonst nicht benötigt werden.
- Verschieben Sie alle Workflow-Pakete an den vorherigen Speicherort, die nicht durch andere Inhalte referenziert werden, aber am neuen Speicherort benötigt werden.
- Belassen Sie alle Workflow-Pakete, auf die andere Inhalte verweisen, am vorherigen Speicherort.
|
Hinweise |
Workflow-Pakete, die über die Miscadmin-Konsole in der klassischen Benutzeroberfläche erstellt wurden, verbleiben am vorherigen Speicherort, während alle anderen am neuen Speicherort gespeichert werden. Die Workflow-Pakete, die entweder am vorherigen oder am neuen Speicherort gespeichert sind, können über die Miscadmin-Konsole in der klassischen Benutzeroberfläche verwaltet werden. |
Materialien auf adobe.com