Repository-Neustrukturierung für alle Lösungen in AEM 6.4
Wie auf der übergeordneten Seite Repository-Umstrukturierung in AEM 6.4 beschrieben, sollten Kunden, die auf AEM 6.4 aktualisieren, diese Seite verwenden, um den Arbeitsaufwand zu bewerten, der mit Repository-Änderungen verbunden ist, die möglicherweise alle Lösungen beeinträchtigen. Einige Änderungen erfordern einen Arbeitsaufwand während des Aktualisierungsprozesses auf AEM 6.4, während andere bis zu einer Aktualisierung auf 6.5 verschoben werden können.
Mit der Aktualisierung auf 6.4
Vor der Aktualisierung auf 6.5
Mit der Aktualisierung auf 6.4
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.4-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 Aktualisierung auf 6.5
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