Ristrutturazione dell’archivio comune in AEM 6.5
Creato per:
- Amministratore
Come descritto nella pagina padre Ristrutturazione dell’archivio in AEM 6.5, i clienti che eseguono l’aggiornamento a AEM 6.5 devono utilizzare questa pagina per valutare l’impegno di lavoro associato alle modifiche dell’archivio che potrebbero influire su tutte le soluzioni. Alcune modifiche richiedono un impegno di lavoro durante il processo di aggiornamento AEM 6.5, mentre altre possono essere differite fino a un aggiornamento futuro.
Con Aggiornamento 6.5
Prima di un aggiornamento futuro
- Configurazioni ContextHub
- Progettazioni Cloud Service classiche
- Progettazioni dashboard classiche
- Progettazioni report classici
- Progettazioni predefinite
- Endpoint Adobe DTM JavaScript
- Adobe di endpoint per web hook DTM
- Attività casella in entrata
- Configurazioni blueprint per Multi-Site Manager
- Configurazioni gadget dashboard progetti AEM
- Modello e-mail notifica replica
- Tag
- Servizi cloud di traduzione
- Lingue di traduzione
- Regole di traduzione
- Libreria client widget traduzione
- Console Web di attivazione struttura
- Cloud Service di connettori di traduzione fornitore
- Modelli e-mail di notifica flusso di lavoro
Con aggiornamento 6.5
Configurazioni ContextHub
A partire da AEM 6.4, non è presente alcuna configurazione ContextHub predefinita. Pertanto, a livello di directory principale del sito deve essere impostato cq:contextHubPathproperty
per indicare quale configurazione deve essere utilizzata.
- Passa alla directory principale del sito.
- Apri le proprietà della pagina principale e seleziona la scheda Personalization.
- Nel campo Percorso Contexthub immetti il percorso di configurazione ContextHub.
Inoltre, nella configurazione ContextHub, sling:resourceType
deve essere aggiornato per essere relativo e non assoluto.
- Apri le proprietà del nodo di configurazione ContextHub in CRX DE Lite, ad esempio
/apps/settings/cloudsettings/legacy/contexthub
- Cambia
sling:resourceType
da/libs/granite/contexthub/cloudsettings/components/baseconfiguration
agranite/contexthub/cloudsettings/components/baseconfiguration
Ad esempio, sling:resourceType
della configurazione ContextHub deve essere relativo anziché assoluto.
Modelli flusso di lavoro
/etc/workflow/models
/libs/settings/workflow/models
/conf/global/settings/workflow/models
/var/workflow/models
Qualsiasi modello di flusso di lavoro nuovo o modificato deve essere migrato a /conf/global/workflow/models.
-
Distribuire i modelli di flusso di lavoro modificati in un'istanza di sviluppo AEM 6.5 locale, in modo che esistano nel percorso precedente.
-
Modifica il modello di flusso di lavoro utilizzando l’Editor modello di flusso di lavoro dell’AEM in AEM > Strumenti > Flusso di lavoro > Modelli.
-
Durante la migrazione dei modelli di flusso di lavoro AEM modificati
- Con l’Editor modello flusso di lavoro aperto, modifica l’URL dell’indirizzo del browser e sostituisci il segmento di percorso /libs/settings/workflow/models con /etc/workflow/models.
- Ad esempio, modifica: 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
- Con l’Editor modello flusso di lavoro aperto, modifica l’URL dell’indirizzo del browser e sostituisci il segmento di percorso /libs/settings/workflow/models con /etc/workflow/models.
-
Abilita la modalità Modifica nell’Editor modello flusso di lavoro, che copierà la definizione del modello flusso di lavoro in /conf/global/workflow/models.
-
Seleziona il pulsante Sync per sincronizzare le modifiche apportate al modello di flusso di lavoro di runtime in /var/workflow/models.
-
Esporta sia il modello di flusso di lavoro (https://experienceleague.adobe.com/conf/global/workflow/models/<modello-flusso%20di%20lavoro>?lang=it) che il modello di flusso di lavoro di runtime (https://experienceleague.adobe.com/var/workflow/models/<modello-flusso%20di%20lavoro>?lang=it) e integrali nel progetto AEM.
-
Ad esempio, esportare:
/conf/global/settings/workflow/models/dam/my_workflow_model
e/var/workflow/models/dam/my_workflow_model
-
La risoluzione del modello di flusso di lavoro viene eseguita nell'ordine seguente:
/conf/global/settings/workflow/models
/libs/settings/workflow/models
/etc/workflow/models
Pertanto, tutte le personalizzazioni dei modelli di flusso di lavoro forniti dall’AEM che persistono nella posizione Precedente devono essere spostate in /conf/global/settings/workflow/models se devono essere mantenute, altrimenti saranno sostituite dalla definizione del modello di flusso di lavoro fornita dall’AEM in /libs/settings/workflow/models.
Istanze flusso di lavoro
/etc/workflow/instances
/var/workflow/instances
Non è richiesta alcuna azione per l’allineamento con la nuova posizione.
Le istanze storiche dei flussi di lavoro possono continuare a risiedere nella posizione precedente senza problemi e verranno create nuove istanze dei flussi di lavoro nella nuova posizione.
custom
nel percorso precedente deve tenere conto del nuovo percorso. Si consiglia di eseguire il refactoring di questo codice per utilizzare le API del flusso di lavoro AEM.Moduli di avvio per flusso di lavoro
/etc/workflow/launcher/config
/libs/settings/workflow/launcher/config
/conf/global/settings/workflow/launcher/config
Qualsiasi modulo di avvio flusso di lavoro nuovo o modificato deve essere migrato a /conf/global/workflow/launcher/config
.
- Copiare le configurazioni del modulo di avvio del flusso di lavoro nuove o modificate dal percorso precedente al nuovo percorso (
/conf/global
).
La risoluzione dell'utilità di avvio del flusso di lavoro viene eseguita nell'ordine seguente:
/conf/global/settings/workflow/launcher
/libs/settings/workflow/launcher
/etc/workflow/launcher
Di conseguenza, le personalizzazioni di Workflow Launcher fornite dall'AEM e persistenti nel percorso precedente devono essere spostate nel nuovo percorso (/conf/global/settings/workflow/launcher
) se devono essere mantenute, altrimenti saranno sostituite dalla definizione di Workflow Launcher fornita dall'AEM in /libs/settings/workflow/launcher
.
Script flusso di lavoro
/etc/workflow/scripts
/libs/workflow/scripts
/apps/workflow/scripts
Qualsiasi script di flusso di lavoro nuovo o modificato deve essere migrato alla nuova posizione e i modelli di flusso di lavoro di riferimento devono essere aggiornati per riflettere la nuova posizione.
- Copiare gli script di flusso di lavoro nuovi o modificati dal percorso precedente al nuovo percorso.
/apps/workflow/scripts
devono essere mantenute nell’SCM.
- Aggiornare eventuali riferimenti agli script del flusso di lavoro nella posizione precedente in Modelli flusso di lavoro per puntare alle nuove posizioni.
L'AEM 6.4 SP1, quando sarà pubblicato, consente di posticipare la ristrutturazione al 6.5 upgrade
.
Se si effettua l’aggiornamento al AEM 6.4 prima del rilascio del AEM 6.4 SP1, tale ristrutturazione dovrebbe essere effettuata nell’ambito del progetto di aggiornamento. In caso contrario, la modifica e il salvataggio dei passaggi del flusso di lavoro che fanno riferimento a script nel percorso precedente rimuoveranno completamente il riferimento allo script del flusso di lavoro dal passaggio del flusso di lavoro e solo gli script del flusso di lavoro nei nuovi percorsi saranno disponibili nel menu a discesa per la selezione degli script.
Prima di un aggiornamento futuro
Configurazioni ContextHub
/etc/cloudsettings
/libs/settings/cloudsettings
/conf/global/settings/cloudsettings
/conf/<tenant>/settings/cloudsettings
Tutte le configurazioni ContextHub nuove o modificate devono essere migrate nella nuova posizione e le pagine AEM Sites di riferimento devono essere aggiornate per riflettere la nuova posizione.
- Copia tutte le configurazioni ContextHub nuove o modificate dalla posizione precedente alla nuova posizione.
- Associa le configurazioni AEM applicabili alle gerarchie di contenuti AEM.
- Gerarchie di pagine AEM Sites tramite AEM Sites > Pagina > Proprietà pagina > Scheda Avanzate > Configurazione cloud.
- Dissocia tutte le configurazioni ContextHub legacy migrate dalle gerarchie di contenuti AEM sopra indicate.
Progettazioni Cloud Service classiche
/etc/designs/cloudservices
/libs/settings/wcm/designs/cloudservices
/apps/settings/wcm/designs/cloudservices
Per qualsiasi design gestito in SCM e non scritto in fase di esecuzione tramite le finestre di dialogo per progettazione.
- Copiare le progettazioni dal percorso precedente al nuovo percorso (
/apps
). - Convertire le risorse CSS, JavaScript e statiche nella progettazione in una Libreria client con
allowProxy = true
. - Aggiorna i riferimenti alla posizione precedente in
cq
: ProprietàdesignPath
. - Aggiorna tutte le pagine che fanno riferimento alla posizione precedente per utilizzare la nuova categoria Libreria client (è necessario aggiornare il codice di implementazione della pagina).
- Aggiorna le regole Dispatcher dell’AEM per consentire la distribuzione delle librerie client tramite /etc.clientlibs/. servlet proxy
Per tutte le progettazioni che NON sono state gestite in SCM e sono state modificate in fase di esecuzione tramite le finestre di dialogo per progettazione.
- Non spostare design modificabili da
/etc
.
Progettazioni dashboard classiche
/etc/designs/dashboards
/libs/settings/wcm/designs/dashboards
/apps/settings/wcm/designs/dashboards
Per qualsiasi design gestito in SCM e non scritto in fase di esecuzione tramite le finestre di dialogo per progettazione.
- Copia le progettazioni dalla posizione precedente alla nuova posizione (https://experienceleague.adobe.com/apps?lang=it).
- Convertire le risorse CSS, JavaScript e statiche nella progettazione in una Libreria client con
allowProxy = true
. - Aggiornare i riferimenti alla posizione precedente in
cq
: ProprietàdesignPath
. - Aggiorna tutte le pagine che fanno riferimento alla posizione precedente per utilizzare la nuova categoria Libreria client (è necessario aggiornare il codice di implementazione della pagina).
- Aggiorna le regole Dispatcher dell’AEM per consentire la distribuzione delle librerie client tramite /etc.clientlibs/. servlet proxy
Per tutte le progettazioni che NON sono state gestite in SCM e sono state modificate in fase di esecuzione tramite le finestre di dialogo per progettazione.
- Non spostare design modificabili da
/etc
.
Progettazioni report classici
/etc/designs/reports
/libs/settings/wcm/designs/reports
/apps/settings/wcm/designs/reports
Per qualsiasi design gestito in SCM e non scritto in fase di esecuzione tramite le finestre di dialogo per progettazione.
- Copia le progettazioni dalla posizione precedente alla nuova posizione (https://experienceleague.adobe.com/apps?lang=it).
- Convertire le risorse CSS, JavaScript e statiche nella progettazione in una Libreria client con
allowProxy = true
. - Aggiornare i riferimenti alla posizione precedente in
cq
: ProprietàdesignPath
. - Aggiorna tutte le pagine che fanno riferimento alla posizione precedente per utilizzare la nuova categoria Libreria client (è necessario aggiornare il codice di implementazione della pagina).
- Aggiorna le regole Dispatcher dell’AEM per consentire la distribuzione delle librerie client tramite /etc.clientlibs/. servlet proxy
Per tutte le progettazioni che NON sono state gestite in SCM e sono state modificate in fase di esecuzione tramite le finestre di dialogo per progettazione.
- Non spostare design modificabili da
/etc
.
Progettazioni predefinite
/etc/designs/default
/libs/settings/wcm/designs/default
/apps/settings/wcm/designs/default
Per qualsiasi design gestito in SCM e non scritto in fase di esecuzione tramite le finestre di dialogo per progettazione.
- Copia le progettazioni dalla posizione precedente alla nuova posizione (https://experienceleague.adobe.com/apps?lang=it).
- Convertire le risorse CSS, JavaScript e statiche nella progettazione in una Libreria client con
allowProxy = true
. - Aggiornare i riferimenti alla posizione precedente in
cq
: ProprietàdesignPath
. - Aggiorna tutte le pagine che fanno riferimento alla posizione precedente per utilizzare la nuova categoria Libreria client (è necessario aggiornare il codice di implementazione della pagina).
- Aggiorna le regole Dispatcher dell’AEM per consentire la distribuzione delle librerie client tramite /etc.clientlibs/. servlet proxy
Per tutte le progettazioni che NON sono state gestite in SCM e sono state modificate in fase di esecuzione tramite le finestre di dialogo per progettazione.
- Non spostare design modificabili da
/etc
.
Endpoint Adobe DTM JavaScript
/etc/clientlibs/dtm
/var/cq/dtm/clientlibs
Non è richiesta alcuna azione.
La posizione precedente pubblica funge da endpoint proxy per la nuova posizione privata.
Adobe di endpoint per web hook DTM
/etc/dtm-hook
/var/cq/dtm/web-hook
Non è richiesta alcuna azione.
La posizione precedente pubblica funge da endpoint proxy per la nuova posizione privata.
Attività casella in entrata
/etc/taskmanagement
/var/taskmanagement
Non è richiesta alcuna azione per eseguire la migrazione delle attività nella nuova posizione.
- Le attività presenti nel percorso precedente continuano a essere disponibili e a funzionare.
- Le nuove attività vengono create nella nuova posizione.
Configurazioni blueprint per Multi-Site Manager
/etc/blueprints
/libs/msm
/apps/msm
- Copia configurazioni personalizzate da
/etc/blueprints
a/apps/msm
. - Rimuovi
/etc/blueprints
.
Configurazioni gadget dashboard progetti AEM
/etc/projects/dashboard/gadgets
/libs/cq/core/content/projects/dashboard/gadgets
/apps/cq/core/content/projects/dashboard/gadgets
Qualsiasi configurazione di gadget del dashboard per progetti AEM nuova o modificata deve essere migrata nella nuova posizione (/apps
).
- Copiare le configurazioni del gadget del dashboard progetti AEM nuove o modificate dalla posizione precedente alla nuova posizione (
/apps
).- Non copiare le configurazioni del gadget del dashboard dei progetti AEM non modificate, in quanto queste sono ora presenti nella nuova posizione (
/libs
).
- Non copiare le configurazioni del gadget del dashboard dei progetti AEM non modificate, in quanto queste sono ora presenti nella nuova posizione (
- Aggiornare eventuali modelli di progetti AEM che fanno riferimento alla Posizione precedente in modo che puntino alla nuova posizione appropriata.
Modello e-mail notifica replica
/etc/notification/email/default/com.day.cq.replication
/libs/settings/notification-templates/com.day.cq.replication
/apps/settings/notification-templates/com.day.cq.replication
Qualsiasi modello di posta elettronica di notifica replica nuovo o modificato deve essere migrato nel nuovo percorso (/apps
)
- Copiare i modelli di posta elettronica per le notifiche di replica nuovi o modificati dalla posizione precedente nella nuova posizione (
/apps
). - Rimuovere eventuali modelli di posta elettronica di notifica replica migrati dal percorso precedente.
Gli unici nuovi modelli di posta elettronica per le notifiche di replica supportati sono quelli che supportano le nuove impostazioni internazionali.
La risoluzione del modello di posta elettronica per le notifiche di replica viene eseguita nell'ordine seguente:
/etc/notification/email/default/com.day.cq.replication
/apps/settings/notification-templates/com.day.cq.replication
/libs/settings/notification-templates/com.day.cq.replication
Tag
/etc/tags
/content/cq:tags
Tutti i tag devono essere migrati a /content/cq:tags
.
- Copia tutti i tag dalla posizione precedente alla nuova posizione.
- Rimuovi tutti i tag dalla posizione precedente.
- Tramite la console Web AEM, riavviare il bundle OSGi Day Communique 5 Tagging all'indirizzo https://serveraddress:serverport/system/console/bundles/com.day.cq.cq-tagging affinché l'AEM riconosca che la nuova posizione contiene dei contenuti e deve essere utilizzata.
Il riavvio del bundle OSGi di assegnazione tag Day Communique registrerà la nuova posizione come radice del tag solo se la posizione precedente è vuota.
I riferimenti alla posizione precedente continueranno a funzionare dopo la migrazione alla nuova posizione per tutte le funzionalità che utilizzano l’API TagManager dell’AEM per la risoluzione dei tag.
Qualsiasi codice personalizzato che fa riferimento in modo esplicito al percorso
/etc/tags
deve essere aggiornato a /content/
cq
:tags
, o preferibilmente riscritto per utilizzare l'API Java TagManager, insieme a questa migrazione.
Servizi cloud di traduzione
/etc/cloudservices/translation
/libs/settings/cloudconfigs/translation/translationcfg
/apps/settings/cloudconfigs/translation/translationcfg
/conf/global/settings/cloudconfigs/translation/translationcfg
/conf/<tenant>/settings/cloudconfigs/translation/translationcfg
Qualsiasi nuovo Cloud Service di traduzione deve essere migrato nel nuovo percorso (/apps
, /conf/global
o /conf/<tenant>
).
-
Migra le configurazioni esistenti nella posizione precedente alla nuova posizione.
- Ricrea manualmente nuove configurazioni dei Cloud Service di traduzione tramite l'interfaccia utente di creazione AEM in Strumenti > Cloud Service > Cloud Service di traduzione.
O - Copiare le nuove configurazioni dei Cloud Service di traduzione dal percorso precedente al nuovo percorso (
/apps
,/conf/global
o/conf/<tenant>
).
- Ricrea manualmente nuove configurazioni dei Cloud Service di traduzione tramite l'interfaccia utente di creazione AEM in Strumenti > Cloud Service > Cloud Service di traduzione.
-
Associa le configurazioni AEM applicabili alle gerarchie di contenuti AEM.
- Gerarchie di pagine AEM Sites tramite AEM Sites > Pagina > Proprietà pagina > Scheda Avanzate > Configurazione cloud.
- Gerarchie di frammenti esperienza AEM tramite Frammenti esperienza AEM > Frammento esperienza > Proprietà > Scheda Cloud Service > Configurazione cloud.
- Gerarchie di cartelle di frammenti esperienza AEM tramite Frammenti esperienza AEM > Cartella > Proprietà > Scheda Cloud Service > Configurazione cloud.
- Gerarchie di cartelle AEM Assets tramite AEM Assets > Cartella > Proprietà cartella > Scheda Cloud Service > Configurazione.
- Progetti AEM tramite Progetti AEM > Progetto > Proprietà progetto > Scheda Avanzate > Configurazione cloud.
-
Dissocia eventuali Cloud Service di traduzione legacy migrati dalle gerarchie di contenuto AEM sopra indicate.
La risoluzione dei Cloud Service di traduzione viene eseguita nell'ordine seguente:
/conf/<tenant>/settings/cloudconfigs/translations/translationcfg
/conf/global/settings/cloudconfigs/translations/translationcfg
/apps/settings/cloudconfigs/translations/translationcfg
/libs/settings/cloudconfigs/translations/translationcfg
I Cloud Service di traduzione migrati devono essere compatibili con AEM 6.4.
Lingue di traduzione
/etc/translation/supportedLanguages
/libs/settings/translation/supportedLanguages
/apps/settings/translation/supportedLanguages
Qualsiasi definizione di lingua di traduzione nuova o modificata richiede la migrazione di tutte le definizioni di lingua di traduzione nella nuova posizione (/apps
).
- Se sono state apportate aggiunte o modifiche alle definizioni della lingua di traduzione, copiare tutte le definizioni della lingua di traduzione dalla posizione precedente alla nuova posizione (
/apps
).
La risoluzione del percorso della lingua di traduzione viene eseguita nell'ordine seguente:
/etc/translation/supportedLanguages
/apps/settings/translation/supportedLanguage
/libs/settings/translation/supportedLanguages
Questa risoluzione non supporta una sovrapposizione di unione, il che significa che il percorso risolto deve contenere tutte le lingue supportate e non erediterà le lingue supportate da risoluzioni di ordine superiore.
Regole di traduzione
/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
Un file XML delle regole di traduzione modificato deve essere migrato nel nuovo percorso (/apps
o /conf/global
).
1. Copiare il file XML delle regole di traduzione modificato dalla posizione precedente nella nuova posizione.
La risoluzione XML delle regole di traduzione della replica viene eseguita nell'ordine seguente:
/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
Libreria client widget traduzione
/etc/designs/translation/translationwidget
/libs/settings/wcm/designs/translation/translationwidget
/apps/settings/wcm/designs/translation/translationwidget
Per qualsiasi design gestito in SCM e non scritto in fase di esecuzione tramite le finestre di dialogo per progettazione.
- Copia le progettazioni dalla posizione precedente alla nuova posizione (https://experienceleague.adobe.com/apps?lang=it).
- Convertire le risorse CSS, JavaScript e statiche nella progettazione in una Libreria client con
allowProxy = true
. - Aggiornare i riferimenti alla posizione precedente in
cq
: ProprietàdesignPath
. - Aggiorna tutte le pagine che fanno riferimento alla posizione precedente per utilizzare la nuova categoria Libreria client (è necessario aggiornare il codice di implementazione della pagina).
- Aggiorna le regole Dispatcher dell’AEM per consentire la distribuzione delle librerie client tramite /etc.clientlibs/. servlet proxy
Per tutte le progettazioni che NON sono state gestite in SCM e sono state modificate in fase di esecuzione tramite le finestre di dialogo per progettazione.
- Non spostare design modificabili da
/etc
.
Console Web di attivazione struttura
/etc/replication/treeactivation
/libs/replication/treeactivation
Cloud Service di connettori di traduzione fornitore
/etc/cloudservices/<vendor>
/libs/settings/cloudconfigs/translation/<vendor>
/apps/settings/cloudconfigs/translation/<vendor>
/conf/global/settings/cloudconfigs/translation/<vendor>
/conf/<tenant>/settings/cloudconfigs/translation/<vendor>
Qualsiasi nuovo Cloud Service di connettori di traduzione fornitore deve essere migrato nella nuova posizione (/apps
, /conf/global
o /conf/<tenant>
).
-
Migra le configurazioni esistenti nella posizione precedente alla nuova posizione.
- Crea manualmente configurazioni di Cloud Service di connettori di traduzione fornitori netti tramite l'interfaccia utente di creazione dell'AEM in Strumenti > Cloud Service > Cloud Service di traduzione.
O - Copiare le configurazioni dei nuovi Cloud Service di connettori di traduzione fornitori dalla posizione precedente alla nuova posizione (
/apps
,/conf/global
o/conf/<tenant>
).
- Crea manualmente configurazioni di Cloud Service di connettori di traduzione fornitori netti tramite l'interfaccia utente di creazione dell'AEM in Strumenti > Cloud Service > Cloud Service di traduzione.
-
Associa le configurazioni AEM applicabili alle gerarchie di contenuti AEM.
- Gerarchie di pagine AEM Sites tramite AEM Sites > Pagina > Proprietà pagina > Scheda Avanzate > Configurazione cloud.
- Gerarchie di frammenti esperienza AEM tramite Frammenti esperienza AEM > Frammento esperienza > Proprietà > Scheda Cloud Service > Configurazione cloud.
- Gerarchie di cartelle di frammenti esperienza AEM tramite Frammenti esperienza AEM > Cartella > Proprietà > Scheda Cloud Service > Configurazione cloud.
- Gerarchie di cartelle AEM Assets tramite AEM Assets > Cartella > Proprietà cartella > Scheda Cloud Service > Configurazione.
- Progetti AEM tramite Progetti AEM > Progetto > Proprietà progetto > Scheda Avanzate > Configurazione cloud.
-
Dissocia eventuali Cloud Service di traduzione legacy migrati dalle gerarchie di contenuto AEM sopra indicate.
La risoluzione dei Cloud Service di traduzione viene eseguita nell'ordine seguente:
/conf/<tenant>/settings/cloudconfigs/translations/<vendor>
/conf/global/settings/cloudconfigs/translations/<vendor>
/apps/settings/cloudconfigs/translations/<vendor>
/libs/settings/cloudconfigs/translations/<vendor>
Modelli e-mail di notifica flusso di lavoro
/etc/workflow/notification
/libs/settings/workflow/notification
/conf/global/settings/workflow/notification
È necessario eseguire la migrazione di tutti i modelli e-mail di notifica flusso di lavoro modificati nel nuovo percorso (/conf/global
).
- Copiare nella nuova posizione tutti i modelli di e-mail di notifica del flusso di lavoro modificati dalla posizione precedente.
- Rimuovi i modelli e-mail di notifica flusso di lavoro migrati dalla posizione precedente.
La risoluzione del modello e-mail di notifica flusso di lavoro viene eseguita nell'ordine seguente:
/etc/workflow/notification
/conf/global/settings/workflow/notification
/libs/settings/workflow/notification
Pacchetti flusso di lavoro
/etc/workflow/packages
/var/workflow/packages
I pacchetti di flusso di lavoro esistenti nella posizione precedente devono essere migrati nella nuova posizione.
- Rimuovi eventuali pacchetti flusso di lavoro nella posizione precedente che non sono referenziati da altri contenuti e che non sono altrimenti necessari.
- Sposta tutti i pacchetti flusso di lavoro nella posizione precedente che non sono referenziati da altri contenuti ma che sono comunque necessari nella nuova posizione.
- Lascia nella posizione precedente tutti i pacchetti del flusso di lavoro a cui fanno riferimento altri contenuti.
I pacchetti del flusso di lavoro creati tramite la console Miscadmin dell’interfaccia classica vengono mantenuti nella posizione precedente, mentre tutti gli altri vengono mantenuti nella nuova posizione.
I pacchetti del flusso di lavoro memorizzati nelle posizioni precedenti o precedenti possono essere gestiti tramite la console Gestione errori dell’interfaccia classica.