La validazione di Joomla deve dimostrare che i record migrati continuano a formare pagine, route, autorizzazioni, relazioni linguistiche e flussi gestiti dalle estensioni realmente utilizzabili. Un Article può esistere mentre Category, voce di menu, livello di accesso, associazione linguistica, contesto dei moduli, stile del template o alias producono un risultato pubblico errato. Un utente può esistere mentre i gruppi e i livelli di accesso alla visualizzazione assegnati espongono troppo o troppo poco contenuto.
Joomla separa inoltre i record CMS core dai record di componenti ed estensioni. Products, Customers, Orders, form, directory, prenotazioni, membership e strutture di builder di pagine possono utilizzare l’infrastruttura Joomla pur restando di proprietà del relativo componente. La validazione deve seguire questi responsabili, anziché trattare ogni riga come un Article o un utente.
Definire le prove Joomla e le decisioni di lancio
Utilizzare uno stato decisionale unico per ogni area di prova rilevante:
- Pass: prove rappresentative e casi di eccezione dimostrano il risultato previsto per contenuti, route, accessi, lingue, composizione della pagina o estensioni Joomla.
- Watch: il risultato è utilizzabile, ma resta una correzione non bloccante documentata, un’attività di configurazione sulla destinazione, un adeguamento manuale della presentazione o una differenza accettata.
- Block: il problema incide in modo sostanziale su accesso pubblico, contenuti riservati, continuità multilingua, route importanti, record delle estensioni, storico e-commerce, conformità o ambito di migrazione concordato.
| Area di prova | Prova richiesta in Joomla | Condizione tipica di Block |
|---|---|---|
| Contenuti core | Articles e Categories mantengono contenuti, stato, gerarchia, lingua, accesso, metadati e possibilità di modifica. | Un Article prioritario manca, è assegnato in modo errato o non è accessibile al pubblico previsto. |
| Menu e route | Voci di menu, alias, relazioni padre-figlio, pagine home, viste dei componenti e redirect conducono alle destinazioni approvate. | Una route di valore elevato risolve verso l’elemento, la lingua o il contesto di accesso sbagliati. |
| Identità e ACL | Utenti, gruppi, autorizzazioni, livelli di accesso alla visualizzazione e record riservati corrispondono alla policy prevista. | Utenti non autorizzati possono vedere o modificare contenuti riservati oppure utenti necessari perdono l’accesso. |
| Multilingua | Lingue, associazioni, strutture di menu e contenuti specifici per lingua restano collegati. | Un percorso prioritario in una lingua non può essere completato. |
| Composizione della pagina | Moduli, posizioni, stili di template, override e output dei componenti supportano le pagine prioritarie. | Una pagina essenziale per il lancio non può essere compresa o utilizzata. |
| Ambito delle estensioni | Record dei componenti e output di migrazione non standard restano collegati ai relativi responsabili. | Record essenziali per l’attività appartenenti a un’estensione o all’e-commerce risultano mancanti o scollegati. |
Una decisione Joomla deve identificare l’Article, la Category, la voce di menu, la vista del componente, la lingua, il livello di accesso, lo stile del template, la posizione del modulo o il record di estensione esaminato. Un Pass assegnato all’intero sito non deve nascondere un errore limitato a una lingua o a un pubblico con accesso riservato.
Utilizzare test rappresentativi per dimostrare le relazioni Joomla
I test rappresentativi devono includere record che mettano alla prova il modello di pagina Joomla:
- un Article con Category, autore, metadati, stato, accesso, lingua e media;
- Categories annidate utilizzate da layout List o Blog;
- una voce di menu che punta direttamente a un Article e una voce Category Blog o Category List;
- una gerarchia di menu con alias, voci padre, accesso, lingua e voce home predefinita;
- un Article riservato o una vista di componente collegata a un livello di accesso non pubblico;
- utenti rappresentativi appartenenti a diversi gruppi utenti;
- Articles, Categories, menu e associazioni multilingua quando utilizzati;
- una pagina composta da output del componente, moduli, stile di template e funzionamento degli override;
- un record da ogni estensione o componente e-commerce importante incluso nell’ambito;
- route prioritarie, redirect, media e campi personalizzati.
Il risultato di un test rappresentativo è un Block quando rivela un presupposto strutturale che verrebbe ripetuto nell’esecuzione più ampia della migrazione. Esempi: Articles assegnati alla Category sbagliata, alias di menu che creano route duplicate o errate, utenti con livello di accesso sbagliato, associazioni multilingua perse oppure record di estensioni scollegati dal componente che li gestisce.
Il test rappresentativo dimostra il modello delle relazioni e il metodo di verifica. Non deve riprodurre il volume completo, ma deve essere sufficientemente ampio da consentire ai responsabili di contenuti, accessi, lingue, presentazione ed estensioni di ripetere la revisione.
Validare Articles, Categories, tag, campi e contenuti core
Gli Articles Joomla devono mantenere titolo, alias, contenuto, struttura intro/full-text quando pertinente, stato, presenza in home o in evidenza, autore, date, Category, lingua, livello di accesso, tag, campi personalizzati, metadati, immagini e collegamenti. Le Categories hanno una propria gerarchia, accesso, lingua, metadati e layout pubblici.
| Prova sui contenuti core | Pass | Watch | Block |
|---|---|---|---|
| Article | Contenuto, stato, autore, Category, lingua, accesso, metadati e media sono coerenti. | Restano piccole correzioni di formattazione o metadati opzionali. | Un Article prioritario manca, non è accessibile o è assegnato al contesto sbagliato. |
| Category | Gerarchia, lingua, accesso, descrizione, metadati e appartenenza degli Articles sono corretti. | Restano correzioni di ordinamento a bassa priorità. | Una famiglia di contenuti prioritaria non può essere trovata o viene esposta in modo errato. |
| Tag | Termini e assegnazioni supportano la scoperta trasversale prevista. | Restano normalizzazioni non critiche. | Una classificazione o un filtro necessario non è utilizzabile. |
| Campo personalizzato | Gruppo, tipo, valore, contesto di visualizzazione e template o estensione che lo utilizza sono corretti. | Resta una rifinitura facoltativa della visualizzazione. | Un campo pubblico o operativo necessario viene perso. |
| Media | Immagini e file si risolvono correttamente da Articles, Categories, campi e moduli. | Didascalie secondarie o dimensioni richiedono pulizia. | Un media prioritario manca o punta al record sbagliato. |
Categories e menu Joomla non costituiscono la stessa gerarchia. Una Category può superare la validazione mentre la relativa voce di menu pubblica è assente o configurata in modo errato. Al contrario, una voce di menu può caricare una pagina mentre la Category sottostante contiene gli Articles sbagliati. Validare separatamente struttura dei dati e struttura delle route.
Quando questi stati esistono, includere esempi archiviati, non pubblicati, in evidenza, programmati e con accesso riservato. Gli amministratori devono poter filtrare e modificare i record nelle viste di gestione previste, mentre i visitatori devono vedere soltanto quelli destinati alla propria lingua e al proprio contesto di accesso. In questo modo un campione limitato alle pagine pubbliche non nasconde difetti amministrativi o del ciclo di vita.
Validare menu, alias, route, redirect e contesto home
Le route Joomla sono fortemente influenzate dalle voci di menu. Una voce può puntare a un singolo Article, una Category Blog, una Category List, una vista di componente, un URL esterno o un’altra route. Può inoltre controllare alias, gerarchia padre-figlio, lingua, accesso, stato home predefinito, stile di template e parametri di layout.
| Prova sulla route | Prova richiesta |
|---|---|
| Voce Article diretta | L’Article previsto si apre con alias, lingua, accesso e contesto di template approvati. |
| Category Blog o List | La Category e l’ambito delle sottocategorie corretti producono Articles e ordinamento previsti. |
| Vista di componente | La voce di menu punta al componente, alla vista e al contesto del record corretti. |
| Menu padre-figlio | Gerarchia, ordinamento, etichette, accesso e stati attivi supportano la navigazione. |
| Voce home | Esiste la voce predefinita corretta per ogni lingua e contesto del sito applicabile. |
| Redirect | I vecchi percorsi di alto valore risolvono verso route Joomla approvate senza loop o destinazioni nella lingua sbagliata. |
| Collegamento interno | Collegamenti da Articles, moduli, campi ed estensioni non dipendono più da alias o ID obsoleti della Source Platform. |
Una route non deve ricevere Pass soltanto perché restituisce una pagina. La pagina deve mostrare output del componente, contesto Article o Category, lingua, regola di accesso, metadati, moduli e stile di template previsti.
Testare le route da più punti di ingresso: URL diretto, navigazione del menu, collegamento interno da un Article, collegamento da un modulo, selettore di lingua e risultato di ricerca quando applicabile. Joomla può produrre Itemid e contesti dei moduli differenti per lo stesso record di componente, quindi le prove devono confermare che la route approvata carichi anche la composizione della pagina e i metadati previsti.
Validare utenti, gruppi, autorizzazioni e livelli di accesso alla visualizzazione
L’autorizzazione Joomla combina utenti, gruppi gerarchici, autorizzazioni per le azioni e livelli di accesso alla visualizzazione. La validazione deve distinguere ciò che un utente può fare dai contenuti che può vedere.
| Prova ACL | Pass | Watch | Block |
|---|---|---|---|
| Identità utente | Stato dell’account, nome utente o email, campi profilo e ID esterno richiesto sono corretti. | Resta una piccola pulizia del profilo. | Gli utenti necessari non possono accedere o risultano duplicati in modo errato. |
| Appartenenza ai gruppi | Gli utenti rappresentativi appartengono ai gruppi previsti e la gerarchia ereditata è compresa. | Resta una pulizia non critica dei gruppi. | Un utente riceve autorizzazioni ereditate errate. |
| Autorizzazione del componente | Gli utenti possono creare, modificare, pubblicare, eliminare, configurare o amministrare soltanto come previsto. | Resta un adeguamento non bloccante delle autorizzazioni documentato. | È possibile amministrare senza autorizzazione oppure il personale necessario non può operare. |
| Accesso alla visualizzazione | Articles, voci di menu, Categories, moduli e record dei componenti sono visibili soltanto ai gruppi approvati. | Resta una rifinitura della visibilità a bassa priorità. | Contenuti riservati vengono esposti oppure contenuti necessari risultano nascosti. |
| Profilo dell’estensione | Record e-commerce, membership, directory o di altri componenti restano collegati all’utente Joomla previsto. | Resta una pulizia facoltativa dei metadati storici. | L’identità applicativa o il diritto di accesso risulta scollegato. |
Utilizzare utenti che appartengono a gruppi sovrapposti e utenti che dipendono dall’appartenenza ereditata. Un’etichetta di ruolo copiata non dimostra autorizzazioni equivalenti. Le prove devono mostrare le azioni e la visibilità effettivamente disponibili per l’utente.
Registrare sia prove positive sia negative. Un utente che deve poter modificare un Article deve riuscirci, mentre un utente simile esterno al gruppo autorizzato deve essere respinto. Ripetere lo stesso schema per la visualizzazione sul sito pubblico. Questa verifica a coppie è più affidabile della sola ispezione delle assegnazioni ai gruppi, perché autorizzazioni ereditate e mappature dei livelli di accesso possono produrre risultati imprevisti.
Validare contenuti multilingua e associazioni
I siti Joomla multilingua richiedono prove sensibili alla lingua su contenuti, Categories, menu, moduli, voci home, alias e associazioni. Un Article tradotto può esistere mentre il selettore di lingua, la voce di menu associata o la home specifica per lingua conducono altrove.
| Prova multilingua | Prova richiesta |
|---|---|
| Assegnazione linguistica | Ogni record prioritario utilizza la lingua prevista o l’ambito approvato per tutte le lingue. |
| Associazioni di Articles e Categories | I record equivalenti nelle diverse lingue sono collegati correttamente. |
| Struttura dei menu | Ogni lingua espone l’albero di menu e la voce home predefinita previsti. |
| Assegnazione dei moduli | I moduli specifici per lingua compaiono soltanto nel contesto previsto. |
| Alias e route | I percorsi per lingua non entrano in conflitto e i collegamenti raggiungono la traduzione corretta. |
| Accesso e metadati | Accessi, titoli, descrizioni e intento canonical specifici per lingua restano coerenti. |
Un set linguistico deve essere testato come un percorso completo del visitatore, non come una raccolta di record tradotti isolati. Includere homepage, navigazione, Article o percorso del componente prioritario, cambio lingua e percorso di ritorno. Un’associazione mancante può essere Watch per contenuti di basso valore, ma diventa Block quando interrompe un percorso Customer, legale o e-commerce necessario.
Le prove devono includere record con traduzioni mancanti e record intenzionalmente assegnati a tutte le lingue. Questi casi non devono essere trattati allo stesso modo. Un Article di basso valore non tradotto può essere Watch, mentre una traduzione legale, di account o e-commerce mancante può bloccare il lancio della lingua interessata. Documentare fallback o esclusione previsti anziché presumere che la lingua predefinita sia accettabile.
Validare moduli, template, override e composizione della pagina
Una pagina Joomla può combinare una vista di componente con più moduli assegnati in base a posizione, voce di menu, lingua, livello di accesso e stato di pubblicazione. Stili di template e override di layout possono modificare il modo in cui viene renderizzato lo stesso contenuto. La validazione deve distinguere quali parti provengono da record migrati e quali appartengono all’implementazione dello store di destinazione.
| Prova sulla composizione della pagina | Pass | Watch | Block |
|---|---|---|---|
| Output del componente | La vista principale di Article, Category o estensione mostra i record previsti. | Resta una piccola rifinitura del layout. | La pagina mostra il componente o il contesto record sbagliati. |
| Assegnazione del modulo | I moduli necessari compaiono nella posizione, nel menu, nella lingua e nel contesto di accesso corretti. | Resta una pulizia non critica del posizionamento. | Manca un modulo necessario per navigazione, login, aspetti legali o e-commerce. |
| Stile di template | Lo stile previsto si applica alla voce di menu o all’area del sito pertinente. | Resta la rifinitura visiva. | La pagina diventa inutilizzabile o nasconde contenuti critici. |
| Override | Il risultato sulla destinazione supporta dati e azioni richiesti. | È in attesa una sostituzione documentata. | Una vista critica perde campi o interazioni perché il vecchio override non si applica più. |
| Page builder | I contenuti inclusi sono modificabili e producono un risultato pubblico approvato. | Resta un adeguamento manuale. | Una pagina prioritaria è vuota, non funziona o resta intrappolata in dati di estensione inutilizzabili. |
La validazione non deve promettere la ricostruzione completa del template salvo quando rientra nell’ambito. Deve dimostrare che le pagine prioritarie hanno un risultato approvato e utilizzabile e che i difetti della migrazione sono separati dalle attività di implementazione sulla destinazione.
Utilizzare pagine prioritarie con voci di menu, livelli di accesso, lingue e stili di template differenti. Un modulo può risultare pubblicato e non funzionare comunque perché assegnazione al menu, posizione, lingua o regola di accesso sono errate. Quando un override non viene mantenuto, le prove devono mostrare il rendering approvato sulla destinazione e confermare che campi e azioni richiesti restino disponibili.
Validare separatamente record delle estensioni e record e-commerce
Le estensioni Joomla possono gestire Products, Customers, Orders, abbonamenti, prenotazioni, form, eventi, directory, membership, download, dati dei builder di pagine e riferimenti a sistemi esterni. Questi record possono utilizzare utenti core, Categories, tag, campi o voci di menu continuando però a mantenere proprie tabelle e regole.
| Area dell’estensione | Prove richieste | Indicazione per la decisione di lancio |
|---|---|---|
| Componente e-commerce | Struttura Product, Categories, opzioni, prezzi, inventario, Customers, Orders, route e campi dell’estensione | Block quando un Product prioritario o un Order storico non può essere interpretato correttamente. |
| Estensione membership o accessi | Relazione utente, piano, stato, date, contenuti protetti e storico pagamenti quando incluso | Block quando un diritto di accesso attivo è errato. |
| Componente form | Definizione del form, campi, invii quando inclusi, routing e notifiche | Block quando un form necessario o lo storico concordato è inutilizzabile. |
| Componente eventi, prenotazioni o directory | Record core, responsabilità, date, luoghi, partecipanti e vista pubblica | Block quando un obbligo attivo o un percorso di scoperta è errato. |
| Page builder | Record di pagina, blocchi, media e contesto di modifica | Watch o Block in base all’importanza della pagina e al risultato approvato. |
| Tabella personalizzata o integrazione | Chiave padre, ID esterno, trasformazione e sistema che utilizza il dato sulla destinazione | Block quando un flusso concordato non riesce a leggere il risultato. |
| Output di migrazione approvato | Risultato acquistato di mappatura, filtraggio o configurazione supportata | Confrontare con il requisito selezionato e il risultato Joomla atteso. |
| Output di migrazione non standard | Entità personalizzata, relazione, trasformazione o identificatore esterno approvato | Confrontare con le prove di accettazione concordate. |
I record e-commerce non devono essere validati come normali utenti o Articles Joomla. È il componente responsabile di Products, Customers e Orders a determinare le prove necessarie. Un utente Joomla può essere collegato a un Customer, ma il solo record utente non dimostra lo storico e-commerce o il funzionamento dell’account.
Quando i record generano obblighi attivi o accessi riservati, il responsabile dell’estensione deve partecipare alla decisione. Validare sia il record amministrativo sia il risultato pubblico o visibile all’utente. Un Product, una prenotazione, una membership o un invio di form che compare in una tabella ma non può essere trovato, modificato o riconciliato tramite il componente di destinazione non deve ricevere Pass.
Validare l’esecuzione più ampia della migrazione e le azioni successive
L’esecuzione più ampia deve dimostrare copertura completa di contenuti, stati, lingue, accessi, menu, estensioni ed eccezioni. Riconciliare i totali per tipo di contenuto, Category, lingua, stato, livello di accesso, gruppo utenti, menu ed entità di estensione incluse. Esaminare esclusioni deliberate, difetti della sorgente, alias duplicati, media orfani, associazioni interrotte e record che richiedono un’implementazione separata.
Le attività successive richiedono una revalidazione specifica per l’azione:
| Azione successiva | Prove Joomla da ripetere |
|---|---|
| continuare con la configurazione accettata | Confermare che nuovi Articles, utenti, media e record delle estensioni mantengano le stesse Categories, lingue, accessi, route e relazioni tra campi. Ricontrollare collisioni con modifiche dello store di destinazione e nuovi alias. |
| continuare con una configurazione modificata | Revalidare ogni selezione modificata dei tipi di dati, mappatura di Category o campo, regola utenti, regola linguistica, decisione sulle estensioni, regola di routing e filtro. |
| produrre un nuovo risultato di migrazione distinto | Trattare il risultato come indipendente. Ripetere le prove su contenuti, ACL, multilingua, composizione delle pagine, estensioni e decisione di lancio. |
La revisione del volume completo deve confrontare anche la distribuzione dei record, non soltanto i totali. Conteggi per lingua, livello di accesso, Category, stato, gruppo utenti e tipo di estensione possono rivelare classificazioni errate che un unico conteggio complessivo nasconde. I registri delle eccezioni devono indicare se una differenza è intenzionale, un difetto della sorgente, una decisione di ristrutturazione della destinazione o un problema di migrazione ancora irrisolto.
Creare il registro decisionale per il lancio di Joomla
Il registro finale delle prove deve identificare:
- Article, Category, voce di menu, gruppo utenti, livello di accesso, lingua, modulo, stile di template, componente o route testati;
- identificatori di Source Platform e destinazione utilizzati per la riconciliazione;
- risultato previsto e prova osservata;
- decisione Pass, Watch o Block;
- responsabile della correzione o dell’attività di implementazione sulla destinazione;
- se il problema incide sul lancio, su successive attività di migrazione o su una pulizia non bloccante;
- prova necessaria per chiudere il rilievo.
Un Pass richiede contenuti prioritari utilizzabili, route corrette, accessi controllati, percorsi linguistici coerenti, composizione delle pagine approvata e responsabilità esplicite per i record delle estensioni. Un elemento Watch ha un responsabile identificato e non compromette questi risultati. Un Block rimane quando contenuti importanti non sono accessibili, dati riservati vengono esposti, un percorso linguistico non funziona, una pagina critica non può essere composta o un risultato concordato dell’estensione è inutilizzabile.
Conclusione
La validazione di Joomla deve dimostrare le relazioni tra Articles, Categories, menu, alias, route, utenti, gruppi, autorizzazioni, livelli di accesso, lingue, moduli, template e record delle estensioni. La sola presenza dei record non dimostra che il sito funzioni nel contesto di pagina, pubblico, lingua o componente previsto.
I test rappresentativi dimostrano il modello delle relazioni. L’esecuzione più ampia della migrazione dimostra completezza dell’ambito e gestione delle eccezioni. Le azioni successive richiedono una revalidazione mirata o completa in base all’azione selezionata. L’approvazione del lancio dipende da prove riproducibili e decisioni Pass, Watch o Block esplicite.
Domande frequenti
Perché Categories e menu Joomla devono essere validati separatamente?
Le Categories organizzano i contenuti, mentre le voci di menu definiscono route pubbliche, layout, gerarchia, accesso, lingua e contesto del template. Uno dei due può essere corretto mentre l’altro conduce i visitatori al risultato sbagliato.
Come deve essere validato il controllo degli accessi Joomla?
Utilizzare utenti rappresentativi di ogni gruppo rilevante e verificare sia le azioni consentite sia l’accesso alla visualizzazione. I nomi dei gruppi da soli non dimostrano autorizzazioni ereditate o livelli di accesso associati ad Articles, menu, moduli e record dei componenti.
Cosa rende completa la validazione multilingua in Joomla?
Validare assegnazioni linguistiche, Articles e Categories associati, menu e voci home specifici per lingua, moduli, alias, metadati e un percorso completo del visitatore attraverso il selettore di lingua.
I record delle estensioni devono essere controllati come Articles o utenti Joomla?
No. Devono essere validati attraverso il componente che gestisce campi, relazioni, route e flussi di lavoro. Articles e utenti core possono partecipare alla relazione, ma non sostituiscono l’entità dell’estensione.
Come devono influire le differenze di template o builder di pagine sulle decisioni di lancio?
Classificare se il problema riguarda contenuti migrati, implementazione sulla destinazione o un risultato personalizzato concordato. Utilizzare Watch per attività non bloccanti con un responsabile identificato e Block quando una pagina prioritaria è inutilizzabile o non può essere mantenuta.
Cosa deve essere revalidato dopo una successiva attività di migrazione Joomla?
Ricontrollare Articles, Categories, menu, alias, utenti, accessi, lingue, media, record delle estensioni, redirect e conflitti con modifiche nello store di destinazione. Una nuova configurazione o una nuova migrazione richiedono prove più ampie rispetto alla continuazione con una configurazione invariata.