Se WordPress viene scelto come piattaforma di destinazione, la preparazione deve iniziare chiarendo che cosa sia realmente il sito di origine. La stessa installazione WordPress può essere una pubblicazione, un sito di documentazione, un sito marketing, un ambiente membership, una directory, una piattaforma di apprendimento, un sistema per eventi oppure il CMS attorno a uno Store WooCommerce. Posts e CMS Pages del core possono rappresentare soltanto una parte dei contenuti operativi. Custom post type, tassonomie, metadati, relazioni con i media, utenti, tabelle dei plugin, blocchi, layout dei builder, redirect e identificatori esterni possono determinare se il sito migrato resterà modificabile e comprensibile.
La preparazione deve produrre evidenze sulla piattaforma di origine, non supposizioni. Ogni classe di record importante deve avere un proprietario, un’esportazione o inventario, un campione rappresentativo e una condizione di preparazione completata. I contenuti del core WordPress devono restare separati dai dati applicativi gestiti dai plugin e la preparazione del CMS WordPress deve restare distinta dalla preparazione di Products, Customers e Orders WooCommerce.
Confermare ambito WordPress e proprietari dei record
Per prima cosa, definire quali record di origine appartengono al core WordPress, quali a plugin o codice personalizzato, quali restano in sistemi esterni e quali vengono esclusi intenzionalmente. Questo confine evita che la migrazione tratti ogni riga del database WordPress come normale contenuto.
WordPress memorizza diversi post type nella stessa infrastruttura dei post, ma il post type determina comunque scopo editoriale, amministrazione, template, capacità, archivi e comportamento API. Anche le tassonomie personalizzate richiedono registrazioni e relazioni con gli oggetti; i metadati richiedono il plugin, il tema o il codice che ne interpreta chiavi e valori.
| Azione di preparazione | Responsabile | Evidenza da preparare | Condizione di preparazione completata |
|---|---|---|---|
| Definire il ruolo previsto del sito WordPress di destinazione | Proprietario del sito e responsabile contenuti | Dichiarazione sintetica dell’ambito che copra pubblicazione, marketing, membership, directory, formazione, e-commerce o altri ruoli applicativi | Ogni classe principale di record di origine ha un proprietario WordPress, plugin, sistema esterno, archivio o un’esclusione intenzionale. |
| Separare ambito CMS WordPress da WooCommerce o da altri ambiti applicativi | Proprietario del sito e responsabile tecnico | Confine tra entità che elenchi CMS Posts, CMS Pages, media, utenti, menu e Products, Orders, membership, prenotazioni o invii posseduti dalle applicazioni | Nessun record applicativo viene considerato automaticamente una normale CMS Page o un Post soltanto perché utilizza tabelle WordPress. |
| Registrare la topologia del sito di origine | Responsabile tecnico | Elenco domini, sottodirectory, siti per lingua, network/siti Multisite, ambienti di staging e URL pubblici attivi | Il team può identificare quale sito o network possiede ogni record selezionato. |
| Identificare i sistemi esterni autorevoli | Responsabile delle integrazioni | Mappa degli identificatori di CRM, DAM, PIM, LMS, marketing, ricerca, identità o sistemi documentali | Le chiavi esterne e i sistemi che continueranno a essere sistemi di riferimento sono documentati prima dell’inizio della mappatura dei campi. |
In Multisite, l’identificatore del sito o blog fa parte della proprietà del record. Gli utenti possono partecipare all’intero network mentre Posts, CMS Pages, termini, opzioni e molti record dei plugin restano specifici per sito. Il pacchetto di preparazione deve mantenere questo ambito invece di unire i record per titolo o ID numerico.
Garantire accesso alla piattaforma di origine, backup ed evidenza dell’ambiente
Una migrazione WordPress richiede più di un accesso amministratore. I contenuti possono essere distribuiti tra database, directory uploads, directory dei plugin, file dei temi, file di lingua, object storage, media remoti e servizi esterni. La preparazione degli accessi deve rendere recuperabile la piattaforma di origine e permettere al team di interpretare le strutture personalizzate.
| Azione di preparazione | Responsabile | Evidenza da preparare | Condizione di preparazione completata |
|---|---|---|---|
| Confermare l’accesso all’amministrazione WordPress | Amministratore del sito | Account amministratore funzionante ed elenco delle aree di amministrazione con accesso limitato | Posts, Pages, utenti, media, plugin, temi, menu e impostazioni necessari possono essere inventariati. |
| Creare un backup completo della piattaforma di origine | Hosting o responsabile tecnico | Backup datato del database più file wp-content, uploads, temi, plugin e riferimenti di configurazione quando disponibili |
Posizione, data, responsabile del ripristino e periodo di conservazione del backup sono registrati. |
| Registrare i dettagli dell’ambiente | Responsabile tecnico | Versione WordPress, versione PHP, versione database, tema attivo, child theme, plugin attivi, must-use plugin e servizi server rilevanti | L’ambiente di origine può essere ricostruito in misura sufficiente per comprendere la proprietà di contenuti e plugin. |
| Registrare processi programmati e in background | Responsabile plugin o integrazioni | Eventi WP-Cron, scheduler esterni, code, endpoint webhook e processi batch che creano o aggiornano record | I writer automatici sono noti e non verranno confusi con contenuti statici migrati. |
| Conservare evidenze di esportazione | Responsabili contenuti e tecnici | File di esportazione WordPress quando utili, inventari di database/tabelle, elenchi di file media ed esportazioni specifiche dei plugin | Ogni area dati selezionata dispone di un artefatto recuperabile della piattaforma di origine o di un percorso di recupero documentato. |
L’esportatore integrato di WordPress può fornire evidenze utili sui contenuti, ma non è un backup completo del sito e non rappresenta automaticamente ogni tabella plugin, opzione, file media, dipendenza del tema o record esterno. Il pacchetto di preparazione deve quindi distinguere le esportazioni dei contenuti dalle evidenze necessarie per il recupero completo.
Inventariare Posts, CMS Pages, custom post type e stati del ciclo di vita
Elencare ogni post type che contiene record, non soltanto quelli visibili nel menu principale di amministrazione. Includere Posts e CMS Pages standard, allegati, revisioni quando mantenute e ogni custom post type registrato. Per ciascun tipo, documentare scopo operativo, numero di record, stato pubblico o privato, funzioni dell’editor, relazioni parent, autore, date, comportamento degli archivi e plugin o codebase responsabile.
| Area di record | Evidenza da preparare | Decisione da risolvere | Condizione di preparazione completata |
|---|---|---|---|
| Blog Posts | Campioni con autori, date, estratti, categorie, tag, commenti, immagini in evidenza e contenuti incorporati | Quale cronologia, bozze, record programmati, record privati e archivi restano nell’ambito? | Gli stati del ciclo di vita inclusi ed esclusi sono espliciti. |
| CMS Pages | Mappa padre-figlio, template di pagina, utilizzo nei menu, moduli, contenuti incorporati e percorsi ad alto valore | Quali gerarchie e dipendenze dai template devono continuare? | Ogni Page importante ha un proprietario di destinazione e uno stato parent o top-level previsto. |
| Custom post type | Fonte della registrazione, elenco campi, tassonomie, capacità, impostazioni degli archivi e record rappresentativi | La destinazione mantiene il tipo, lo converte o lo conserva in un’altra applicazione? | Ogni tipo attivo ha una rappresentazione di destinazione e un responsabile della modifica. |
| Revisioni, autosave e cestino | Conteggi e motivazione della conservazione | Le versioni storiche hanno valore operativo oppure sono soltanto cronologia del database? | La conservazione è intenzionale, non ereditata per impostazione predefinita. |
| Contenuti privati o protetti | Proprietario dell’accesso, pubblico e meccanismo di protezione attuale | L’accesso appartiene ai ruoli WordPress, a un plugin membership o a un altro sistema? | I record protetti hanno identità e dipendenze di autorizzazione documentate. |
Non utilizzare il conteggio dei record come unico inventario. Un custom post type con venti record può generare più complessità di migrazione di migliaia di Blog Posts ordinari quando dipende da più tassonomie, campi relazione, tabelle personalizzate e archivi pubblici.
Preparare tassonomie, termini, menu e relazioni degli archivi
Le tassonomie WordPress classificano oggetti; i menu organizzano la navigazione. Devono essere inventariati separatamente anche quando una Category o un termine compare anche in un menu. Per ogni tassonomia, registrare se è gerarchica o piatta, quali post type classifica, se dispone di archivi pubblici, quali metadati appartengono ai termini e se esistono etichette equivalenti in un’altra tassonomia.
| Azione di preparazione | Responsabile | Evidenza da preparare | Condizione di preparazione completata |
|---|---|---|---|
| Inventariare tassonomie standard e personalizzate | Architetto dei contenuti o responsabile plugin | Nomi tassonomie, tipi di oggetto registrati, gerarchia, conteggio termini, metadati dei termini e impostazioni degli archivi | Ogni termine selezionato resta collegato alla tassonomia e al tipo di oggetto corretti. |
| Ripulire termini duplicati o obsoleti | Responsabile contenuti | Elenco di decisioni per unire, mantenere, rinominare o escludere | Etichette simili non verranno unite a meno che rappresentino la stessa classificazione. |
| Esportare strutture di navigazione | Responsabile contenuti | Alberi di menu principale, footer, utility, contestuali e specifici per lingua con link personalizzati | Il posizionamento nei menu è documentato separatamente dalla gerarchia dei contenuti e dall’appartenenza tassonomica. |
| Documentare le destinazioni degli archivi | Responsabili SEO e contenuti | Elenco URL di archivi Category, tag, tassonomie personalizzate, autori, date e custom post type | Ogni archivio importante ha una decisione di destinazione, sostituzione o redirect. |
Gli ID dei termini e gli ID delle voci di menu sono specifici dell’installazione. Quando metadati o record dei builder fanno riferimento a tali ID, l’evidenza di preparazione deve identificare tassonomia, termine, menu o oggetto di contenuto referenziato, non soltanto il numero originale.
Mappare metadati, campi personalizzati, opzioni e tabelle dei plugin
I metadati possono essere un semplice valore editoriale, un riferimento a oggetto, configurazione serializzata, dato di layout, identificatore esterno o stato applicativo. Creare un inventario delle chiavi importanti per post meta, user meta, term meta e comment meta. Raggruppare le chiavi per proprietario e scopo invece di tentare di mantenere ogni chiave tecnica.
I plugin possono inoltre creare tabelle dedicate quando il loro dominio non si adatta alle strutture core di WordPress. Moduli, membership, sistemi di apprendimento, eventi, prenotazioni, directory, redirect, strumenti di analisi e integrazioni usano spesso tabelle personalizzate per definizioni, transazioni, cronologie o relazioni.
| Azione di preparazione | Responsabile | Evidenza da preparare | Condizione di preparazione completata |
|---|---|---|---|
| Inventariare le chiavi di metadati essenziali per il business | Responsabile plugin e responsabile contenuti | Nome chiave, tipo oggetto, formato dati, valori campione, scopo per l’utente e tipo di oggetto referenziato | Ogni chiave mantenuta ha un campo di destinazione, un proprietario plugin o un proprietario esterno. |
| Identificare i campi che fanno riferimento ad altri oggetti | Responsabile tecnico | Campioni di ID post, allegato, utente, termine e ID esterni memorizzati nei metadati | I riferimenti possono essere ricostruiti verso gli oggetti di destinazione invece di copiare ID numerici obsoleti. |
| Registrare campi serializzati o strutturati | Responsabile plugin o builder | Esempi di schema, ripetitori, gruppi, payload JSON/serializzati e definizioni dei campi | La destinazione può interpretare la struttura oppure è documentata una decisione di ristrutturazione. |
| Inventariare opzioni del sito e dei plugin | Responsabile tecnico | Opzioni rilevanti per il business, plugin/tema proprietario, ambito del sito e classificazione come contenuto o configurazione | La configurazione non viene classificata silenziosamente come contenuto migrato. |
| Inventariare tabelle personalizzate | Responsabile plugin e amministratore database | Nomi tabelle, conteggi righe, chiavi primarie, relazioni parent, date, stati e chiavi esterne | Ogni tabella essenziale per il business ha una destinazione esplicita, un sistema esterno mantenuto, un archivio o una decisione di esclusione. |
Cache tecniche, record temporanei, log, sessioni, indici generati e dati di plugin abbandonati non devono essere inclusi soltanto perché esistono. La loro esclusione va registrata affinché un successivo confronto del database non interpreti una pulizia intenzionale come contenuto mancante.
Preparare media, blocchi, builder, temi e contenuti incorporati
La preparazione dei media deve mantenere sia i file sia i riferimenti. Registrare immagini in evidenza, immagini inline, gallerie, documenti scaricabili, risorse ospitate esternamente, didascalie, alt text, metadati degli allegati e file riutilizzati. Identificare file presenti nella directory uploads ma non più referenziati e riferimenti per cui il file non esiste più.
La presentazione dei contenuti può essere memorizzata come blocchi core, HTML dell’editor classico, shortcode, widget, blocchi riutilizzabili, pattern, template part, metadati dei page builder, opzioni del tema o template personalizzati. L’implementazione WordPress di destinazione potrebbe non utilizzare lo stesso builder o tema, quindi la preparazione deve separare i contenuti riutilizzabili dai dati di layout specifici della piattaforma di origine.
| Area di preparazione | Evidenza da preparare | Responsabile | Condizione di preparazione completata |
|---|---|---|---|
| Media Library | Inventario dei file, record attachment, alt text, didascalie, collegamenti alle immagini in evidenza, gallerie e URL esterni | Responsabili contenuti e media | I file prioritari sono accessibili e ogni riferimento importante dispone di un file di origine noto o di un proprietario remoto. |
| Blocchi core e contenuti classici | Contenuti rappresentativi con link, embed, tabelle, blocchi riutilizzabili e formattazione complessa | Responsabile editoriale | I pattern di contenuto che richiedono conversione o ricostruzione manuale sono identificati. |
| Shortcode | Inventario shortcode, plugin/tema proprietario, pagine di esempio e risultato atteso | Responsabile plugin | Ogni shortcode critico ha un renderer che continuerà a esistere oppure una decisione di sostituzione. |
| Page builder | Versione builder, template, sezioni globali, memorizzazione dei campi, dipendenza dal tema e layout campione | Responsabili design e tecnici | I contenuti riutilizzabili sono separati dai dati di presentazione specifici del builder. |
| Temi e template part | Tema attivo/child, template personalizzati, aree widget, template part e stili globali | Responsabile design | Il codice del tema è trattato come evidenza dell’implementazione, non come normale contenuto. |
L’articolo WordPress non richiede che il design finale sia già completo. Richiede però evidenze sufficienti sulla proprietà per evitare che dati dei builder, codice del tema, shortcode e contenuti riutilizzabili vengano mescolati in un unico ambito di migrazione indistinto.
Preparare utenti, ruoli, autori, commenti e record sensibili alla privacy
Gli utenti WordPress possono essere autori, redattori, amministratori, iscritti, membri, studenti, venditori o Customers di un’altra applicazione. Ruoli e capacità core definiscono i privilegi, mentre i plugin possono aggiungere ruoli, capacità, profili, membership e cronologie. Inventariare separatamente ruolo e relazione applicativa.
| Azione di preparazione | Responsabile | Evidenza da preparare | Condizione di preparazione completata |
|---|---|---|---|
| Classificare le popolazioni utenti | Amministratore del sito e responsabile business | Conteggi e campioni per ruolo, tipo applicativo, stato attivo, autore e scopo account | Autori, personale, membri, iscritti e utenti applicativi non vengono uniti soltanto in base all’email. |
| Registrare ruoli e capacità personalizzate | Responsabile tecnico | Definizioni dei ruoli, capacità personalizzate, plugin/codice proprietario e utenti rappresentativi | Il comportamento di accesso richiesto ha un proprietario di destinazione; i privilegi obsoleti sono esclusi. |
| Collegare autori e proprietà | Responsabile editoriale | Posts di valore elevato e record personalizzati con riferimenti ad autore/proprietario | I record inclusi hanno autori di destinazione risolvibili oppure un proprietario fallback approvato. |
| Inventariare commenti e Reviews | Responsabile contenuti o comunità | Stato, gerarchia, identità autore, contenuto correlato, regole spam/esclusione e proprietà plugin | Commenti del blog, discussioni, testimonianze e Reviews e-commerce restano classificati correttamente. |
| Identificare campi sensibili alla privacy | Responsabili privacy e business | Inventario campi, base del consenso, regola di conservazione e requisito di accesso | I dati sensibili hanno una decisione approvata di migrazione, archivio, redazione o esclusione. |
Hash delle password e identità di autenticazione esterne della piattaforma di origine devono essere documentati separatamente dai profili utente di base. Un record utente può rientrare nell’ambito anche quando la credenziale di autenticazione originale non è trasferibile.
Preparare URL, metadati SEO, redirect, lingue e ambito Multisite
Creare un inventario degli URL di origine per CMS Pages, Blog Posts, custom post type, archivi tassonomici, archivi autore, media, feed e percorsi plugin ad alto valore. Registrare struttura dei permalink, gerarchia parent, rewrite rule delle tassonomie, ambito dominio/sottodirectory, URL canonical e redirect esistenti.
I campi SEO possono essere memorizzati nei record core, nei metadati, nelle tabelle dei plugin o su piattaforme esterne. Inventariare titoli, descrizioni, valori canonical, campi social, input per dati strutturati, controlli di indicizzazione e record di redirect per proprietario. Non presumere che l’esportazione di un plugin contenga ogni relazione dei percorsi.
| Azione di preparazione | Responsabile | Evidenza da preparare | Condizione di preparazione completata |
|---|---|---|---|
| Raccogliere gli URL prioritari della piattaforma di origine | Responsabile SEO | Elenco URL basato su dati di analisi e ricerca più stato attuale e destinazione prevista | Ogni percorso prioritario ha una decisione di mantenimento, modifica, consolidamento, ritiro o redirect. |
| Registrare logica di permalink e rewrite | Responsabile tecnico | Impostazioni permalink, rewrite rule di custom post type e tassonomie, endpoint plugin e regole percorso/dominio Multisite | Il design dei percorsi di destinazione distingue record di contenuto, archivi ed endpoint applicativi. |
| Inventariare i proprietari dei dati SEO | Responsabili SEO e plugin | Mappa chiavi/tabelle dei metadati, file di esportazione, regole canonical, regole di indicizzazione e fonti sitemap | Ogni valore SEO mantenuto ha un proprietario di destinazione. |
| Preparare relazioni multilingue | Responsabile localizzazione | Lingue, gruppi di traduzione, codici locale, percorsi specifici per lingua e regole fallback | Le traduzioni restano collegate invece di diventare contenuti duplicati indipendenti. |
| Registrare i redirect esistenti | Responsabile SEO o tecnico | Origine, destinazione, stato, proprietario e priorità | Redirect duplicati, concatenati, obsoleti e ancora necessari sono classificati. |
Per Multisite, includere nell’evidenza URL la relazione network/sito. Slug identici su siti differenti rappresentano percorsi distinti e non devono essere uniti senza una decisione esplicita sui contenuti.
Selezionare campioni rappresentativi per la migrazione di prova
La selezione dei campioni deve rappresentare la diversità strutturale del sito, non soltanto record recenti o semplici. Ogni campione deve indicare relazioni di contenuto attese, file collegati, evidenze relative al percorso e revisore responsabile.
| Campione | Evidenza da preparare | Perché deve far parte del set di campioni |
|---|---|---|
| CMS Page gerarchica | Percorso parent/child, template, blocchi o dati builder, media, uso nel menu e campi SEO | Rappresenta gerarchia Page, dipendenze di presentazione e routing. |
| Blog Post con relazioni | Autore, categorie, tag, commenti, immagine in evidenza, embed e percorsi archivio | Rappresenta cronologia editoriale e classificazione. |
| Un record per ogni custom post type importante | Tassonomie, metadati, media, percorso pubblico, plugin proprietario e record correlati | Espone dipendenze di registrazione plugin e schema personalizzato. |
| Record con molti metadati | Definizioni dei campi, ID di riferimento, ripetitori, valori serializzati e ID esterni | Espone se i valori dei campi possono restare interpretabili. |
| Utente con contesto applicativo | Ruolo, capacità, record creati, dati profilo e membership o altra relazione plugin | Rappresenta l’identità senza confondere utenti core e profili dei plugin. |
| Record con contenuto/media complesso | Galleria, file scaricabile, allegato riutilizzato, shortcode/embed e link interni | Rappresenta dipendenze tra file e riferimenti nei contenuti. |
| Record multilingue o Multisite quando applicabile | Proprietà sito/lingua, collegamenti tra traduzioni, percorsi e utenti condivisi | Espone relazioni di ambito sito e localizzazione. |
Un registro dei campioni deve includere ID di origine, URL pubblico quando applicabile, proprietario del record, oggetti correlati, motivo della selezione e dipendenze irrisolte. I record semplici possono confermare il funzionamento di base, ma sono i record complessi a rivelare se le evidenze sull’ambito sono complete.
Completare il gate finale di preparazione per WordPress
Prima dell’esecuzione, consolidare le evidenze in un unico registro di preparazione. Un elemento irrisolto può restare aperto soltanto se dispone di un responsabile, una data decisionale e un effetto definito sull’ambito.
| Area di preparazione | Condizione di preparazione completata |
|---|---|
| Ambito e proprietà | Ogni tipo di record selezionato appartiene al core WordPress, a un plugin/applicazione personalizzata nominata, a un sistema esterno, a un archivio o a un’esclusione intenzionale. |
| Accesso e recupero | Accesso amministratore, backup database, backup file, inventario dell’ambiente e responsabilità del ripristino sono registrati. |
| Architettura dei contenuti | Posts, CMS Pages, custom post type, tassonomie, menu e stati del ciclo di vita hanno decisioni esplicite di inclusione e destinazione. |
| Dati personalizzati | Metadati importanti, opzioni, tabelle personalizzate, riferimenti agli oggetti e identificatori esterni hanno schemi e proprietari noti. |
| Media e presentazione | I file prioritari sono disponibili; dipendenze da builder, blocchi, shortcode, temi e template sono classificate. |
| Utenti e privacy | Ruoli, autori, profili applicativi, commenti, dipendenze di autenticazione e campi sensibili sono classificati. |
| URL e SEO | Percorsi prioritari, logica dei permalink, redirect, ambito lingua/sito e proprietari dei dati SEO sono documentati. |
| Campioni | Il registro dei campioni rappresenta ogni pattern rilevante di contenuto e applicazione WordPress nell’ambito. |
L’ambito WordPress è pronto quando il team di migrazione può identificare che cosa rappresenta ogni record selezionato, dove risiedono i dati correlati, chi possiede la sua rappresentazione di destinazione e quali evidenze della piattaforma di origine sostengono la decisione.
Conclusione
Preparare una migrazione verso WordPress significa definire proprietà e relazioni tra contenuti, classificazione, metadati, media, identità, presentazione, plugin, tabelle personalizzate, percorsi e sistemi esterni. Backup completo e accesso amministratore sono necessari, ma non spiegano custom post type, relazioni tassonomiche, strutture dei builder, profili applicativi, ambito Multisite o record gestiti dai plugin.
Un buon pacchetto di preparazione rende esplicite queste relazioni. Separa i dati CMS WordPress da WooCommerce o da altri domini applicativi, conserva evidenze recuperabili della piattaforma di origine, seleziona campioni rappresentativi e assegna ogni record importante a una destinazione, a un proprietario esterno mantenuto, a un archivio o a un’esclusione intenzionale prima dell’inizio della migrazione.
Domande frequenti
Che cosa va preparato per primo in una migrazione verso WordPress?
Definire il ruolo del sito WordPress di destinazione e classificare i proprietari dei record di origine. In questo modo, prima del lavoro dettagliato sui campi, ogni record può essere assegnato al core WordPress, a un plugin o applicazione personalizzata, a un sistema esterno, a un archivio o a un’esclusione intenzionale.
Il file di esportazione WordPress è un backup completo per la migrazione?
No. L’esportazione integrata può fornire evidenze utili sui contenuti, ma una fonte realmente recuperabile richiede normalmente anche database, media e altri file wp-content, dettagli dell’ambiente e record specifici dei plugin o sistemi esterni che l’esportazione non rappresenta.
Perché custom post type e tassonomie devono essere inventariati separatamente?
Possono condividere la memorizzazione WordPress pur usando registrazioni, capacità, editor, metadati, archivi, template e proprietari plugin differenti. Mantenere soltanto titoli e contenuti non conserverebbe la struttura che rende gestibili quei record.
Come devono essere preparati campi personalizzati e metadati?
Registrare proprietario dei metadati, tipo di oggetto, formato del valore, definizione del campo, oggetti referenziati, campioni rappresentativi e destinazione prevista. ID numerici e valori serializzati non devono essere copiati senza ricostruire i record o gli schemi a cui fanno riferimento.
Plugin e temi devono essere trattati come contenuti migrati?
Non automaticamente. Plugin e temi sono dipendenze dell’implementazione. Record essenziali, impostazioni, tabelle personalizzate, shortcode, template e collegamenti esterni devono avere decisioni di proprietà esplicite, mentre dati tecnici temporanei o obsoleti possono essere esclusi.
In che modo la preparazione WordPress differisce dalla preparazione WooCommerce?
La preparazione WordPress riguarda CMS Posts, CMS Pages, custom post type, tassonomie, metadati, media, utenti, menu, percorsi e confini applicativi dei plugin. La preparazione WooCommerce riguarda separatamente Products, varianti, Customers, Orders, coupon, commerce Reviews, HPOS, metadati del processo di acquisto ed estensioni e-commerce.