VirtueMart memorizza i record commerciali all’interno di un ambiente Joomla, ma non utilizza lo stesso modello basato su articoli come Products adottato da J2Store o J2Commerce. Products, Product Categories, Manufacturers, prezzi, stock, custom field, shopper group, regole di calcolo, Orders, metodi di spedizione e metodi di pagamento appartengono a VirtueMart. Joomla fornisce invece identità utente, menu, moduli, template, framework linguistico, routing, regole di accesso e ambiente delle estensioni che circondano quei record.
Questa divisione dell’ownership rende la migrazione un problema di traduzione delle relazioni. Una variante sorgente può diventare un child Product, un custom field o un’altra relazione strutturata. Un segmento Customer può diventare uno shopper group che influenza prezzi e disponibilità dei metodi. Un valore fiscale o di sconto può essere evidenza all’interno di un vecchio Order oppure una regola di calcolo attiva per i carrelli futuri. La destinazione corretta dipende dal ruolo commerciale del dato sorgente.
Confini di ownership tra Joomla e VirtueMart
Un negozio VirtueMart nasce dall’unione di due modelli collegati. Il componente commerce possiede catalogo e record transazionali; Joomla possiede gran parte del contesto di sito e identità che rende quei record accessibili.
| Area di business | Owner principale nella destinazione | Relazione da preservare |
|---|---|---|
| Identità dei Products e campi catalogo | VirtueMart | Product verso Category, Manufacturer, media, prezzo, stock, custom field e Products correlati |
| Accesso utente | Utente Joomla | Utente verso shopper VirtueMart e record indirizzo |
| Segmentazione shopper | Shopper group VirtueMart, talvolta combinato con accessi Joomla | Shopper verso prezzo, visibilità, imposte, pagamento o comportamento di spedizione |
| Route della vetrina | Menu Joomla, router, alias, lingua e vista VirtueMart | Product o Category verso la destinazione preferita per l’acquirente |
| Visualizzazione dei Products | Layout VirtueMart più template e moduli Joomla | Identificatori dei record verso il corretto output della pagina |
| Pagamento e spedizione | Metodi e plugin VirtueMart | Regole attive dei metodi verso evidenze negli Orders e funzionamento del checkout |
Un Product può essere presente in VirtueMart anche quando route per l’acquirente, posizionamento del modulo o contesto linguistico sono assenti. Un utente Joomla può esistere mentre shopper group, indirizzo o cronologia Orders corrispondenti risultano scollegati. Entrambi i lati della relazione devono avere un owner esplicito.
Products, Categories, Manufacturers e media
I Products VirtueMart possono collegarsi a numerose strutture commerciali. Un Product sorgente può richiedere una o più Categories, un Manufacturer, immagini e file, campi stock, dimensioni, disponibilità, prezzi, imposte, shopper group, custom field, child Products, Products correlati, recensioni e contenuti tradotti.
| Significato nella sorgente | Domanda per la destinazione VirtueMart | Relazione necessaria |
|---|---|---|
| Classificazione del Product | In quali Categories VirtueMart dovrebbe rientrare il Product? | Assegnazioni Product-to-Category e gerarchia prevista |
| Identità del brand | È un record Manufacturer, una Category, un custom field o una chiave esterna? | Relazione Product-to-Manufacturer ed eventuale pagina del brand |
| Galleria e file | Quali media sono immagini, file scaricabili o asset di contenuto? | Ruolo media-to-Product, ordine e visibilità |
| Product correlato o accessorio | La relazione serve merchandising, compatibilità, sostituzione o logica bundle? | Relazione Product-to-Product con finalità definita |
| Stock e dimensioni | I valori appartengono al Product o al singolo child Product? | Ownership di inventario e attributi sensibili alla spedizione |
| Recensioni e valutazioni | Sono record nativi VirtueMart, contenuti Joomla o dati di estensione? | Relazione tra autore, Product, valutazione, testo e stato di pubblicazione |
La traduzione delle Categories non va confusa con la navigazione Joomla. Le Categories VirtueMart organizzano il catalogo commerciale; le voci di menu Joomla espongono determinate viste di Category o Product. Una gerarchia Category della sorgente può quindi migrare correttamente mentre la navigazione della destinazione utilizza una struttura di route diversa.
Anche i record Manufacturer richiedono revisione semantica. Un brand sorgente può servire solo come testo visualizzato oppure guidare filtri, pagine dedicate, esportazioni feed, regole di prezzo e chiavi di integrazione esterne. La destinazione dovrebbe preservare le funzioni ancora necessarie, non convertire automaticamente ogni etichetta brand in un unico oggetto target.
Child Products, custom field e significato delle varianti
I custom field VirtueMart possono descrivere Products, raccogliere input degli shopper, collegare record correlati, attivare comportamento di plugin o partecipare a strutture selezionabili dei Products. I child Products possono avere SKU, prezzo, stock, dimensioni, immagini o disponibilità propri. Poiché entrambi i meccanismi possono apparire come scelte nella vetrina, le “varianti” della sorgente non possono essere mappate in modo uniforme.
| Comportamento nella sorgente | Possibile rappresentazione in VirtueMart | Significato da preservare |
|---|---|---|
| Taglia o colore ha SKU e stock indipendenti | Relazione parent-child Product, spesso esposta tramite un campo selezionabile | Ogni scelta deve risolvere nell’inventario corretto e nella corretta identità della riga Order |
| La scelta cambia il prezzo ma condivide lo stock | Custom field del Product o relazione di prezzo configurata | La variazione di prezzo resta collegata alla scelta selezionata |
| Lo shopper inserisce testo o carica informazioni | Custom field per input dello shopper o record di estensione | Il valore inserito resta collegato alla corretta riga dell’Order |
| Specifica tecnica | Custom field descrittivo | Il valore resta leggibile e, quando rilevante, filtrabile |
| Product o Category correlati | Relazione tramite custom field di sistema | Il collegamento continua a puntare al record previsto |
| Configuratore basato su plugin | Custom field e tabelle dati posseduti dal plugin | Lo stato della configurazione ha un owner target supportato |
La decisione di mappatura dovrebbe dipendere da cinque domande: la scelta cambia SKU, stock, prezzo, immagine o evasione degli ordini? Se nessuno di questi elementi cambia, il valore può essere descrittivo invece che una variante. Se ne cambiano diversi, è più probabile che serva un child Product o una struttura posseduta da plugin piuttosto che un semplice campo di testo.
I custom field sono definizioni riutilizzabili che possono poi essere assegnate ai Products. Definizione, tipo, ordine, visibilità, ownership del plugin e valore specifico del Product sono relazioni separate. Copiare soltanto il valore mostrato può perdere la definizione che rende quel valore selezionabile o operativo.
Shopper group, prezzi e regole di calcolo
Gli shopper group VirtueMart possono influenzare visibilità del catalogo, prezzi dei Products, imposte, metodi di pagamento, metodi di spedizione e altre regole commerciali. Un gruppo Customer della sorgente non equivale quindi necessariamente a una semplice etichetta shopper group di VirtueMart.
Anche i prezzi possono dipendere dal contesto. Un Product può avere prezzi associati a intervalli di quantità, shopper group, valute o altre condizioni. Le regole di calcolo possono applicare imposte, sconti, margini o modifiche di prezzo e possono essere limitate per Product Category, Manufacturer, shopper group, paese, stato/provincia, valuta o data.
| Regola nella sorgente | Relazione VirtueMart | Conseguenza della traduzione |
|---|---|---|
| Listino wholesale | Shopper group più record di prezzo del Product | Appartenenza del Customer e idoneità al prezzo devono restare collegate |
| Acquirenti esenti da imposte | Shopper group, località dell’indirizzo e regole di calcolo | Identità, geografia e condizioni della regola devono essere allineate |
| Sconto per Category | Product Category più regola di calcolo | La regola dipende dall’appartenenza alla Category, non da un campo sconto copiato |
| Imposta regionale | Contesto paese/stato più regola di calcolo | L’indirizzo del Customer o dell’Order fornisce parte dell’input della regola |
| Promozione a tempo | Regola di calcolo o coupon con date | Periodo attivo e operazione aritmetica devono restare espliciti |
| Prezzo specifico per valuta | Relazione tra prezzo e valuta | Importo, valuta e contesto di visualizzazione non devono essere confusi |
Importi storici degli Orders e logica di calcolo attiva appartengono a livelli diversi. Un vecchio Order dovrebbe mantenere imposta, sconto, valuta e totale effettivamente registrati. Non ha bisogno che l’attuale motore di calcolo ricalcoli la cronologia. Il nuovo checkout, al contrario, dipende dalle regole attive nella destinazione.
Shopper, indirizzi, campi e Orders
VirtueMart collega comunemente un utente Joomla a un record shopper, agli shopper group e alle informazioni di indirizzo. Gli Orders guest possono esistere senza un account Joomla riutilizzabile. I campi shopper possono raccogliere informazioni di registrazione, fatturazione, spedizione, imposte, azienda o informazioni specifiche della transazione.
Il modello di destinazione dovrebbe assegnare ciascun campo in base al suo ciclo di vita:
- l’identità permanente di accesso appartiene all’utente Joomla;
- la segmentazione riutilizzabile dell’acquirente appartiene alle relazioni degli shopper group;
- le informazioni riutilizzabili di fatturazione o spedizione appartengono ai record shopper/indirizzo;
- i dettagli guest appartengono allo snapshot dell’Order;
- note di consegna una tantum o istruzioni d’acquisto appartengono all’Order;
- valori di membership o consenso posseduti da estensioni appartengono al sistema che li utilizza.
Gli Orders sono evidenze storiche. Possono includere snapshot dei Products, custom field selezionati, identità dei child Products, quantità, prezzi, imposte, sconti, coupon, contesto shopper group, indirizzi, etichette di pagamento e spedizione, stati, valuta, note e fatture.
| Evidenza nell’Order | Perché la relazione è importante |
|---|---|
| Product e child Product | Identifica l’articolo effettivamente venduto, non soltanto il parent Product |
| Selezione custom field | Spiega configurazione, personalizzazione o significato dell’opzione Product |
| Snapshot shopper e indirizzo | Preserva chi ha acquistato e dove l’Order è stato fatturato o spedito |
| Prezzo, imposta, sconto e valuta | Spiega il risultato finanziario storico |
| Metodo di pagamento e spedizione | Fornisce contesto per supporto ed evasione degli ordini |
| Stato e timestamp | Mostra la cronologia operativa dell’Order |
| Riferimento esterno | Collega record contabili, ERP, carrier o marketplace |
I plugin di pagamento e spedizione possono creare metadata aggiuntivi. L’etichetta storica e il riferimento del provider possono appartenere all’Order migrato, mentre la configurazione corrente del plugin appartiene all’ambiente target.
Vetrina, lingue, URL e presentazione Joomla
I record Product e Category di VirtueMart da soli non determinano il sito visto dall’acquirente. Menu Joomla, moduli, override del template, alias, assegnazioni linguistiche, livelli di accesso e routing modellano la vetrina finale.
Un URL sorgente può dipendere da slug dei Products, Categories annidate, prefissi lingua, alias di menu o un’estensione SEO. Le route VirtueMart possono dipendere sia dagli alias commerce sia dal contesto dei menu Joomla. La migrazione dovrebbe quindi identificare la destinazione canonical di ogni Product e Category ad alto valore e poi collegare i redirect a tale destinazione.
I dati multilingue possono includere record tradotti di Products e Categories, testo dei Manufacturers, etichette custom field, menu Joomla, moduli e metadata. Una relazione linguistica è completa solo quando i record commerce tradotti si risolvono nel corretto contesto Joomla di lingua e route.
| Livello della vetrina | Responsabilità nel modello dati |
|---|---|
| Alias VirtueMart di Product e Category | Identità lato commerce utilizzata dalle route |
| Voce di menu Joomla | Punto di ingresso e contesto route per una vista |
| Modulo | Query e posizionamento che mostra Products o Categories |
| Override del template | Logica di presentazione che si aspetta determinati campi o identificatori |
| Associazione linguistica | Collegamento tra contenuti, menu e record commerce tradotti |
| Metadata e destinazione canonical | Ownership della pagina rivolta ai motori di ricerca |
La logica di presentazione non dovrebbe essere inserita nei campi dei Products soltanto per riprodurre una pagina. Dovrebbe restare nel livello di presentazione Joomla e VirtueMart della destinazione, che utilizza i record tradotti attraverso relazioni stabili.
Dati di plugin, personalizzazioni e sistemi esterni
I negozi VirtueMart utilizzano spesso estensioni per pagamento, spedizione, custom field, abbonamenti, configuratori di Products, ricerca, feed, fatture, marketplace, contabilità ed evasione degli ordini. Queste estensioni possono creare tabelle e riferimenti che non fanno parte del modello ordinario di Products, shopper o Orders.
| Dipendenza | Dati che possono trovarsi fuori dai record core | Domanda per la destinazione |
|---|---|---|
| Plugin custom field | Valori del configuratore, file forniti dall’acquirente, relazioni child, logica di prezzo | Esiste un plugin equivalente o un record target strutturato? |
| Estensione abbonamenti o ricorrenze | Piani, cicli, rinnovi, riferimenti gateway, entitlement | Quale sistema possiede lo stato ricorrente dopo la migrazione? |
| Configuratore Product o estensione bundle | Products componenti, formule, configurazioni salvate | La destinazione può rappresentare la configurazione senza appiattirla? |
| Plugin di pagamento o spedizione | ID transazione, etichette, tracking, metadata del metodo | Quali valori sono evidenza storica e quali configurazione attiva? |
| Integrazione ERP o contabile | Chiavi Product, Customer, imposta, fattura e Order | Quali identificatori sono durevoli e autorevoli esternamente? |
| Override di template o modulo | Aspettative sui campi e regole di visualizzazione | Quali identificatori tradotti devono restare stabili per la presentazione? |
Le colonne personalizzate del database non si spiegano da sole. I loro nomi possono indicare come il dato è memorizzato, ma non il suo scopo commerciale. Ogni valore mantenuto deve avere un consumer nominato, un ciclo di vita e una relazione di destinazione.
Come le differenze di VirtueMart modificano l’ambito della migrazione
L’ambito VirtueMart dovrebbe essere espresso come trattamento delle relazioni:
| Trattamento | Esempi tipici VirtueMart | Conseguenza sull’ambito |
|---|---|---|
| Traduzione diretta dei record | Products, Categories, Manufacturers, shopper, Orders, media | Mappare campi standard e identificatori |
| Ricostruzione delle relazioni | Parent-child Products, assegnazioni custom field, shopper group, prezzi, condizioni delle regole di calcolo | Ricostruire collegamenti e input delle regole |
| Struttura di presentazione Joomla | Menu, moduli, route, contesto linguistico, override del template | Assegnare all’implementazione del sito target |
| Dati posseduti dai plugin | Configuratori, abbonamenti, campi checkout speciali, metadata dei metodi | Definire una destinazione supportata o un archivio separato |
| Continuità dei sistemi esterni | Identificatori ERP, contabilità, evasione degli ordini, feed o marketplace | Preservare chiavi durevoli e ownership |
| Ritiro intenzionale | Plugin obsoleti, custom field inutilizzati, route duplicate, regole abbandonate | Escludere con motivazione registrata |
Il modello dati è coerente quando un Product può essere seguito attraverso Categories, child Products, custom field, prezzi, stock, regole degli shopper group, righe degli Orders, route Joomla e identificatori esterni senza dipendere da presupposti tecnici non documentati.
Conclusione
Le differenze del modello dati di VirtueMart derivano dall’interazione tra record commerciali VirtueMart e strutture del sito Joomla. I Products possono dipendere da Categories, Manufacturers, media, child Products, custom field, shopper group, prezzi, regole di calcolo e plugin. I Customers possono attraversare utenti Joomla, record shopper, indirizzi e gruppi. Gli Orders preservano snapshot che devono rimanere comprensibili anche quando regole e plugin correnti sono diversi.
Una migrazione affidabile traduce esplicitamente queste relazioni. Separa l’evidenza storica degli Orders dal comportamento attivo di calcolo e checkout, mantiene il routing Joomla distinto dai record Product e assegna ai dati posseduti da plugin o sistemi esterni una destinazione chiara. In questo modo si preserva il significato commerciale invece di limitarsi a riprodurre righe di database.
Domande frequenti
Perché le varianti VirtueMart non possono essere tutte mappate in un unico tipo di opzione?
Alcune scelte sono child Products con SKU, stock, prezzo, immagine o dimensioni propri. Altre sono modificatori di prezzo, custom field descrittivi, input dello shopper o configurazioni possedute da plugin. La funzione commerciale determina la struttura target.
Qual è la differenza tra una definizione custom field e un valore del Product?
La definizione stabilisce tipo del campo, funzionamento, visibilità ed eventuale logica plugin. L’assegnazione al Product fornisce il valore o la selezione per uno specifico Product. Entrambe le relazioni possono essere necessarie affinché il comportamento della vetrina funzioni.
In che modo gli shopper group influenzano il modello dati?
Gli shopper group possono influenzare prezzi, visibilità, imposte, metodi di pagamento, metodi di spedizione e altre regole. Preservare soltanto il nome del gruppo senza membri e regole che lo utilizzano non preserva il significato commerciale.
Gli Orders storici dovrebbero essere ricalcolati con le regole fiscali e di sconto della destinazione?
No. Gli Orders storici dovrebbero mantenere importi ed etichette registrati al momento dell’acquisto. Le regole target attive governano i nuovi carrelli e devono restare separate dallo snapshot storico.
Perché i menu Joomla sono importanti se i Products sono memorizzati in VirtueMart?
I menu possono stabilire contesto della route e punti di ingresso della vetrina. Gli alias di Product e Category possono essere corretti mentre l’URL preferito per l’acquirente dipende ancora dalle relazioni tra menu Joomla e lingua.
Come dovrebbero essere tradotti i dati posseduti dai plugin?
Identifica i record creati dal plugin, le relazioni con Product, shopper o Order che utilizza e il sistema target che possiederà la stessa funzione commerciale. Preserva soltanto i valori con un utilizzo futuro definito.