Repository-Neustrukturierung für alle Lösungen in AEM 6.5
Wie auf der übergeordneten Seite Repository-Neustrukturierung in AEM 6.5 beschrieben, sollten Kundinnen und Kunden, die auf AEM 6.5 aktualisieren, diese Seite verwenden, um den Arbeitsaufwand im Zusammenhang mit Repository-Neustrukturierungen einzuschätzen, die sich auf alle Lösungen auswirken könnten. Einige Änderungen erfordern einen Arbeitsaufwand während des Upgrades auf AEM 6.5, während andere auf eine zukünftige Aktualisierung verschoben werden können.
Mit der Aktualisierung auf 6.5
Vor einem künftigen Upgrade
Mit der Aktualisierung auf 6.5
ContextHub-Konfigurationen
Ab AEM 6.4 gibt es keine ContextHub-Standardkonfiguration mehr. Daher muss auf der Stammverzeichnisebene der Site cq:contextHubPathproperty
festgelegt 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.
Außerdem muss in der ContextHub-Konfiguration in sling:resourceType
der absolute Pfad in einen relativen Pfad geändert werden.
- Ö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 mit AEM Workflow-Modell-Editor unter AEM > Tools > Workflow > Modelle.
- Beim Migrieren von modifizierten, AEM bereitgestellten Workflow-Modellen
- Wenn der Workflow-Modell-Editor geöffnet ist, ändern Sie die Adresse des Browsers 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 in http://localhost:4502/editor.html/etc/workflow/models/dam/update_asset.html
- Aktivieren Sie den Bearbeitungsmodus im Workflow-Modell-Editor, der die Definition des Workflow-Modells nach /conf/global/workflow/models kopiert.
- Wählen Sie die Schaltfläche Synchronisieren , um die Änderungen mit dem Laufzeitarbeitsmodell unter /var/workflow/models zu synchronisieren.
- Exportieren Sie beide Workflow-Modelle (/conf/global/workflow/models/<workflow-model>?lang=de) und das Laufzeitarbeitsablaufmodell (/var/workflow/models/<workflow-model>?lang=de) und in das AEM Projekt integrieren.
- Beispiel: export:
/conf/global/settings/workflow/models/dam/my_workflow_model und
/var/workflow/models/dam/my_workflow_model
|
Anmerkungen |
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 AEM bereitgestellten Workflow-Modelle, die am vorherigen Speicherort beibehalten werden, nach /conf/global/settings/workflow/models verschoben werden, wenn sie beibehalten werden sollen. Andernfalls werden sie durch die AEM bereitgestellte Workflow-Modelldefinition in /libs/settings/workflow/models ersetzt. |
Workflow-Instanzen
Vorheriger Speicherort |
/etc/workflow/instances |
Neuer Speicherort |
/var/workflow/instances |
Leitfaden für die Neustrukturierung |
Es ist keine Aktion erforderlich, um den neuen Speicherort anzupassen. Historische Workflow-Instanzen können sicher im vorherigen Speicherort verbleiben und neue Workflow-Instanzen werden am neuen Speicherort erstellt. |
Anmerkungen |
Alle expliziten Pfadverweise in
custom
-Code zum vorherigen Speicherort sollte auch den neuen Speicherort berücksichtigen. Es wird empfohlen, diesen Code zu überarbeiten, um die AEM Workflow-APIs zu verwenden. |
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 |
Jeder neue oder modifizierte Workflow-Starter muss nach /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 ).
|
Anmerkungen |
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 zu von AEM bereitgestellten Workflow-Startern, die am vorherigen Speicherort bestehen bleiben, an den neuen Speicherort (/conf/global/settings/workflow/launcher ) verschoben werden, wenn sie beibehalten werden sollen. Andernfalls werden sie durch die von AEM bereitgestellte Definition des Workflow-Starters 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 modifizierten Workflow-Skripte müssen an den neuen Speicherort migriert werden und die referenzierenden Workflow-Modelle müssen entsprechend dem neuen Speicherort aktualisiert werden.
- Kopieren Sie alle neuen oder modifizierten Workflow-Skripte vom vorherigen Speicherort an den neuen Speicherort.
/apps/workflow/scripts sollte in SCM gepflegt werden.
- Aktualisieren Sie alle Verweise auf die Workflow-Skripte in den Workflow-Modellen am vorherigen Speicherort, sodass sie auf die neuen Speicherorte verweisen.
|
Anmerkungen |
Nach der Veröffentlichung von AEM 6.4 SP1 ist es möglich, die Restrukturierung bis Version 6.5 zu verschieben
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. Andernfalls wird beim Bearbeiten und Speichern von Workflow-Schritten, die auf Skripte am vorherigen Speicherort verweisen, der Workflow-Skript-Verweis vollständig aus dem Workflow-Schritt entfernt. In der Dropdown-Liste für die Skriptauswahl sind nur Workflow-Skripte an neuen Speicherorten verfügbar. |
Vor einem künftigen Upgrade
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 entsprechend dem neuen Speicherort aktualisiert werden.
- Kopieren Sie alle neuen oder modifizierten ContextHub-Konfigurationen vom vorherigen Speicherort an den neuen Speicherort.
- Verknüpfen Sie die entsprechenden AEM-Konfigurationen mit den AEM Inhaltshierarchien.
- AEM Sites-Seitenhierarchien über AEM Sites > Seite > Seiteneigenschaften > Erweiterte Registerkarte > Cloud-Konfiguration.
- Trennen Sie alle migrierten älteren ContextHub-Konfigurationen von den oben AEM Inhaltshierarchien.
|
Anmerkungen |
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 Verweise auf den vorherigen Speicherort in der Eigenschaft
cq
:
designPath
.
- 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 Implementierungs-Codes).
- Aktualisieren Sie AEM Dispatcher-Regeln, um die Unterstützung für Client-Bibliotheken über das Proxy-Servlet /etc.clientlibs/... zuzulassen. Proxy-Servlet.
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 .
|
Anmerkungen |
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 vorherigen 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 Verweise auf den vorherigen Speicherort in der Eigenschaft
cq
:
designPath
.
- 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 Implementierungs-Codes).
- Aktualisieren Sie AEM Dispatcher-Regeln, um die Unterstützung für Client-Bibliotheken über das Proxy-Servlet /etc.clientlibs/... zuzulassen. Proxy-Servlet.
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 .
|
Anmerkungen |
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 vorherigen 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 Verweise auf den vorherigen Speicherort in der Eigenschaft
cq
:
designPath
.
- 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 Implementierungs-Codes).
- Aktualisieren Sie AEM Dispatcher-Regeln, um die Unterstützung für Client-Bibliotheken über das Proxy-Servlet /etc.clientlibs/... zuzulassen. Proxy-Servlet.
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 .
|
Anmerkungen |
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 vorherigen 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 Verweise auf den vorherigen Speicherort in der Eigenschaft
cq
:
designPath
.
- 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 Implementierungs-Codes).
- Aktualisieren Sie AEM Dispatcher-Regeln, um die Unterstützung für Client-Bibliotheken über das Proxy-Servlet /etc.clientlibs/... zuzulassen. Proxy-Servlet.
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 .
|
Anmerkungen |
Nicht zutreffend |
Adobe DTM-JavaScript-Endpunkt
Vorheriger Speicherort |
/etc/clientlibs/dtm |
Neuer Speicherort |
/var/cq/dtm/clientlibs |
Leitfaden für die Neustrukturierung |
Keine Aktion erforderlich. Der vorherige öffentliche Speicherort dient als Proxy-Endpunkt für den neuen privaten Speicherort. |
Anmerkungen |
Nicht zutreffend |
Adobe DTM-Web-Hook-Endpunkt
Vorheriger Speicherort |
/etc/dtm-hook |
Neuer Speicherort |
/var/cq/dtm/web-hook |
Leitfaden für die Neustrukturierung |
Keine Aktion erforderlich. Der vorherige öffentliche Speicherort dient als Proxy-Endpunkt für den neuen privaten Speicherort. |
Anmerkungen |
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. |
Anmerkungen |
Zum Migrieren von Aufgaben an den neuen Speicherort ist keine Aktion erforderlich.
- Aufgaben, die am vorherigen Speicherort vorhanden sind, sind weiterhin verfügbar und funktionieren.
- Neue Aufgaben werden am 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 .
|
Anmerkungen |
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 modifizierten Dashboard-Gadget-Konfigurationen für AEM-Projekte 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 keine unmodifizierten Dashboard-Gadget-Konfigurationen für AEM-Projekte, da diese bereits am neuen Speicherort (
/libs ) existieren.
- Aktualisieren Sie alle AEM-Projektvorlagen, die auf den vorherigen Speicherort verweisen, sodass sie auf den neuen Speicherort verweisen.
|
Anmerkungen |
Wenn das Kompatibilitätspaket AEM 6.4 angewendet wird, müssen die Aktivitäten zur Repository-Ausrichtung zum Zeitpunkt der Entfernung des Kompatibilitätspakets 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 modifizierten E-Mail-Vorlagen für die Replikationsbenachrichtigung 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.
|
Anmerkungen |
Die einzigen unterstützten neuen E-Mail-Vorlagen für Replikationsbenachrichtigungen sind die Unterstützung neuer Gebietsschemata. Die Auflösung der E-Mail-Vorlage für Replikationsbenachrichtigungen erfolgt 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 nach /content/cq:tags migriert werden.
- Kopieren Sie alle Tags vom vorherigen Speicherort an den neuen Speicherort.
- Entfernen Sie alle Tags vom vorherigen Speicherort.
- Über die AEM-Web-Konsole erfolgt der Neustart des Day Communique 5 Tagging OSGi-Bundles unter https://serveradresse:serverport/system/console/bundles/com.day.cq.cq-tagging, damit AEM erkennt, dass der neue Speicherort Inhalt enthält und verwendet werden sollte.
|
Anmerkungen |
Wenn Sie das OSGi-Bundle Day Communique Tagging neu starten, wird der neue Speicherort nur als Tag-Stamm registriert, wenn der vorherige Speicherort leer ist. Verweise auf den vorherigen Speicherort funktionieren auch nach der Migration zu "Neuer Speicherort"für alle Funktionen, die AEM TagManager-API für die Tag-Auflösung verwenden. Jeder benutzerspezifische Code, der explizit auf den Pfad verweist /etc/tags muss aktualisiert werden auf /content/
cq
:tags
, oder vorzugsweise umgeschrieben, um die TagManager Java-API zusammen mit dieser Migration zu verwenden. |
Übersetzungs-Cloud-Services
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 |
Alle neuen Cloud-basierten Übersetzungsdienste müssen an den neuen Speicherort (/conf/global ,/apps oder /conf/<tenant> ) migriert werden.
- Migrieren Sie vorhandene Konfigurationen am vorherigen Speicherort zum neuen Speicherort.
- Erstellen Sie manuell neue Konfigurationen für Übersetzungs-Cloud Service über die AEM Authoring-Benutzeroberfläche unter Tools > Cloud Service > Übersetzungs-Cloud Service.
ODER
- Kopieren Sie alle neuen Konfigurationen für Cloud-basierte Übersetzungsdienste vom vorherigen Speicherort an den neuen Speicherort (
/conf/global ,/apps oder /conf/<tenant> ).
- Verknüpfen Sie die entsprechenden AEM-Konfigurationen mit den AEM Inhaltshierarchien.
- AEM Sites-Seitenhierarchien über AEM Sites > Seite > Seiteneigenschaften > Registerkarte "Erweitert"> Cloud-Konfiguration.
- AEM von Experience Fragment-Hierarchien über AEM Experience Fragments > Experience Fragment > Eigenschaften > Registerkarte Cloud Service > Cloud-Konfiguration.
- AEM Ordnerhierarchien von Experience Fragment über AEM Experience Fragments > Ordner > Eigenschaften > Registerkarte "Cloud Service"> Cloud-Konfiguration.
- Ordnerhierarchien von AEM Assets über AEM Assets > Ordner > Ordnereigenschaften > Cloud-Services > Konfiguration.
- AEM-Projekte über AEM-Projekte > Projekt > Projekteigenschaften > Erweitert > Cloud-Konfiguration.
- Trennen Sie alle migrierten alten Cloud-basierten Übersetzungsdienste von den oben genannten AEM-Inhaltshierarchien.
|
Anmerkungen |
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 Übersetzungs-Cloud Service 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 ).
- Falls Ergänzungen oder Modifikationen an den Definitionen für Übersetzungssprachen vorgenommen wurden, sollten Sie alle Definitionen für Übersetzungssprachen vom vorherigen Speicherort an den neuen Speicherort (
/apps ) kopieren.
|
Anmerkungen |
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 Auflösung unterstützt keine Zusammenführungsüberlagerung. Das bedeutet, dass der aufgelöste Pfad alle unterstützten Sprachen enthalten muss und unterstützte Sprachen nicht von den Auflösungen mit höherer Reihenfolge übernimmt. |
Ü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 modifizierte 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. |
Anmerkungen |
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 vorherigen 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 Verweise auf den vorherigen Speicherort in der Eigenschaft
cq
:
designPath
.
- 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 Implementierungs-Codes).
- Aktualisieren Sie AEM Dispatcher-Regeln, um die Unterstützung für Client-Bibliotheken über das Proxy-Servlet /etc.clientlibs/... zuzulassen. Proxy-Servlet.
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 .
|
Anmerkungen |
Nicht zutreffend |
Web-Konsole für Strukturaktivierung
Vorheriger Speicherort |
/etc/replication/treeactivation |
Neuer Speicherort |
/libs/replication/treeactivation |
Leitfaden für die Neustrukturierung |
Keine Aktion erforderlich. |
Anmerkungen |
Die Web-Konsole für die Strukturaktivierung ist jetzt über verfügbar. Tools > Bereitstellung > Replikation > Tree aktivieren. |
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 Connector-Cloud-Services für Übersetzungsanbieter müssen an den neuen Speicherort (/conf/global ,/apps oder /conf/<tenant> ) migriert werden.
- Migrieren Sie vorhandene Konfigurationen im vorherigen Speicherort zum neuen Speicherort.
- Erstellen Sie manuell die neuen Konfigurationen des Connector-Cloud Service für Übersetzungsanbieter über die AEM Authoring-Benutzeroberfläche unter Tools > Cloud Service > Übersetzungs-Cloud Service.
ODER
- Kopieren Sie alle neuen Konfigurationen für Connector-Cloud-Services für Übersetzungsanbieter vom vorherigen Speicherort an den neuen Speicherort (
/conf/global , /apps oder /conf/<tenant> ).
- Verknüpfen Sie die entsprechenden AEM-Konfigurationen mit den AEM Inhaltshierarchien.
- AEM Sites-Seitenhierarchien über AEM Sites > Seite > Seiteneigenschaften > Registerkarte "Erweitert"> Cloud-Konfiguration.
- AEM von Experience Fragment-Hierarchien über AEM Experience Fragments > Experience Fragment > Eigenschaften > Registerkarte Cloud Service > Cloud-Konfiguration.
- AEM Ordnerhierarchien von Experience Fragment über AEM Experience Fragments > Ordner > Eigenschaften > Registerkarte "Cloud Service"> Cloud-Konfiguration.
- Ordnerhierarchien von AEM Assets über AEM Assets > Ordner > Ordnereigenschaften > Cloud-Services > Konfiguration.
- AEM-Projekte über AEM-Projekte > Projekt > Projekteigenschaften > Erweitert > Cloud-Konfiguration.
- Trennen Sie alle migrierten alten Cloud-basierten Übersetzungsdienste von den oben genannten AEM-Inhaltshierarchien.
|
Anmerkungen |
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 modifizierten E-Mail-Vorlagen für Workflow-Benachrichtigungen müssen an den neuen Speicherort (/conf/global ) migriert werden.
- Kopieren Sie alle geänderten E-Mail-Vorlagen für Workflow-Benachrichtigungen vom vorherigen Speicherort an den neuen Speicherort.
- Entfernen Sie migrierte E-Mail-Vorlagen für Workflow-Benachrichtigungen vom vorherigen Speicherort.
|
Anmerkungen |
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 |
Vorhandene Workflow-Pakete am vorherigen Speicherort sollten an den neuen Speicherort migriert werden.
- Entfernen Sie alle Workflow-Pakete am vorherigen Speicherort, die nicht durch andere Inhalte referenziert werden und ansonsten nicht erforderlich sind.
- Verschieben Sie alle Workflow-Pakete an den vorherigen Speicherort, die nicht durch andere Inhalte referenziert, aber anderweitig am neuen Speicherort erforderlich sind.
- Belassen Sie alle Workflow-Pakete, die durch andere Inhalte referenziert werden, am vorherigen Speicherort.
|
Anmerkungen |
Workflow-Pakete, die über die Miscadmin Console der klassischen Benutzeroberfläche erstellt wurden, bleiben am vorherigen Speicherort erhalten, während alle anderen am neuen Speicherort beibehalten werden. Workflow-Pakete, die entweder in den vorherigen oder niedrigeren Speicherorten gespeichert sind, können über die Miscadmin Console der klassischen Benutzeroberfläche verwaltet werden. |