Joomla non rappresenta un sito web come un’unica raccolta di pagine e non offre uno schema e-commerce universale. Il suo modello dati separa record di contenuto, alberi di Categories, route di menu, moduli, assegnazioni dei template, utenti, controlli di accesso, lingue, media, campi personalizzati ed entità di proprietà delle estensioni. Una pagina apparentemente semplice nel browser può quindi dipendere da più record, ciascuno con un responsabile diverso.
Quando Joomla è la piattaforma di destinazione, la pianificazione della migrazione deve ricostruire le relazioni, non limitarsi a copiare campi di testo. Un Article può contenere il contenuto principale, mentre una voce di menu determina la route pubblica, una Category fornisce il contesto organizzativo, un livello di accesso controlla la visibilità, un modulo aggiunge contenuti di supporto e un’estensione gestisce il processo aziendale alla base della pagina. Conservare soltanto il contenuto visibile può lasciare sulla destinazione record esistenti ma privi dello stesso significato in termini di navigazione, autorizzazioni, lingua o applicazione.
Joomla separa contenuti, routing, presentazione e dati applicativi
Joomla core offre strutture riutilizzabili, ma ognuna ha una responsabilità distinta. Articles e altri record dei componenti contengono i contenuti. Le Categories raggruppano i record all’interno del componente che li gestisce. I menu creano navigazione ordinata e relazioni di routing. I moduli collocano output riutilizzabili intorno a una pagina. Template e override determinano la presentazione. Utenti, gruppi e livelli di accesso controllano identità e visibilità. Componenti, plugin e codice personalizzato aggiungono record specifici dell’applicazione.
| Livello Joomla | Significato principale | Conseguenza per la rappresentazione sulla destinazione |
|---|---|---|
| Articles e record dei componenti | Contenuti modificabili o record gestiti da un’applicazione | La destinazione deve identificare il vero responsabile del record invece di trattare ogni pagina visibile come un Article. |
| Categories | Raggruppamento gerarchico all’interno di uno specifico componente | Una Category di contenuto e una Category e-commerce possono avere etichette simili pur appartenendo a insiemi di dati differenti. |
| Menu e voci di menu | Navigazione, route, alias, lingua, accesso e contesto della pagina | URL pubblici e punti di ingresso possono dipendere dalle relazioni delle voci di menu, non soltanto dai titoli degli Articles. |
| Moduli | Blocchi riutilizzabili assegnati a posizioni e pagine | I contenuti di supporto possono richiedere un proprio record sulla destinazione e una relazione di posizionamento. |
| Template e override | Layout e output renderizzato | Sono elementi di presentazione, non sostituti dei contenuti migrati o dei dati applicativi. |
| Utenti, gruppi e livelli di accesso | Identità, autorizzazioni e visibilità | Un account Joomla non può essere interpretato automaticamente come un Customer e-commerce o un segmento aziendale. |
| Componenti, plugin e tabelle personalizzate | Funzioni e record specifici di un dominio | E-commerce, membership, moduli, directory, download e integrazioni richiedono un’interpretazione specifica del relativo responsabile. |
Questo modello a livelli è una delle differenze fondamentali di Joomla in una migrazione. Lo stesso campo di origine può diventare contenuto core, parametro di una voce di menu, campo personalizzato, record di un componente, relazione con un utente o requisito di implementazione sulla destinazione, a seconda della funzione che svolge.
Articles, Categories e voci di menu mantengono relazioni differenti
Un Article è un record di contenuto. Una Category raggruppa record appartenenti allo stesso componente Joomla. Una voce di menu è un record di navigazione e routing che può puntare a un Article, a una vista Category, a un componente di terze parti, a un collegamento di sistema o a un’altra destinazione. Questi oggetti possono contribuire alla stessa pagina pubblica, ma non sono intercambiabili.
Le Categories Joomla sono legate al componente. L’albero delle Categories utilizzato dai contenuti core è separato dalle partizioni di Categories usate da altri componenti che supportano le Categories Joomla. Questo è importante quando la Source Platform utilizza una tassonomia universale. Una «Category» di origine potrebbe dover diventare una Category dei contenuti Joomla, una Category dell’estensione e-commerce, un tag, un ramo di menu oppure più record coordinati.
Le voci di menu contengono dati strutturali che i record di contenuto non possiedono. Gli alias possono formare i percorsi URL; le relazioni padre-figlio creano alberi di menu; lingua e accesso determinano la disponibilità; i riferimenti ai componenti identificano la vista aperta; le assegnazioni degli stili di template possono modificare la presentazione per una route specifica.
| Concetto di origine | Possibile rappresentazione in Joomla | Significato che deve restare esplicito |
|---|---|---|
| Pagina editoriale | Article più una o più voci di menu | L’Article contiene il contenuto; la voce di menu gestisce il punto di ingresso navigabile e il contesto della route. |
| Landing page di una Product Category | Category e-commerce più voce di menu Joomla | Raggruppamento commerciale e navigazione pubblica restano relazioni separate. |
| Sezione di una raccolta di risorse | Category, Articles con tag, voce di menu e moduli | Classificazione, contenuti, route e visualizzazioni di supporto possono avere responsabili differenti. |
| Alias URL diretto | Alias della voce di menu, output del router del componente o record di redirect | Il percorso pubblico non può essere dedotto in modo affidabile soltanto dal titolo. |
| Landing page nascosta | Record pubblicato senza voce di menu visibile oppure voce di menu nascosta | La visibilità nella navigazione non equivale allo stato di pubblicazione o alla disponibilità dell’URL. |
Il modello della destinazione deve quindi mantenere sia l’identità del record sia l’identità della route. Fondere troppo presto questi due aspetti può interrompere alias, percorsi gerarchici, punti di ingresso specifici per lingua, breadcrumb, regole di accesso o collegamenti provenienti da altri contenuti.
Moduli, template e override non sono il corpo della pagina
Joomla compone le pagine utilizzando più del solo output del componente principale. I moduli possono fornire navigazione, banner, form, ricerca, accesso all’account, selettore di lingua, contenuti correlati, HTML personalizzato o blocchi specifici di un’estensione. Il loro significato dipende dal tipo di modulo, dalla posizione, dallo stato di pubblicazione, dalla lingua, dall’accesso e dall’assegnazione alle voci di menu.
Una Source Platform può memorizzare tutti i contenuti di una pagina in un unico record di layout, mentre Joomla distribuisce il risultato tra un Article o una vista del componente e diversi moduli. Può verificarsi anche il contrario: una pagina Joomla composta da più moduli può dover diventare una singola pagina strutturata su un’altra piattaforma di destinazione. Il modello di migrazione deve decidere se un modulo resterà un blocco riutilizzabile, diventerà contenuto incorporato, sarà associato a un widget della destinazione oppure resterà parte di un’attività separata di implementazione grafica.
Template e override di layout costituiscono un altro confine di responsabilità. Uno stile di template può essere assegnato tramite le voci di menu e un override può modificare il modo in cui un componente o un modulo viene renderizzato senza cambiare il record sottostante. I dati di Product, Article, Customer o Order possono continuare a essere migrabili anche quando il vecchio output non può essere riprodotto come dato.
| Oggetto di presentazione Joomla | Cosa gestisce | Cosa non gestisce |
|---|---|---|
| Modulo | Record di visualizzazione riutilizzabile e relativo contesto di assegnazione | Il record aziendale principale renderizzato da un componente |
| Posizione del modulo | Identificatore di collocazione previsto da un template | Il contenuto memorizzato nel modulo |
| Stile di template | Configurazione visiva e di layout per route selezionate | Significato di Article, Product, Customer o Order |
| Override del layout | Regola di rendering modificata | Un record portabile sulla destinazione per impostazione predefinita |
| Modulo HTML personalizzato | Contenuto riutilizzabile esterno a un Article | La route completa della pagina o il funzionamento dell’applicazione |
Mantenere espliciti questi confini impedisce di scambiare elementi di presentazione per contenuti mancanti e di nascondere record aziendali all’interno di una discussione sulla ricostruzione grafica.
Utenti Joomla, gruppi, livelli di accesso e Customers sono concetti separati
Un utente Joomla è principalmente un’identità che può accedere al sito o all’interfaccia amministrativa. L’account può contenere nome utente, email, stato, preferenze, appartenenza ai gruppi e contesto delle autorizzazioni. Il sistema ACL di Joomla separa poi ciò che un utente può visualizzare da ciò che può fare.
Questo modello non coincide con quello di un Customer e-commerce. Un’estensione e-commerce può collegare i propri record Customer, indirizzi, gruppi di acquirenti, abbonamenti, membership o Orders a un ID utente Joomla, ma tali record restano di proprietà dell’estensione. Un utente Joomla registrato potrebbe non aver mai effettuato un acquisto, mentre un Order guest può contenere i dati dell’acquirente senza un account Joomla permanente.
| Record relativo all’identità | Significato in Joomla | Incompatibilità comune con il modello di origine |
|---|---|---|
| Utente | Identità di accesso e attributi dell’account core | Viene trattato come profilo Customer completo anche se i dati e-commerce risiedono altrove. |
| Gruppo utenti | Raggruppamento di autorizzazioni utilizzato dall’ACL Joomla | Viene scambiato per segmento marketing, gruppo di prezzo o azienda B2B. |
| Livello di accesso alla visualizzazione | Definisce quali gruppi possono visualizzare un elemento | Viene ridotto a un semplice flag pubblico/privato perdendo regole di visibilità a più livelli. |
| Autorizzazioni amministrative | Azioni che un utente può eseguire in un componente | Vengono confuse con lo stato dell’account sulla vetrina online. |
| Customer dell’estensione | Record di acquirente o membro collegato, quando previsto, a un utente Joomla | Viene perso se si interpretano soltanto le tabelle core degli utenti. |
| Acquirente guest | Dati storici dell’acquirente memorizzati con un Order | Viene forzato erroneamente in un account utente Joomla permanente. |
La relazione sulla destinazione deve preservare la distinzione tra identità, autorizzazione, profilo acquirente, indirizzo, organizzazione e proprietà delle transazioni storiche. Fondere questi concetti può esporre contenuti riservati, rimuovere accessi legittimi, duplicare Customers o separare gli Orders dalla corretta identità storica.
Campi personalizzati, tag, media e metadati aggiungono significato strutturato
I campi personalizzati di Joomla possono associare valori strutturati a tipi di record supportati, come Articles, utenti o contatti. Il loro ruolo aziendale varia molto: etichette editoriali, specifiche tecniche, dati di directory, identificatori esterni, attributi dei membri, chiavi di integrazione o contenuti strutturati della pagina. L’etichetta del campo, da sola, non determina la rappresentazione sulla destinazione.
I tag forniscono una classificazione flessibile trasversale alle Categories. I media e i percorsi dei file possono supportare immagini incorporate, gallerie, download, documenti o risorse di estensioni. I metadati possono risiedere in Articles, Categories, voci di menu o record delle estensioni e possono influenzare snippet di ricerca, condivisione, indicizzazione e decisioni di routing.
| Area dati | Domanda sulla relazione | Interpretazione sulla destinazione |
|---|---|---|
| Campo personalizzato | Quale componente e quale tipo di record gestiscono il valore? | Associarlo a un campo nativo della destinazione, a un elemento di contenuto strutturato, a un campo dell’estensione o a una relazione con dati esterni. |
| Tag | Serve per navigazione, filtri, contenuti correlati o annotazione editoriale? | Mantenere la relazione aziendale che il tag svolge realmente. |
| Elemento multimediale | Quali record riutilizzano la risorsa e il percorso è incorporato nel contenuto? | Mantenere relazioni di collegamento e riutilizzo anziché copiare file senza riferimenti. |
| Metadati | Il valore appartiene al contenuto, alla route, alla Category o al componente? | Associarlo all’oggetto della destinazione che controlla l’output pubblico equivalente. |
| Identificatore esterno | Quale sistema utilizza il valore come chiave? | Mantenere stabile l’identificatore e collegarlo all’entità corretta sulla destinazione. |
Una mappatura a livello di campo che ignora la responsabilità del componente può collocare un valore valido sull’oggetto sbagliato. La destinazione potrebbe visualizzarlo e allo stesso tempo perdere filtri, integrazioni, accessi o comportamento di modifica.
I dati multilingua dipendono da lingue, associazioni, route e supporto delle estensioni
Joomla distingue la traduzione dell’interfaccia dalla lingua dei contenuti. I record di contenuto possono avere un’assegnazione linguistica, mentre le associazioni multilingua collegano record equivalenti tra lingue differenti. Anche strutture di menu, pagine predefinite, alias, moduli, Categories e record delle estensioni possono variare per lingua.
Una Source Platform che memorizza le traduzioni come colonne di un unico record potrebbe richiedere più record Joomla associati. Un’altra piattaforma di origine potrebbe già utilizzare record separati ma non avere associazioni equivalenti a quelle di Joomla. Le estensioni possono implementare campi multilingua tramite il supporto linguistico core, proprie tabelle o sistemi di traduzione di terze parti.
| Elemento multilingua | Significato nel modello dati |
|---|---|
| Lingua del contenuto | Identifica la lingua assegnata a un contenuto o a un record di componente. |
| Associazione linguistica | Collega record equivalenti senza trasformarli in un unico record. |
| Voce di menu specifica per lingua | Fornisce route e contesto di navigazione per una lingua. |
| Modulo specifico per lingua | Fornisce contenuti di supporto alle route della lingua selezionata. |
| Record di traduzione dell’estensione | Contiene dati e-commerce o applicativi tradotti secondo il modello dell’estensione. |
| Override di lingua | Modifica testi dell’interfaccia anziché rappresentare contenuti aziendali da migrare. |
Il modello della destinazione deve distinguere i contenuti aziendali tradotti dalle stringhe dell’interfaccia e dalle relazioni di routing. Mantenere il testo senza associazioni può creare pagine apparentemente duplicate ma non collegate come equivalenti linguistiche. Mantenere le associazioni senza il relativo contesto di menu e moduli può lasciare incompleto un ramo linguistico.
Le estensioni definiscono i confini dell’e-commerce e delle altre applicazioni
Joomla core non definisce Products, carrelli, Customers, Orders, abbonamenti, eventi, directory o record di marketplace nativi. Queste entità appartengono ai componenti installati o ad applicazioni personalizzate. Due siti Joomla possono quindi mostrare vetrine online simili memorizzando i dati e-commerce in tabelle e relazioni completamente differenti.
L’estensione proprietaria determina tipi di Product, struttura delle Categories, funzionamento di opzioni o varianti, prezzi, stock, collegamenti ai Customers, righe Order, storico degli stati, riferimenti di pagamento, riferimenti di spedizione, campi personalizzati e identificatori di integrazione. Plugin e moduli possono aggiungere ulteriori record o modificarne l’interpretazione.
| Concetto e-commerce | Posizione in Joomla core | Responsabile effettivo dei dati |
|---|---|---|
| Product e scelta acquistabile | Nessuno schema Product core universale | Componente e-commerce e relative estensioni |
| Customer e indirizzo | L’utente core può fornire soltanto l’identità | Componente e-commerce, componente membership o applicazione personalizzata |
| Order e riga Order | Nessuno schema Order core universale | Componente e-commerce o sistema Orders esterno |
| Gruppo di prezzo o regola B2B | Non equivale automaticamente ai gruppi utenti Joomla | Estensione e-commerce, plugin prezzi o sistema esterno |
| Campo di checkout | Non è per impostazione predefinita un campo utente core | Componente e-commerce, plugin form o tabella personalizzata |
| Riferimento di pagamento e spedizione | Contesto storico conservato dal responsabile e-commerce | Componente e-commerce più plugin del gateway o del corriere |
Per questo motivo, «dati Joomla» non è una definizione sufficiente dell’ambito. L’inventario della migrazione deve identificare componenti, plugin, moduli, tabelle personalizzate e sistemi esterni che gestiscono record importanti per l’attività.
Implementazioni personalizzate e identificatori esterni richiedono una mappa delle responsabilità
I siti Joomla utilizzati da molti anni spesso contengono componenti personalizzati, tabelle di estensioni modificate, override dei template, plugin basati su eventi, attività pianificate, integrazioni API e relazioni dirette nel database. Alcuni valori personalizzati riguardano soltanto la presentazione; altri sono chiavi aziendali autorevoli.
La mappa delle responsabilità più utile identifica il record, la tabella o API che lo gestisce, l’entità padre, il sistema esterno che lo utilizza e l’oggetto di destinazione che deve ricevere il valore. Questo è particolarmente importante per ID ERP, ID CRM, riferimenti documentali, stati membership, ID venditore marketplace, chiavi per l’evasione degli ordini e timestamp di sincronizzazione.
| Segnale di responsabilità | Perché modifica la rappresentazione |
|---|---|
| Tabella personalizzata con chiavi esterne verso utenti o Articles core | Il record aziendale può scomparire se si interpretano soltanto le tabelle core di Joomla. |
| Campo o record evento creato da un plugin | Il valore può dipendere dal funzionamento del plugin anziché da un campo nativo della destinazione. |
| Identificatore riutilizzato da un sistema esterno | Rigenerare gli ID può interrompere riconciliazione o sincronizzazione. |
| Override che legge colonne non standard | La pagina visibile può dipendere da dati non esposti nelle normali interfacce del componente. |
| Più estensioni utilizzano lo stesso utente | L’identità deve restare condivisa mentre i profili gestiti da ciascuna estensione restano distinti. |
La destinazione non deve riprodurre ogni dettaglio dell’implementazione Joomla. Deve però prevedere una rappresentazione deliberata per ogni relazione che trasporta un significato aziendale, di accesso, contenuto o integrazione.
Conclusione
La migrazione di Joomla consiste essenzialmente nel rappresentare correttamente più livelli collegati. Articles, Categories, voci di menu, moduli, template, utenti, livelli di accesso, lingue, campi personalizzati, media, estensioni e sistemi esterni gestiscono parti diverse del significato del sito.
Un modello di destinazione coerente mantiene questi confini di responsabilità prima di decidere come rappresentare i record. In questo modo i contenuti restano collegati alle route, le identità alle autorizzazioni, le traduzioni alla struttura linguistica, i record e-commerce all’estensione che li gestisce e gli identificatori esterni ai sistemi che ne dipendono.
Domande frequenti
Joomla offre un modello nativo per Products e Orders?
No. Joomla core fornisce contenuti, identità, accessi, routing e infrastruttura per le estensioni, ma Products e Orders appartengono a un componente e-commerce o a un’applicazione personalizzata. Il loro significato ai fini della migrazione deve essere ricavato dallo schema del relativo responsabile.
Le Categories Joomla sono uguali alle voci di menu?
No. Le Categories raggruppano i record all’interno di un componente, mentre le voci di menu creano relazioni di navigazione e routing. Una pagina pubblica di Category può dipendere da entrambi gli oggetti, ma nel modello di destinazione devono restare separati.
Ogni utente Joomla può essere migrato come Customer?
No. Un utente Joomla è un’identità di accesso e un soggetto a cui si applicano autorizzazioni. Customers, indirizzi, membership e Orders e-commerce possono essere record separati di proprietà delle estensioni collegati a tale identità, mentre gli acquirenti guest possono non avere alcun account utente Joomla.
Come devono essere rappresentati moduli e override dei template?
I moduli devono essere classificati in base ai contenuti riutilizzabili e alle relazioni di assegnazione. Template e override appartengono normalmente all’implementazione della presentazione più che alla migrazione dei record aziendali, anche se i contenuti memorizzati nei moduli personalizzati devono comunque essere inventariati.
Perché i dati Joomla multilingua sono particolarmente sensibili alle relazioni?
Assegnazioni linguistiche, record associati, voci di menu specifiche per lingua, moduli, alias e traduzioni delle estensioni possono contribuire tutti a un’unica esperienza linguistica. Il solo testo tradotto non preserva queste relazioni.
Quando i dati personalizzati di Joomla richiedono una progettazione separata sulla destinazione?
Serve una progettazione separata quando valori importanti risiedono in tabelle personalizzate, campi delle estensioni, record dei plugin, override o integrazioni esterne che non corrispondono a un’entità standard della destinazione. La progettazione deve preservare significato aziendale e responsabilità del dato, senza copiare alla cieca il modello di memorizzazione della Source Platform.