WordPress memorizza gran parte dei contenuti visibili tramite un numero limitato di strutture core riutilizzabili, ma tali strutture possono supportare applicazioni molto diverse. Un record nella tabella dei post può rappresentare un Blog Post, una CMS Page, un allegato media, una voce di navigazione, una revisione o un custom post type. Una tassonomia può classificare contenuti editoriali, record di directory, corsi, eventi o Products. I metadati possono essere un semplice valore di visualizzazione oppure il campo che collega un record a un plugin, un template, una regola di autorizzazione o un sistema esterno.
La decisione importante per la migrazione non è quindi se un valore possa entrare in WordPress. È quale oggetto WordPress debba possederlo e quali relazioni rendano il record realmente gestibile. Una “pagina” della piattaforma di origine può diventare una CMS Page, un custom post type, un archivio tassonomico, un record di plugin o più oggetti collegati. Un “Customer” della piattaforma di origine può diventare un utente WordPress, un Customer di un plugin e-commerce, un profilo membership, un contatto CRM oppure non diventare affatto un account WordPress.
Il core WordPress offre tipi di record riutilizzabili, non uno schema aziendale universale
Il core WordPress separa contenuti, classificazione, media, identità, impostazioni, commenti, routing e presentazione. I plugin possono registrare nuovi tipi di record o creare tabelle separate per applicazioni specializzate. Temi e template a blocchi determinano la visualizzazione, ma non diventano automaticamente proprietari dei record operativi sottostanti.
| Livello WordPress | Significato nel core | Conseguenza per la rappresentazione |
|---|---|---|
| Tabella dei post | Memorizza più post type, tra cui Posts, Pages, allegati, revisioni, voci di menu e custom post type registrati | Il post type e le sue relazioni contano più della posizione condivisa nella stessa tabella. |
| Tassonomie e termini | Classificano i record tramite vocabolari gerarchici o piatti | Una Category della piattaforma di origine non può essere mappata in modo affidabile senza sapere cosa classifica e come la destinazione la utilizza. |
| Metadati | Aggiungono valori chiave-valore a post, utenti, termini e commenti | Lo stesso schema di memorizzazione può contenere campi di visualizzazione, relazioni, autorizzazioni, stato dei plugin o identificatori esterni. |
| Utenti, ruoli e capacità | Rappresentano identità e autorizzazioni | Un utente WordPress non è automaticamente un Customer, membro, studente, donatore, venditore o profilo del personale. |
| Opzioni e impostazioni | Memorizzano configurazioni a livello di sito o plugin | I record di configurazione non devono essere confusi con entità di contenuto trasferibili. |
| Commenti | Memorizzano interazioni collegate a post o altri oggetti supportati | Commenti del blog, Product Reviews, testimonianze, domande e discussioni possono richiedere proprietari diversi nella destinazione. |
| Plugin e tabelle personalizzate | Aggiungono record e funzioni specifiche per un dominio | E-commerce, membership, moduli, eventi, directory, formazione e prenotazioni richiedono un’interpretazione basata sul reale proprietario dei dati. |
WordPress può quindi ricevere molti tipi di dati della piattaforma di origine, ma il modello di destinazione deve indicare post type, tassonomia, proprietario dei metadati, proprietario del plugin e percorso previsti. Senza queste decisioni, i contenuti migrati possono esistere nel database pur restando assenti dall’editor, dagli archivi, dai template, dalla ricerca, dalle autorizzazioni o dal flusso applicativo.
Blog Posts, CMS Pages e custom post type hanno significati diversi
Posts e Pages di WordPress condividono la struttura di memorizzazione principale ma svolgono ruoli editoriali differenti. I Blog Posts appartengono normalmente a un flusso editoriale basato sul tempo e possono partecipare a categorie, tag, autori, archivi, feed e navigazione cronologica. Le CMS Pages rappresentano generalmente contenuti relativamente stabili del sito e possono formare gerarchie padre-figlio. I custom post type modellano domini strutturati che vanno oltre il normale contenuto editoriale.
Una piattaforma di origine può chiamare “page” ogni record pubblico anche quando i record rappresentano eventi, sedi, case study, risorse, persone, corsi, immobili o annunci. Trasformarli tutti in CMS Pages elimina la distinzione di tipo che permette di usare campi specializzati, archivi, filtri, template e interfacce di amministrazione dedicate.
| Record di origine | Possibile destinazione WordPress | Relazione che determina la scelta |
|---|---|---|
| Articolo di notizie o contenuto editoriale | Blog Post | Data di pubblicazione, autore, categorie, tag, archivi, feed e contenuti correlati |
| Pagina “chi siamo”, contatti, policy o servizi | CMS Page | Gerarchia stabile, posizione nel menu, template di pagina e percorso |
| Evento | Custom post type per eventi o record di un plugin eventi | Data, sede, organizzatore, ricorrenza, ticket e relazioni calendario |
| Immobile o voce di directory | Custom post type per annunci o record di un plugin directory | Località, attributi, filtri tassonomici, proprietario, stato e relazioni di ricerca |
| Corso o lezione | Post type gestito da LMS e relative tabelle | Gerarchia dei corsi, iscrizioni, avanzamento, quiz, certificati e regole di accesso |
| Product | Modello Product di un plugin e-commerce | Tipo Product, variante, prezzo, stock, imposta, spedizione, Customer e relazioni con Orders |
| Sezione grafica riutilizzabile | Pattern di blocchi, template part, record del builder o blocchi incorporati | Riutilizzo nella presentazione, non identità editoriale indipendente |
I custom post type possono essere memorizzati insieme agli altri post type, ma la stessa posizione di memorizzazione non li rende intercambiabili. Capacità registrate, funzionalità dell’editor, tassonomie, metadati, esposizione REST, comportamento degli archivi e template definiscono il modo in cui redattori e applicazioni li utilizzano.
Tassonomie, termini, menu e archivi sono collegati ma non equivalenti
Le tassonomie WordPress classificano oggetti. Le Categories sono gerarchiche per impostazione predefinita, i tag sono piatti e plugin o temi possono registrare tassonomie personalizzate per ambiti come argomenti, brand, località, settori, tipi di risorsa, livelli di corso o attributi Product. I termini sono i singoli valori all’interno di tali tassonomie.
Menu e navigazione sono separati. Una voce di menu può collegarsi a una CMS Page, un Blog Post, un archivio tassonomico, un archivio di custom post type, un URL esterno o un altro percorso. L’esistenza di un termine tassonomico non garantisce una voce di menu corrispondente e la gerarchia del menu non riproduce necessariamente la gerarchia dei contenuti.
| Struttura di origine | Proprietà in WordPress | Problema di rappresentazione |
|---|---|---|
| Sezione editoriale | Category o tassonomia personalizzata | Mantenere la relazione con i post type corretti e il comportamento previsto dell’archivio. |
| Etichetta o parola chiave | Tag o tassonomia personalizzata piatta | Evitare di creare una gerarchia profonda quando il valore di origine è soltanto un’etichetta. |
| Brand, regione o tipo di risorsa | Tassonomia personalizzata, tassonomia e-commerce o classificazione di plugin | Mantenere separati i vocabolari quando controllano filtri o template differenti. |
| Albero di navigazione principale | Record di navigazione/menu | Ordine e annidamento del menu sono relazioni di presentazione, non appartenenza tassonomica. |
| Pagina di destinazione per una classificazione | Archivio tassonomico, CMS Page o vista di plugin | Decidere quale oggetto possiede percorso, corpo del contenuto e insieme di risultati filtrati. |
| Category di origine usata soltanto internamente | Metadato o classificazione esterna | Non esporre per impostazione predefinita un codice operativo come archivio pubblico WordPress. |
Anche le relazioni tra termini devono avere un ambito chiaro. Un termine assegnato ai Blog Posts può avere la stessa etichetta di un termine assegnato ai Products, ma i due possono appartenere a tassonomie diverse e servire applicazioni differenti. Unirli soltanto perché il nome coincide può fondere archivi e filtri che non hanno lo stesso significato.
Metadati e campi personalizzati possono contenere dati di visualizzazione, relazioni o stato applicativo
Le API dei metadati WordPress supportano valori aggiuntivi per post, utenti, termini e commenti. Plugin e temi usano comunemente i metadati per sottotitoli, valori SEO, ID esterni, scelta dei template, riferimenti ai file, località, date, prezzi, impostazioni di visibilità, ID di relazione e stato applicativo serializzato.
Il solo schema di memorizzazione non rivela il significato. Una meta key può contenere un semplice testo, un riferimento a un altro post, un elenco di ID di termini, un ID di allegato, un array strutturato o una macchina a stati specifica del plugin. Un campo visualizzato correttamente nella piattaforma di origine può diventare inutilizzabile se la destinazione copia soltanto il valore letterale e perde la definizione del campo o l’oggetto referenziato.
| Schema dei metadati | Possibile significato | Requisito nella destinazione |
|---|---|---|
| Testo semplice o numero | Sottotitolo, specifica, data, punteggio, codice o etichetta editoriale | Collegare il valore all’oggetto corretto e renderlo disponibile nell’interfaccia di modifica prevista. |
| ID di post o allegato | Relazione con un altro record o elemento media | Ricostruire il riferimento verso il record di destinazione invece di copiare il vecchio ID numerico. |
| ID di termine | Relazione di classificazione | Ricollegare il valore alla tassonomia e al termine di destinazione. |
| ID utente | Autore, proprietario, docente, venditore, revisore o assegnatario | Mantenere il ruolo operativo, non soltanto il numero utente della piattaforma di origine. |
| Array serializzato o JSON | Campi ripetitori, layout, impostazioni, coordinate o stato di plugin | Interpretare lo schema del plugin proprietario prima di decidere se la struttura può essere trasferita. |
| Identificatore esterno | Chiave CRM, ERP, PIM, DAM o sistema legacy | Mantenerlo stabile sull’entità di destinazione che rappresenta lo stesso oggetto operativo. |
Le definizioni dei campi possono essere importanti quanto i valori. I sistemi che registrano campi personalizzati possono definire tipo di campo, valori consentiti, etichette, regole di input, ripetitori, gruppi, logica condizionale e relazioni. Copiare i valori senza tali definizioni può lasciare gli amministratori con dati che nessun editor o template sa utilizzare.
Blocchi, builder, template e dati del tema appartengono al livello di presentazione
I contenuti WordPress possono essere rappresentati come HTML dell’editor classico, markup a blocchi, shortcode, strutture specifiche dei builder, blocchi riutilizzabili, pattern, template part o impostazioni del tema. Questi livelli possono fare riferimento alla stessa CMS Page o allo stesso custom post type sottostante pur codificando la presentazione in modi differenti.
Un page builder della piattaforma di origine può memorizzare i dati di layout in post_content, metadati, custom post type, opzioni o tabelle personalizzate. Un sito basato su blocchi può memorizzare i blocchi nel record mentre il Site Editor e il tema forniscono i template che li circondano. Il modello di destinazione deve mantenere separata la proprietà dei contenuti dalla proprietà della presentazione.
| Struttura di presentazione | Cosa possiede | Cosa resta separato |
|---|---|---|
| Blocchi core nel contenuto del post | Contenuto strutturato e attributi dei blocchi per un record | Template a livello di sito, navigazione, dati dei plugin e record esterni |
| Shortcode | Istruzioni segnaposto interpretate da un plugin o tema | Configurazione effettiva del plugin o dati interrogati dallo shortcode |
| Layout del page builder | Sezioni, widget, stili e riferimenti specifici del builder | I record operativi visualizzati all’interno del layout |
| Template o template part | Struttura di rendering a livello di sito | Dati di CMS Page, Blog Post, Product, Customer o Order |
| Opzione del tema | Impostazione globale di design o visualizzazione | Contenuti editoriali trasferibili e record applicativi |
| Blocco riutilizzabile o pattern | Contenuto di presentazione riutilizzabile | Ogni istanza o entità operativa mostrata tramite il pattern |
La destinazione non deve necessariamente mantenere il formato di memorizzazione interno del builder di origine quando utilizza un sistema di rendering differente. Deve però mantenere contenuti, media, link, relazioni riutilizzabili e proprietà dei record richiesti dalla nuova implementazione.
Gli allegati media sono record con file, metadati e relazioni
I media WordPress non sono soltanto una cartella di file copiati. Gli elementi media possono essere record di tipo attachment con titoli, didascalie, descrizioni, alt text, MIME type, metadati dei file, dimensioni delle immagini, autore, date e relazioni padre. Corpi dei contenuti, metadati delle immagini in evidenza, gallerie, blocchi, campi dei plugin e sistemi esterni possono fare riferimento a tali allegati.
| Situazione dei media di origine | Rappresentazione WordPress | Conseguenza sulla relazione |
|---|---|---|
| Immagine in evidenza | Allegato più relazione con il record di contenuto | Devono essere ricostruiti sia il file sia il riferimento. |
| Immagine incorporata nel contenuto | Allegato o file esterno più URL nel contenuto | Il contenuto di destinazione deve puntare alla posizione file corretta. |
| Galleria | Più allegati più struttura di blocco, shortcode, builder o plugin | Il solo trasferimento dei file non mantiene ordine, didascalie o funzionamento della galleria. |
| Documento scaricabile | Allegato media, URL file o download gestito da plugin | Regole di accesso, destinazione dei link e percorsi sostitutivi restano parte del modello. |
| Immagine Product o di un annuncio | Allegato collegato tramite un plugin e-commerce o directory | La relazione del plugin è distinta dai normali media di una CMS Page. |
| Risorsa ospitata esternamente | URL remoto o riferimento DAM | La destinazione deve mantenere il proprietario esterno invece di inventare una relazione con un allegato locale. |
Gli ID del parent degli allegati non rappresentano sempre una mappa completa della proprietà. La stessa immagine può apparire in più record e i flussi editoriali moderni potrebbero non impostare un parent significativo. La destinazione deve ricostruire le relazioni dai riferimenti effettivi, dai campi delle immagini in evidenza, dalle gallerie, dai record dei plugin e dal markup dei contenuti invece di basarsi soltanto sulla colonna parent.
Utenti, ruoli, capacità e profili rappresentano significati di account diversi
Gli utenti WordPress forniscono l’identità di accesso, mentre ruoli e capacità definiscono le azioni consentite. I metadati utente aggiungono valori di profilo e stato specifico dei plugin. I plugin possono introdurre membership, corsi, comunità, account e-commerce, profili venditore, directory del personale, abbonamenti o relazioni con contenuti protetti.
| Identità di origine | Possibile rappresentazione WordPress | Distinzione di proprietà |
|---|---|---|
| Autore o redattore | Utente WordPress con autore dei contenuti e capacità editoriali | Proprietà dei post e cronologia delle revisioni possono essere rilevanti indipendentemente dallo stato di accesso. |
| Amministratore del sito | Utente con capacità amministrative | L’autorità amministrativa non equivale allo stato di Customer o membro. |
| Iscritto alla newsletter | Contatto marketing esterno, record di plugin o utente WordPress con privilegi limitati | Consenso marketing e appartenenza alla lista non devono essere dedotti dalla semplice esistenza di un account. |
| Membro | Utente WordPress più profilo, piano, accessi e record di stato del plugin membership | Il solo record utente non riproduce il funzionamento della membership. |
| Studente | Utente WordPress più iscrizione LMS, avanzamento, quiz e record dei certificati | La cronologia formativa appartiene al dominio dell’LMS. |
| Customer | Customer di un plugin e-commerce, utente WordPress, identità di un ospite o contatto CRM esterno | La proprietà e-commerce deve essere indicata esplicitamente. |
| Venditore o seller di marketplace | Utente più record gestiti dal plugin per venditore e payout | L’appartenenza a un ruolo non rappresenta l’intero account commerciale. |
Hash delle password, provider di autenticazione, impostazioni multifattore e identità single sign-on della piattaforma di origine potrebbero non essere trasferibili come normali campi utente. L’account può mantenere la propria identità operativa anche quando la relazione di autenticazione deve essere rappresentata in modo diverso.
Commenti, revisioni e record storici richiedono un contesto proprio
I commenti possono rappresentare discussioni del blog, Product Reviews, testimonianze, domande, messaggi di supporto o interazioni di plugin. Le revisioni rappresentano versioni precedenti di un contenuto, non record pubblici separati. Anche autosave, cestino, post programmati e post privati hanno un significato di ciclo di vita.
| Record storico | Significato in WordPress | Limite di rappresentazione |
|---|---|---|
| Commento del blog | Interazione collegata a un Blog Post o a una CMS Page | Mantenere autore, data, stato, relazione con la risposta parent e contenuto proprietario. |
| Product Review | Record simile a un commento gestito da un plugin e-commerce | Valutazione, stato di acquisto verificato, riferimento Product e significato della moderazione differiscono da un commento ordinario. |
| Discussione con thread | Gerarchia di commenti o record di un plugin per community | Relazioni padre-figlio e contesto della membership possono essere essenziali. |
| Revisione del contenuto | Versione storica di un singolo post | Non presentare le revisioni come CMS Pages o Blog Posts pubblici duplicati. |
| Record bozza, programmato, privato o nel cestino | Stato del ciclo di vita di un’entità di contenuto | Lo stato di pubblicazione deve restare distinto dalla visibilità nel menu e dalle autorizzazioni di accesso. |
I record storici possono essere esclusi intenzionalmente quando non hanno più valore operativo, ma non devono essere confusi silenziosamente con i contenuti correnti. Il modello di destinazione deve dichiarare se rappresenta il record attuale, la relativa cronologia editoriale o entrambi.
Plugin e tabelle personalizzate definiscono proprietà applicative specifiche
I plugin WordPress possono registrare custom post type, tassonomie, metadati, ruoli, endpoint REST, impostazioni ed eventi programmati. Possono anche creare tabelle database dedicate quando il dominio richiede strutture che non si adattano agli schemi core di post e metadati. Moduli, prenotazioni, membership, sistemi di apprendimento, eventi, directory, donazioni, redirect, strumenti di analisi, automazioni ed e-commerce aggiungono spesso record propri.
| Area gestita da plugin | Record che possono esistere | Requisito di rappresentazione |
|---|---|---|
| Moduli | Definizioni dei moduli, campi, invii, notifiche e integrazioni esterne | Separare la struttura riutilizzabile del modulo dalla cronologia degli invii e dai flussi di consegna. |
| Membership | Piani, abbonamenti, regole di accesso, relazioni utente e contenuti protetti | Mantenere distinti identità, diritto di accesso, pagamento e proprietà dei contenuti. |
| Sistemi di apprendimento | Corsi, lezioni, iscrizioni, avanzamento, quiz, tentativi e certificati | Mantenere le relazioni richieste dal modello formativo di destinazione. |
| Eventi e prenotazioni | Eventi, sessioni, risorse, partecipanti, prenotazioni, pagamenti e promemoria | Non appiattire calendari e relazioni di prenotazione in post generici. |
| Directory o marketplace | Annunci, proprietari, località, attributi, claim, venditori e payout | Identificare quali record sono contenuti e quali appartengono al flusso applicativo. |
| SEO e redirect | Metadati, valori canonical, campi schema, redirect e anteprime social | Collegare i valori al record proprietario del percorso corretto e mantenere separate le impostazioni a livello di sito. |
| Tabelle personalizzate | Entità su misura, cronologie, relazioni, log e chiavi di integrazione | Ricostruire lo schema operativo invece di copiare righe di tabella senza l’applicazione che le possiede. |
I nomi dei file dei plugin e gli elenchi dello stato attivo non costituiscono il modello dati. La vera mappa della proprietà deriva da post type registrati, tassonomie, chiavi dei metadati, tabelle personalizzate, ruoli utente, opzioni, eventi programmati e riferimenti esterni utilizzati dal sito.
URL, permalink, archivi e ambito Multisite fanno parte dell’identità dei record
I percorsi WordPress possono dipendere da post type, slug, CMS Page parent, data di pubblicazione, categoria, tassonomia personalizzata, impostazioni degli archivi, rewrite rule, dominio del sito ed endpoint dei plugin. Un URL della piattaforma di origine quindi non può sempre essere ricostruito dal solo titolo di destinazione.
| Elemento del percorso | Relazione del record | Implicazione nella destinazione |
|---|---|---|
| Percorso CMS Page | Slug della pagina più gerarchia parent | Spostare la pagina sotto un parent diverso può modificare l’intero percorso. |
| Permalink Blog Post | Slug del post più schema permalink configurato | Segmenti di data o Category possono far parte dell’URL storico. |
| Archivio tassonomico | Rewrite della tassonomia più slug del termine | Un termine può possedere un archivio pubblico anche senza una voce di menu. |
| Archivio custom post type | Rewrite del post type registrato e impostazioni degli archivi | Percorsi dei singoli record e dell’archivio possono richiedere identità separate. |
| Endpoint di plugin | Percorso applicativo collegato a un account, Product, corso o altra area | L’endpoint non è una normale CMS Page. |
| URL Multisite | Ambito di network, sito, dominio e percorso | I record possono appartenere a un sito mentre utenti o plugin hanno relazioni valide a livello di network. |
| Redirect | Relazione tra vecchio percorso e nuova destinazione | Il vecchio percorso resta un record di continuità anche quando cambia lo slug di destinazione. |
WordPress Multisite aggiunge un ulteriore livello di proprietà. Posts, Pages, termini, opzioni e molti record dei plugin sono specifici del sito, mentre gli utenti possono partecipare all’intero network. Plugin attivati a livello di rete e servizi esterni condivisi possono introdurre ulteriore ambito. Un’esportazione di origine che omette l’identità del sito può fondere record che erano intenzionalmente separati.
Core WordPress e plugin e-commerce devono restare modelli separati
Il core WordPress non offre nativamente Products, carrello, processo di acquisto, Customers, Orders, coupon, pagamenti, spedizioni, imposte, inventario o evasione degli ordini. Queste entità appartengono a WooCommerce o a un altro plugin e-commerce. Possono usare post type, tassonomie, utenti, metadati, commenti e tabelle WordPress, ma il loro significato operativo deriva dall’applicazione e-commerce.
| Concetto e-commerce | Relazione con il core WordPress | Proprietario effettivo |
|---|---|---|
| Product e variante | Possono usare custom post type, tassonomie, metadati o tabelle dedicate | Plugin e-commerce e relative estensioni |
| Customer | Può collegarsi a un utente WordPress o restare un’identità di transazione di un ospite | Plugin e-commerce, CRM, sistema membership o piattaforma account esterna |
| Order e righe Order | Possono usare custom post type o tabelle e-commerce dedicate | Plugin e-commerce ed estensioni per pagamento o evasione degli ordini |
| Product Review | Può usare commenti più metadati della valutazione | Modello Product Review del plugin e-commerce |
| Abbonamento, prenotazione, bundle o record venditore | Può fare riferimento a Products, utenti e Orders | Estensione specializzata o applicazione marketplace |
| Contesto pagamenti, imposte, spedizioni ed evasione degli ordini | Può apparire nei record delle transazioni storiche | Integrazioni e-commerce e operative, non contenuti del core WordPress |
Una migrazione WordPress e una migrazione WooCommerce sono quindi ambiti differenti anche quando usano la stessa installazione. La destinazione deve identificare plugin e-commerce, relativa versione e modello di memorizzazione, estensioni installate e sistemi esterni prima di interpretare Products, Customers, Orders o record specifici dell’applicazione.
Una mappa di rappresentazione WordPress deve mantenere proprietà e modificabilità
Il modello di destinazione è coerente quando ogni record ha un tipo, un proprietario, un sistema di classificazione, un contratto dei metadati, un percorso e un’interfaccia di modifica definiti. L’obiettivo non è copiare il design del database di origine. È mantenere le relazioni che consentono a redattori, amministratori, applicazioni e sistemi esterni di comprendere i dati.
| Domanda sulla piattaforma di origine | Decisione di rappresentazione |
|---|---|
| Il record è contenuto editoriale o un’entità applicativa? | Scegliere un post type core, custom post type, record di plugin o proprietario in un sistema esterno. |
| Un raggruppamento classifica record o organizza soltanto la navigazione? | Separare relazioni tassonomiche da menu e pagina di destinazione. |
| Un valore personalizzato contiene dati o fa riferimento a un altro oggetto? | Ricostruire sia il valore sia la relazione con l’oggetto di destinazione. |
| Il layout è memorizzato insieme al contenuto o in un sistema builder/template? | Mantenere il significato del contenuto separato dall’implementazione della presentazione. |
| Un account è soltanto un’identità di accesso o fa parte di membership, formazione, e-commerce o sistema venditore? | Mantenere utente WordPress e profilo applicativo come record distinti ma collegati. |
| Un URL deriva da slug, gerarchia, archivio, endpoint di plugin o ambito Multisite? | Mantenere la relazione che possiede il percorso invece di affidarsi ai titoli. |
| L’entità appartiene al core WordPress, a un plugin, a una tabella personalizzata o a una piattaforma esterna? | Rendere esplicito il proprietario effettivo e mantenere identificatori stabili tra sistemi. |
Queste decisioni mantengono gestibile il sito migrato. I redattori trovano i record corretti, i template mostrano gli oggetti previsti, archivi e filtri interrogano le classificazioni giuste, gli account mantengono il proprio significato applicativo e le integrazioni continuano a identificare le stesse entità operative.
Conclusione
WordPress modifica il significato dei dati perché utilizza tabelle core riutilizzabili per molti tipi di record, consentendo al contempo a plugin e codice personalizzato di definire applicazioni specializzate. Posts, CMS Pages, custom post type, tassonomie, metadati, allegati, utenti, commenti, opzioni, tabelle dei plugin, percorsi ed entità e-commerce possono condividere infrastruttura senza condividere il significato operativo.
Una migrazione coerente mantiene questa proprietà. I contenuti restano collegati al post type e alla tassonomia corretti, i metadati restano collegati al relativo contratto di campo e ai record referenziati, i media restano collegati ai contenuti che li utilizzano, gli utenti restano collegati a ruoli e profili applicativi, i percorsi restano collegati agli oggetti che li possiedono e i record di plugin o e-commerce restano separati dai normali contenuti del core WordPress.
Domande frequenti
I custom post type di WordPress sono equivalenti alle CMS Pages?
No. Entrambi possono essere memorizzati tramite il sistema dei post WordPress, ma un custom post type può avere funzionalità dell’editor, tassonomie, capacità, metadati, archivio, comportamento REST e template propri. La destinazione deve mantenere il tipo che rappresenta lo scopo operativo del record.
Ogni Category della piattaforma di origine può diventare una Category WordPress?
No. Il raggruppamento di origine può appartenere a una Category standard, un tag, una tassonomia personalizzata, una tassonomia e-commerce, un menu di navigazione, un campo metadati, un filtro di plugin o una classificazione esterna. La scelta dipende da ciò che il raggruppamento classifica e dal modo in cui la destinazione deve interrogarlo o visualizzarlo.
Perché i campi personalizzati di WordPress sono sensibili alle relazioni?
Un campo personalizzato può contenere un valore letterale, l’ID di un altro record, un riferimento ad allegato, un termine, un utente, una struttura serializzata o uno stato del plugin. Copiare il valore visibile senza ricostruire la relazione o la definizione del campo può rendere inutilizzabili i dati di destinazione.
Temi e page builder possiedono i record operativi sottostanti?
Normalmente no. Possiedono strutture di presentazione, template, stili e riferimenti di layout. La CMS Page, il Blog Post, il Product, l’evento, l’annuncio o un’altra entità restano di proprietà del core WordPress o del plugin pertinente anche quando un builder controlla il modo in cui vengono visualizzati.
I Products WooCommerce devono essere trattati come normali post WordPress?
No. WooCommerce può utilizzare l’infrastruttura WordPress, ma Products, varianti, Customers, Orders, coupon, inventario, pagamenti, spedizioni, imposte ed estensioni appartengono al modello e-commerce WooCommerce. Le loro relazioni richiedono un’interpretazione specifica per il commercio.
Quando i dati WordPress devono risiedere in una tabella personalizzata o in un sistema esterno anziché in un post type?
Il proprietario è determinato dall’applicazione che gestisce il record. Transazioni ad alto volume, cronologie specializzate, relazioni molti-a-molti complesse, log di integrazione o flussi operativi specifici del dominio possono risiedere in tabelle dei plugin o piattaforme esterne. Il modello di migrazione deve mantenere l’entità e i relativi riferimenti senza costringerla in un post generico soltanto perché WordPress è il framework del sito.