La validazione di WordPress deve dimostrare che il sito migrato rimanga gestibile come ambiente di contenuti e applicazioni. Una CMS Page può esistere nel database mentre la gerarchia padre-figlio, l’immagine in evidenza, il collegamento nel menu, i campi personalizzati, il template della pagina o il percorso pubblico sono errati. Un custom post type può conservare titoli e contenuti ma perdere tassonomie, contratto dei metadati, autorizzazioni, archivio o funzionamento del plugin che rendevano utili i record.
Le evidenze devono quindi seguire la reale proprietà dei dati in WordPress. Post principali, CMS Pages, allegati, tassonomie, termini, utenti, ruoli, commenti, metadati, menu e opzioni richiedono verifiche differenti. Custom post type gestiti da plugin, tabelle personalizzate, dati dei builder, membership, moduli, eventi, directory, corsi o identificatori esterni devono essere verificati attraverso l’applicazione che li utilizza. I totali dei record aiutano la riconciliazione, ma da soli non possono autorizzare la messa in esercizio.
Definire le evidenze WordPress e le decisioni di messa in esercizio
Ogni rilievo significativo deve concludersi con uno dei seguenti stati decisionali:
- Pass: evidenze rappresentative e casi eccezionali dimostrano che il record migrato è modificabile, individuabile, correttamente collegato e utilizzabile attraverso il componente WordPress che ne è responsabile.
- Watch: il risultato è utilizzabile, ma rimane una correzione non bloccante documentata, un’attività di configurazione della piattaforma di destinazione, un adeguamento manuale della presentazione o una differenza accettata della piattaforma.
- Block: il problema incide in modo sostanziale sull’accesso ai contenuti, sui permessi degli account, sui percorsi pubblici, sulla visibilità sui motori di ricerca, sul funzionamento delle applicazioni, sulla conformità o sull’ambito di migrazione concordato.
| Area di evidenza | Evidenza richiesta in WordPress | Condizione Block tipica |
|---|---|---|
| Contenuti principali | Blog Posts e CMS Pages mantengono contenuto, stato, autore, date, gerarchia, media, metadati e percorso previsto. | Una pagina prioritaria manca, non è accessibile o non è più modificabile attraverso il flusso di lavoro previsto. |
| Contenuti strutturati | Custom post type, tassonomie, termini, metadati e archivi mantengono il modello applicativo. | Un tipo di record rilevante viene appiattito in contenuto generico oppure perde campi e classificazioni necessari. |
| Identità e accesso | Utenti, ruoli, capability, paternità dei contenuti, membership e contenuti riservati rispettano la proprietà prevista. | Utenti non autorizzati possono accedere a record riservati oppure utenti necessari perdono l’accesso. |
| Presentazione | Blocchi, template, strutture dei builder, menu e riferimenti ai media supportano il risultato pubblico previsto. | Un percorso essenziale per la messa in esercizio è inutilizzabile anche se il testo è presente. |
| Ambito dei plugin | Record dei plugin e tabelle personalizzate hanno un proprietario esplicito nella destinazione e un risultato utilizzabile. | Un flusso di lavoro di un plugin critico per il business perde record, relazioni o identificatori. |
| URL e SEO | Permalink, archivi, metadati, link interni e redirect mantengono i percorsi prioritari di scoperta e accesso. | Un percorso di alto valore non funziona e non esiste una destinazione approvata. |
Il registro decisionale deve indicare l’esatto post type, tassonomia, plugin, percorso, ruolo utente o contesto Multisite verificato. Una decisione generica come “i contenuti WordPress sono approvati” è troppo ampia quando la stessa installazione può contenere più applicazioni indipendenti.
Usare test rappresentativi per verificare il vero modello dei contenuti
I test rappresentativi devono mettere in evidenza le relazioni che rendono specifico il sito WordPress. Seleziona campioni come:
- un normale Blog Post con categorie, tag, autore, immagine in evidenza, commenti e permalink rilevante per la SEO;
- una CMS Page con gerarchia padre-figlio, posizione nel menu, template assegnato, media incorporati e link interni;
- record di ciascun custom post type importante;
- tassonomie personalizzate gerarchiche e non gerarchiche con assegnazioni rappresentative dei termini;
- metadati che memorizzano valori letterali, riferimenti ad allegati, relazioni tra post, riferimenti a termini, riferimenti a utenti o stato serializzato di plugin;
- gallerie multimediali, file scaricabili e allegati riutilizzati;
- utenti con ruoli, capability, paternità dei contenuti o profili gestiti da plugin differenti;
- pagine dipendenti da builder, shortcode, blocchi riutilizzabili o template;
- un percorso per ogni archivio o endpoint di plugin importante;
- record gestiti da plugin o tabelle personalizzate inclusi nell’ambito.
Un risultato del test rappresentativo è Block quando rivela un’ipotesi strutturale che verrebbe ripetuta nell’esecuzione più ampia della migrazione. Esempi: custom post type trasformati in CMS Pages, vecchi ID numerici copiati invece di essere convertiti in riferimenti ai nuovi record, termini di tassonomia ridotti a etichette scollegate oppure un profilo di membership trasferito senza l’utente WordPress e le relazioni con i contenuti protetti di cui ha bisogno.
Il test rappresentativo della migrazione non deve dimostrare la completezza dei volumi. Deve dimostrare che le evidenze selezionate rappresentano il modello WordPress reale e che gli amministratori possono ripetere la verifica sia nella dashboard sia sul sito pubblico.
Validare Blog Posts, CMS Pages, categorie, tag e menu
La validazione dei contenuti principali deve verificare il record completo, non soltanto titolo e corpo. Stato di pubblicazione, autore, date, estratti, media in evidenza, commenti, gerarchia, protezione tramite password, stato sticky, revisioni quando incluse e funzionamento dei percorsi possono tutti modificare il modo in cui WordPress tratta il record.
| Evidenza sui contenuti principali | Pass | Watch | Block |
|---|---|---|---|
| Blog Post | Contenuto, autore, date, categorie, tag, immagine in evidenza, stato e permalink sono coerenti. | Una tassonomia a bassa priorità o un dettaglio di presentazione richiede pulizia. | La cronologia editoriale o un percorso di pubblicazione prioritario è materialmente errato. |
| CMS Page | Contenuto, gerarchia padre-figlio, contesto del template, collegamento nel menu e percorso pubblico sono corretti. | Rimane un adeguamento minore nell’ordine dei menu o nel template. | Una pagina prioritaria è orfana, privata o indirizzata al percorso sbagliato. |
| Categoria o tag | Identità del termine, gerarchia quando prevista, record assegnati, metadati e comportamento dell’archivio sono corretti. | La presentazione facoltativa dell’archivio richiede un adeguamento. | Una classificazione prioritaria non può essere interrogata oppure espone record non pertinenti. |
| Voce di menu | Destinazione, gerarchia, etichetta, accesso e stato attivo sono corretti. | Rimane un ordinamento non critico. | Un percorso principale per i visitatori porta alla destinazione sbagliata o a un URL non funzionante. |
| Commento | Contenuto padre, autore, data, stato, gerarchia delle risposte e significato della moderazione restano comprensibili. | Rimane una pulizia di moderazione a basso valore. | Si perde una relazione necessaria con una discussione o recensione. |
Categorie e menu richiedono evidenze separate. Una categoria può esistere e classificare correttamente i Blog Posts mentre il menu continua a puntare a un percorso obsoleto. Al contrario, un menu può caricare un percorso mentre l’archivio associato contiene i record sbagliati. La decisione di messa in esercizio deve riflettere entrambe le strutture in modo indipendente.
Multisite richiede evidenze consapevoli del singolo sito. Blog Posts, CMS Pages, termini, opzioni, menu e molti record dei plugin appartengono a un sito specifico della rete, mentre gli utenti possono partecipare a più siti. Un record trovato sul sito sbagliato non rappresenta una migrazione riuscita anche se il contenuto è integro.
Validare custom post type, tassonomie e contratti dei metadati
I custom post type definiscono record specifici dell’applicazione, come eventi, risorse, membri dello staff, immobili, corsi, annunci o casi di studio. La validazione deve coprire il tipo registrato, l’interfaccia di modifica, le capability, le tassonomie, i metadati, i percorsi pubblici, gli archivi e il template o plugin che consuma il record.
| Record strutturato | Evidenza richiesta |
|---|---|
| Custom post type | Il record compare sotto il tipo previsto, supporta i campi necessari nell’editor e viene visualizzato tramite i percorsi singoli e di archivio previsti. |
| Tassonomia personalizzata | I termini restano nel vocabolario corretto, conservano la gerarchia quando richiesta e classificano i post type previsti. |
| Relazione tra post | I riferimenti puntano ai record corretti nella destinazione anziché ai vecchi ID della sorgente. |
| Riferimento a media | ID e URL degli allegati risolvono il file migrato e mantengono il contesto della galleria o dell’immagine in evidenza. |
| Riferimento a utente | Le relazioni con autore, proprietario, docente, venditore, recensore o assegnatario puntano all’utente previsto. |
| Metadati serializzati o strutturati | Il plugin o sistema di campi che li possiede può interpretarli senza troncamenti silenziosi o riferimenti interrotti. |
| Definizione dei campi | Etichette, tipi di campo, valori ammessi, repeater, gruppi e relazioni condizionali restano utilizzabili quando inclusi nell’ambito. |
Un valore può apparire correttamente ma essere strutturalmente errato. Per esempio, un campo relazione della sorgente può mostrare il titolo di un Product come testo, mentre l’applicazione di destinazione può richiedere un riferimento a un oggetto post per supportare filtri e aggiornamenti. Il risultato è Block quando la relazione alimenta un flusso di lavoro essenziale per la messa in esercizio; non è approvato soltanto perché il titolo è visibile.
La validazione deve inoltre distinguere dati pubblici e dati amministrativi. Un ID CRM esterno potrebbe non comparire mai sul sito pubblico, ma può essere comunque essenziale per il lancio se sincronizzazione, reportistica o riconciliazione dipendono da esso.
Validare media, blocchi, builder, template e visualizzazione pubblica
La presentazione WordPress può combinare record degli allegati, markup dei blocchi, shortcode, blocchi riutilizzabili, pattern, template part, metadati dei builder, opzioni del tema, menu, widget e output dei plugin. L’obiettivo della validazione non è una riproduzione pixel-per-pixel, a meno che non sia inclusa esplicitamente nell’ambito. L’obiettivo è ottenere contenuti utilizzabili con proprietà, riferimenti e risultato di presentazione approvato.
| Evidenza sulla presentazione | Pass | Watch | Block |
|---|---|---|---|
| Media | I file si aprono, i metadati degli allegati sono coerenti e immagini in evidenza o gallerie fanno riferimento ai record corretti. | Didascalie secondarie, ordinamento o dimensioni richiedono pulizia. | Media prioritari mancanti o collegati ai contenuti sbagliati. |
| Blocchi core | La struttura dei blocchi rimane modificabile e viene visualizzata senza riferimenti interrotti. | Restano differenze minori di spaziatura o tema. | Il contenuto diventa markup non valido o perde dati incorporati essenziali. |
| Shortcode | Il plugin proprietario o la soluzione sostitutiva visualizza il contenuto previsto. | Rimane una sostituzione manuale documentata. | Una pagina prioritaria espone testo shortcode grezzo o perde una funzione necessaria. |
| Page builder | I contenuti importanti sono modificabili nel builder previsto oppure hanno un risultato di ricostruzione approvato. | Rimane un perfezionamento non critico del layout. | Una pagina essenziale per il lancio è vuota, non funziona o resta intrappolata in metadati inutilizzabili. |
| Contesto del template o tema | Si applicano il template corretto del record e il corretto contesto di navigazione. | Rimane una rifinitura visiva fuori dall’ambito della migrazione. | I visitatori non possono usare la pagina oppure gli amministratori non possono mantenerla. |
Il rapporto delle evidenze deve classificare se un problema di presentazione appartiene ai contenuti migrati, alla configurazione del tema di destinazione, alla compatibilità del builder, a una ricostruzione manuale o a un risultato di migrazione non standard concordato. Questa attribuzione evita di confondere correzioni dei contenuti con l’implementazione completa del sito.
Includi evidenze sia dal lato editor sia dal lato visitatore. Gli editor devono poter trovare il record, comprenderne i componenti riutilizzabili, sostituire i media e aggiornare la pagina senza dipendere dai vecchi ID della sorgente. Le evidenze dal lato visitatore devono coprire output responsive, risorse incorporate, sezioni interattive e qualsiasi contesto di login o plugin che modifichi la visualizzazione. In questo modo si distingue una semplice variazione cosmetica da una struttura che non è più mantenibile.
Validare utenti, ruoli, capability e profili gestiti dai plugin
Un utente WordPress è un’identità di accesso, non un profilo aziendale universale. Lo stesso utente può anche essere autore di Blog Posts, appartenere a un piano membership, rappresentare uno studente di un corso, gestire un account venditore oppure avere un profilo specifico di un plugin. La validazione deve dimostrare sia l’identità principale sia le relazioni applicative incluse nell’ambito.
| Evidenza sull’identità | Verifica richiesta |
|---|---|
| Utente core | Identità username o email, nome visualizzato, stato dell’account e campi profilo necessari sono corretti. |
| Ruolo e capability | L’utente può eseguire le azioni previste ed è impedito nell’esecuzione di azioni non autorizzate. |
| Paternità | Blog Posts prioritari e record personalizzati restano assegnati all’autore o proprietario previsto. |
| Contenuti riservati | Le relazioni con gruppi utenti, membership o accesso espongono soltanto i record previsti. |
| Profilo plugin | Record di membership, apprendimento, directory, venditore, donatore o comunità restano collegati all’utente corretto. |
| Confine di autenticazione | Password, single sign-on o requisiti di autenticazione multifattore hanno un esito approvato per l’accesso all’account. |
Usa utenti rappresentativi per ogni ruolo rilevante, compresi utenti con ruoli sovrapposti o relazioni con plugin. Il nome del ruolo può sembrare corretto anche quando le capability sono diverse. Un record utente può esistere mentre la membership o i progressi di un corso sono scollegati. Questi risultati richiedono evidenze e decisioni separate.
Le evidenze sugli account devono coprire anche utenti disabilitati o inattivi, email duplicate, username modificati e account che devono mantenere la paternità dei contenuti senza ricevere accesso. Quando un plugin crea un proprio profilo o record organizzativo, verifica la direzione della relazione: l’utente WordPress deve puntare al record applicativo previsto e l’applicazione deve restituire la stessa identità quando gli amministratori la verificano.
Validare record dei plugin, tabelle personalizzate e confini con il commercio
I plugin possono memorizzare record tramite custom post type, metadati, opzioni, commenti, eventi pianificati o tabelle dedicate. La validazione deve seguire il vero proprietario invece di presumere che ogni record sia contenuto WordPress ordinario.
| Area gestita da plugin | Evidenze da raccogliere | Indicatore per la decisione di lancio |
|---|---|---|
| Moduli | Definizione del modulo, campi, instradamento, invii quando inclusi, notifiche e riferimenti esterni | Block quando un modulo necessario o la cronologia degli invii concordata è inutilizzabile. |
| Membership | Piani, relazioni con utenti, stato, regole di accesso e contenuti protetti | Block quando i membri attivi ricevono accessi errati. |
| Sistemi di apprendimento | Corsi, lezioni, iscrizioni, progressi, tentativi e certificati | Block quando la cronologia o l’accesso degli studenti non possono essere riconciliati. |
| Eventi o prenotazioni | Eventi, sessioni, risorse, partecipanti, prenotazioni e date | Block quando impegni programmati o prenotazioni sono errati. |
| Directory o marketplace | Annunci, proprietari, tassonomie, località, richieste, venditori o pagamenti | Block quando proprietà o scoperta pubblica risultano sostanzialmente errate. |
| Plugin di redirect o SEO | Metadati, valori canonical, campi schema e regole di redirect | Block quando vengono persi percorsi prioritari o segnali di ricerca. |
| Plugin commerce | Products, Customers, Orders, pagamenti, spedizione, Tax, inventario ed estensioni | Validare secondo il ruolo della piattaforma e-commerce pertinente, non come contenuti WordPress core. |
I risultati di migrazione standard approvati devono essere validati rispetto al requisito supportato selezionato e al campo o record di destinazione previsto. I risultati di migrazione non standard devono essere validati rispetto alla trasformazione, relazione, tabella personalizzata o requisito relativo agli ID esterni approvato. Nessuno dei due casi dimostra che un plugin, tema o integrazione non correlato sia stato implementato completamente, a meno che quel lavoro non sia incluso esplicitamente.
Per ciascun dominio di plugin incluso, scegli almeno un record ordinario, un record eccezionale e un record con molte relazioni. Le evidenze devono mostrare non soltanto che i valori sono stati trasferiti, ma che l’applicazione di destinazione può interrogarli, modificarli e visualizzarli attraverso le proprie interfacce supportate. I record conservati soltanto come archivio devono essere etichettati chiaramente, per evitare che vengano scambiati per dati applicativi attivi.
Validare completezza dell’esecuzione più ampia e azioni successive
Le evidenze dell’esecuzione più ampia devono passare dalla struttura rappresentativa alla completezza dell’ambito e alla copertura delle eccezioni. Riconcilia i totali per tipo e stato di record, poi analizza le differenze anziché considerare l’uguaglianza dei conteggi come unico obiettivo. Includi allegati orfani, slug duplicati, record non pubblicati, autori mancanti, termini non assegnati, relazioni interrotte, ambito Multisite e record dei plugin esclusi o gestiti separatamente.
Le attività successive richiedono una nuova validazione specifica per l’azione:
| Azione successiva | Evidenze WordPress da ripetere |
|---|---|
| continuare con la configurazione accettata | Conferma che i record nuovi o modificati continuino a utilizzare gli stessi post type, tassonomie, definizioni di campo, ambito del sito, regole dei percorsi e relazioni dei plugin. Ricontrolla i conflitti con modifiche già effettuate nello store di destinazione. |
| continuare con una configurazione rivista | Rivalida ogni mappatura modificata, selezione dei tipi di dati, regola dei campi, destinazione delle tassonomie, regola dei media e decisione sulla gestione dei plugin. L’approvazione precedente non copre la configurazione modificata. |
| produrre un nuovo risultato di migrazione distinto | Tratta il nuovo risultato come un insieme di evidenze indipendente. Ripeti la verifica di struttura, identità, percorsi, plugin e decisione di lancio senza ereditare l’approvazione del risultato precedente. |
Creare il registro decisionale per la messa in esercizio di WordPress
Il rapporto finale deve essere riproducibile e organizzato per proprietario. Registra:
- il post type, la tassonomia, il ruolo utente, il plugin, il sito o il percorso verificato;
- gli identificatori di origine e destinazione necessari alla riconciliazione;
- il risultato atteso e le evidenze osservate;
- la decisione Pass, Watch o Block;
- il responsabile di qualsiasi correzione o attività di configurazione sulla piattaforma di destinazione;
- se il rilievo influisce sul lancio, su una successiva attività di migrazione oppure soltanto su una pulizia non bloccante;
- le evidenze necessarie per chiudere il rilievo.
Un Pass richiede che contenuti e record applicativi prioritari siano comprensibili, modificabili, individuabili, coerenti con i permessi e collegati ai percorsi pubblici o ai flussi dei plugin previsti. Un elemento Watch ha un responsabile definito e non compromette questi risultati. Rimane Block quando il sito pubblicherebbe percorsi prioritari non funzionanti, esporrebbe contenuti riservati, perderebbe record applicativi o impedirebbe agli amministratori di mantenere contenuti essenziali.
Conclusione
La validazione di WordPress deve seguire la proprietà dei dati, non la somiglianza tra tabelle. Blog Posts, CMS Pages, allegati, termini, utenti, commenti, metadati, menu, custom post type, record dei plugin, percorsi e strutture di presentazione possono condividere la stessa infrastruttura ma richiedono evidenze differenti.
I test rappresentativi dimostrano il modello dei contenuti e delle applicazioni. L’esecuzione più ampia dimostra la completezza dell’ambito e la gestione delle eccezioni. Le azioni di migrazione successive richiedono una nuova validazione mirata dei record e della configurazione modificati. La messa in esercizio viene approvata solo quando le evidenze supportano contenuti utilizzabili, accessi corretti, percorsi affidabili, relazioni con i plugin mantenibili e decisioni Pass, Watch o Block esplicite.
Domande frequenti
È sufficiente controllare il numero di record WordPress dopo la migrazione?
No. I conteggi non possono dimostrare che i record usino il post type corretto, la tassonomia prevista, il contratto dei metadati, l’ambito del sito, la relazione con l’utente, il plugin proprietario, il percorso o la struttura di presentazione. Sono utili per la riconciliazione, ma devono essere accompagnati da evidenze sul funzionamento e sulle relazioni.
Perché i custom post type devono essere validati separatamente dalle CMS Pages?
I custom post type possono avere tassonomie, metadati, capability, archivi, comportamento REST, template e plugin che li utilizzano differenti. Appiattirli in CMS Pages può conservare il testo visibile ma eliminare il modello applicativo.
Come deve essere classificato il contenuto dei page builder?
Verifica contenuto, riferimenti, interfaccia di modifica e risultato pubblico richiesto. Il risultato può ottenere Pass quando il contenuto è utilizzabile attraverso il builder previsto o attraverso un risultato di ricostruzione approvato. Deve invece Blockare il lancio quando una pagina prioritaria è vuota, non funziona o non è più mantenibile.
I record dei plugin devono essere validati come normali contenuti WordPress?
No. Devono essere validati attraverso il plugin o l’applicazione sostitutiva che possiede campi, relazioni, permessi e flussi di lavoro. La sola presenza in WordPress core non dimostra il corretto funzionamento di membership, corsi, prenotazioni, moduli, directory o commercio.
Che cosa deve essere ricontrollato dopo un’azione di migrazione successiva?
Ricontrolla record nuovi e modificati, regole di mappatura, assegnazioni delle tassonomie, riferimenti, proprietà degli utenti, media, percorsi, relazioni dei plugin e conflitti con modifiche nello store di destinazione. Per WordPress, una configurazione modificata o una migrazione distinta richiede evidenze più ampie su post type, tassonomie, utenti, media, percorsi e plugin rispetto alla semplice continuazione della configurazione invariata.
Quando un rilievo WordPress deve impedire la messa in esercizio?
Usa Block quando un problema rilevante impedisce ad amministratori o visitatori di utilizzare contenuti prioritari, espone record riservati, interrompe un percorso di alto valore, scollega dati di plugin critici per il business o viola il risultato di migrazione concordato.