J2Store incorpora l’e-commerce all’interno di Joomla invece di collocare ogni valore commerciale in un unico oggetto Product indipendente. Gli articoli Joomla possono fungere da Products, mentre Joomla Categories, alias, menu, utenti, livelli di accesso, media, moduli e template forniscono gran parte del contesto circostante di contenuto e storefront. J2Store aggiunge quindi prezzo, SKU, stock, tipo di Product, opzioni, relazioni Customer, checkout e Order che rendono vendibile l’articolo.
J2Store è oggi un progetto il cui sviluppo è stato interrotto e il cui repository è archiviato, mentre il successore attivo è J2Commerce. Questo fatto legato al ciclo di vita non elimina il modello dati dei negozi J2Store esistenti. Rende invece più importante interpretare correttamente la sorgente: vecchi record, app, plugin, override e tabelle personalizzate devono essere compresi come evidenza del funzionamento aziendale legacy, non come strutture che si presume coincidano con una destinazione attuale.
La relazione tra articolo e Product
La relazione che definisce J2Store è il collegamento tra un articolo Joomla e i relativi dati e-commerce. L’articolo fornisce l’identità di contenuto; J2Store fornisce l’identità commerciale. Una migrazione che li separa può produrre Products duplicati, record e-commerce orfani o pagine di articoli che non funzionano più come Products.
| Funzione aziendale | Livello Joomla | Livello J2Store |
|---|---|---|
| Titolo Product e contenuto esteso | Titolo dell’articolo, corpo, metadati, lingua, stato di pubblicazione | Il record e-commerce fa riferimento all’articolo vendibile |
| Raggruppamento dei contenuti | Joomla Category, tag, contesto di menu | Elenchi Product, filtri o logiche delle app possono usare il raggruppamento |
| Identità commerciale | Responsabilità CMS limitata | Tipo di Product, SKU, prezzo, imposte, stock, peso, dimensioni |
| Scelta dell’acquirente | Mostrata tramite articolo o output del template | Opzioni, varianti, campi personalizzati o record gestiti dalle app |
| Account dell’acquirente | Utente Joomla e gruppi di utenti | Customer, indirizzi, campi di checkout e Orders |
| URL dello storefront | Alias, Category, voce di menu, router, lingua | Lo stato del Product determina se i controlli di acquisto sono disponibili |
L’ID dell’articolo e la relazione con il Product J2Store devono essere trattati come un’unica identità logica durante la migrazione. Conservare entrambe le tabelle perdendo il collegamento non equivale a preservare il significato.
Tipi di Product, opzioni e record e-commerce specializzati
Le installazioni J2Store possono rappresentare modalità di vendita semplici, variabili, configurabili, scaricabili, virtuali, in abbonamento, prenotabili, con pagamento parziale e altri modelli specializzati. Alcuni dipendono dai tipi di Product core; altri da app o plugin. Le etichette visibili nello storefront non rivelano l’intera struttura sottostante.
Un Product sorgente deve essere scomposto in significati distinti prima della migrazione:
| Elemento sorgente | Possibile responsabile in J2Store | Domanda di rappresentazione |
|---|---|---|
| Nome, descrizione, media incorporati | Articolo Joomla | Quali contenuti appartengono alla pagina Product canonica? |
| SKU, prezzo, stock, peso | Product J2Store o record variante | Il valore è condiviso o specifico per una scelta dell’acquirente? |
| Taglia, colore, materiale, incisione | Opzione, variante, contenuto dell’articolo o record app | Cambia SKU, stock, prezzo, fulfillment oppure soltanto la presentazione? |
| File digitale | Product scaricabile o relazione gestita da un’app | Quale acquisto e quale stato Order autorizzano l’accesso? |
| Piano di abbonamento | Product, piano, rinnovo e record di accesso gestiti dall’app | Quali relazioni ricorrenti e di account devono continuare? |
| Slot di prenotazione | Pianificazione, risorsa, capacità e record di prenotazione gestiti dall’app | Quale record rappresenta il servizio vendibile e quale la prenotazione? |
| Deposito o rata | Piano di pagamento e record del saldo | Come sono collegati totale originario, importo pagato, importo residuo e stato? |
Un’opzione Product non va rappresentata soltanto in base al nome. Un valore “taglia” può essere una variante con stock proprio, un modificatore di prezzo, una dimensione descrittiva o un fattore di spedizione. La struttura sulla destinazione deve seguire la funzione aziendale effettiva.
I record specializzati richiedono particolare attenzione perché le estensioni J2Store possono archiviare i propri dati al di fuori delle normali tabelle Product e Order. Un Product in abbonamento senza i record del piano e del diritto di accesso diventa un normale Product acquistabile una sola volta. Un Product di prenotazione senza i dati delle prenotazioni diventa soltanto una pagina che descrive un servizio.
Categories, menu, moduli e route
La struttura del catalogo J2Store dipende fortemente da Joomla. Una Category sorgente può assumere diversi significati sulla destinazione: classificazione degli articoli, navigazione dell’acquirente, raggruppamento dinamico, input per filtri, confine di accesso o contesto di una landing page.
| Struttura sorgente | Relazione J2Store/Joomla | Significato da preservare |
|---|---|---|
| Product Category | Joomla Category assegnata agli articoli Product | Classificazione e navigazione basata sulle Categories |
| Collezione o reparto | Category, tag, query di modulo, voce di menu o regola di un’app | Logica di raggruppamento e percorso di scoperta |
| Brand o produttore | Campo Product, tag, Category, pagina di contenuto o estensione | Visualizzazione, filtro, route e identità esterna |
| Products in evidenza | Configurazione di modulo o query di un’app | Regola di selezione anziché una lista statica copiata |
| Catalogo con accesso limitato | Livello di accesso Joomla, gruppo di utenti o estensione | Quali utenti possono vedere o acquistare i Products |
| Landing page di campagna | Articolo Joomla, voce di menu, moduli e link Product | Composizione dei contenuti e route canonica |
Il contesto dei menu Joomla influisce sul routing. Lo stesso articolo può comparire attraverso percorsi di menu, percorsi Category o alias diversi. La migrazione deve identificare la destinazione Product preferita e distinguerla dalle route alternative da reindirizzare o ritirare.
Moduli e override dei template non sono record Product. Possono determinare quali Products compaiono, quali campi vengono mostrati e come vengono visualizzati opzioni o prezzi. La loro dipendenza dagli identificatori migrati deve essere documentata, ma la logica di presentazione resta una struttura separata sulla destinazione.
Customers, utenti Joomla e contesto dell’account
I dati Customer di J2Store possono estendersi su utenti Joomla, gruppi di utenti, record Customer, indirizzi, campi di checkout e Orders storici. Un indirizzo email Customer non è sufficiente per ricostruire la relazione con l’account.
Un Customer registrato può avere:
- un ID utente Joomla e uno stato di accesso;
- appartenenza a gruppi di utenti Joomla;
- uno o più indirizzi di fatturazione e spedizione;
- valori di profilo o fiscali riutilizzabili;
- campi personalizzati di registrazione o checkout;
- Orders collegati all’utente o all’email;
- record di membership, abbonamento, reward o accesso gestiti da app.
Un Order guest può contenere gli stessi dati di contatto e indirizzo senza alcun utente Joomla persistente. Creare un account registrato per ogni guest storico può modificare il significato dell’identità e produrre account duplicati o non accessibili.
| Valore Customer | Responsabilità appropriata | Motivo |
|---|---|---|
| Nome di accesso, email, stato abilitato | Utente Joomla | Controlla l’identità persistente per l’autenticazione |
| Ruolo del gruppo utenti | Relazione con il gruppo di utenti Joomla | Può controllare accesso, prezzi o comportamento delle estensioni |
| Indirizzo riutilizzabile | Record Customer/indirizzo J2Store | Appartiene al ciclo di vita del Customer |
| Snapshot di fatturazione e spedizione guest | Order storico | Appartiene a una singola transazione |
| Partita IVA o dati aziendali | Campo Customer, indirizzo o Order a seconda dell’uso | La responsabilità dipende dal fatto che il valore sia riutilizzabile |
| Consenso marketing o stato membership | Profilo Joomla, estensione o sistema esterno | Richiede un sistema utilizzatore identificato |
La gestione delle password va trattata come questione di identità, non come un generico campo Customer. La possibilità di continuare a usare le credenziali dipende dai modelli di autenticazione sorgente e destinazione e dalla relazione con l’utente Joomla che viene mantenuta.
Orders come evidenza storica
Gli Orders J2Store conservano molto più del totale di intestazione. Possono includere snapshot di Products e opzioni, SKU, quantità, prezzi unitari, sconti, coupon, imposte, spedizioni, etichette di pagamento, indirizzi, valori di checkout personalizzati, note, stati e riferimenti gestiti dalle estensioni.
L’Order storico deve rimanere interpretabile anche se il Product originario cambia o un’estensione non è più attiva. Questo richiede che i valori snapshot restino associati all’Order invece di essere ricostruiti soltanto dal catalogo corrente.
| Relazione Order | Significato da preservare |
|---|---|
| Order verso Customer o guest | Chi ha effettuato l’Order e se esisteva un account persistente |
| Order verso riga | Cosa è stato acquistato, incluse opzioni selezionate e nome/SKU registrati |
| Riga verso prezzo e sconto | Come è stato determinato il subtotale storico |
| Order verso imposte e spedizione | Quali importi ed etichette spiegano il totale |
| Order verso record di pagamento | Metodo di pagamento storico e riferimento del provider quando conservato |
| Order verso cronologia degli stati | Interpretazione operativa della transazione nel tempo |
| Order verso record app | Contesto di abbonamento, prenotazione, accesso file, rata o fulfillment |
Le etichette storiche di pagamento e spedizione non ricreano il comportamento attuale di gateway o corrieri. Appartengono all’Order come evidenza. La configurazione attiva del checkout appartiene all’ambiente di destinazione.
Relazioni tra contenuti, lingue, media e SEO
Le pagine Product J2Store ereditano le capacità di contenuto Joomla. Gli articoli Product possono contenere descrizioni formattate, media incorporati, campi personalizzati, metadati, alias, assegnazioni linguistiche, impostazioni di accesso e plugin di contenuto. Un’esportazione Product dalla sorgente può non distinguere quali valori siano contenuto Product e quali siano generati da template o estensioni.
Il modello di destinazione dovrebbe classificare i media per ruolo:
- immagine incorporata nell’articolo;
- immagine Product principale;
- immagine della galleria Product;
- immagine specifica per un’opzione;
- file scaricabile;
- risorsa per landing page o modulo.
Le relazioni linguistiche vanno oltre il testo tradotto. I siti Joomla multilingua possono utilizzare articoli, Categories, menu, moduli, alias e associazioni linguistiche distinti. L’insieme delle traduzioni deve rimanere collegato sia attraverso il livello contenuto sia attraverso quello e-commerce.
La continuità SEO dipende dalla relazione tra alias degli articoli, percorsi Category, voci di menu, comportamento del router, metadati ed eventuali estensioni per canonical o redirect. Un URL sorgente non dovrebbe diventare automaticamente un campo alias se il percorso era generato da una relazione di menu o Category. La destinazione necessita di un responsabile canonico e di un percorso di redirect definito per le alternative di valore.
App, plugin, tabelle personalizzate e sistemi esterni
I negozi J2Store legacy sono spesso modellati da app e plugin. Estensioni per abbonamenti, prenotazioni, pagamenti parziali, reward, bundle Product, upload, campi checkout, pagamento, spedizione, imposte, reporting e integrazioni possono creare record al di fuori del modello Product-Customer-Order di base.
| Dipendenza | Record nascosti o distribuiti | Requisito di rappresentazione |
|---|---|---|
| App per abbonamenti o membership | Piani, riferimenti di fatturazione, rinnovi, stati di accesso, gruppi di utenti | Mantenere la relazione tra Product, Customer, piano e diritto di accesso |
| App per prenotazioni | Risorse, date, capacità, prenotazioni, partecipanti | Distinguere il Product vendibile dall’istanza prenotata |
| App per pagamenti parziali | Piani di pagamento, rate, saldi, collegamenti alle transazioni | Mantenere coerente la relazione finanziaria |
| Campi checkout personalizzati | Valori Customer, valori indirizzo, metadati Order, input di riga | Assegnare ogni campo al proprietario corretto nel relativo ciclo di vita |
| Plugin di pagamento o spedizione | Configurazione, riferimenti provider, etichette metodo, stati personalizzati | Separare configurazione attiva da evidenza storica dell’Order |
| Integrazione ERP, CRM, contabilità o magazzino | ID esterni, stato di sincronizzazione, tabelle di corrispondenza | Preservare le chiavi durevoli e nominare il responsabile del sistema esterno |
| Override del template o modulo | Regole di visualizzazione e presupposti sugli identificatori | Ricostruire la presentazione rispetto ai record trasferiti |
Lo stato archiviato di J2Store significa che le estensioni legacy potrebbero non avere più un equivalente attivo. La domanda sul modello dati resta oggettiva: quali record contengono significato aziendale e dove vivrà quel significato dopo la migrazione? I record senza un utilizzatore sulla destinazione devono essere archiviati o ritirati deliberatamente, non copiati come residui tecnici opachi.
Tracciabilità dei record legacy e responsabilità sull’archivio
Le migrazioni J2Store richiedono spesso due destinazioni: un modello operativo e un archivio storico. Non tutte le tabelle legacy devono diventare oggetti attivi sulla destinazione, ma i record che spiegano Orders, diritti di accesso, evidenza fiscale o cronologia dei sistemi esterni possono richiedere una conservazione di lungo periodo.
La decisione deve basarsi sulla tracciabilità aziendale anziché sull’età della tabella. Un vecchio Product ID può essere obsoleto per lo storefront ma ancora collegare le righe Order storiche alle esportazioni contabili. Un record di un’app può non controllare più il comportamento attivo, ma può spiegare un periodo di membership o il saldo di una rata. Un alias duplicato può essere inutile come contenuto live, ma richiedere ancora un redirect.
| Record legacy | Uso operativo sulla destinazione | Uso in archivio |
|---|---|---|
| Identificatori Product e articolo | Ricollegare l’articolo vendibile attuale e il contenuto | Tracciare vecchie righe Order o riferimenti esterni |
| Configurazione archiviata di un’estensione | In genere sostituita dalla configurazione corrente | Spiegare come sono state prodotte le transazioni storiche |
| Istanze di abbonamento, prenotazione o pagamento | Continuano soltanto quando esiste un responsabile supportato sulla destinazione | Conservare cronologia contrattuale o delle transazioni quando necessario |
| Campi personalizzati obsoleti | Mantenere soltanto quando vengono usati da un flusso corrente | Conservare in un’esportazione documentata quando servono per interpretare lo storico |
| Vecchie route e alias | Reindirizzare le destinazioni di valore | Mantenere un registro delle route per audit e risoluzione dei problemi |
Questa separazione evita che la destinazione operativa diventi la copia di un’implementazione abbandonata, pur preservando le informazioni di cui personale, Customers o sistemi esterni potrebbero avere bisogno. L’archivio deve rimanere ricercabile e collegato a identificatori aziendali stabili invece di essere lasciato come dump di database non documentato.
Come le differenze di J2Store cambiano l’ambito della migrazione
L’ambito J2Store deve distinguere la rappresentazione dei record dalla ricostruzione delle relazioni e dalla gestione delle dipendenze legacy.
| Trattamento | Esempi | Implicazione per l’ambito |
|---|---|---|
| Trasferimento diretto dei record | Products, Customers, Orders, Categories, contenuti e media standard | Associare i campi alla struttura di destinazione supportata |
| Ricostruzione delle relazioni | Articolo-to-Product, utente-to-Customer, Product-to-opzione, Order-to-record app | Ricostruire il collegamento usando identificatori stabili |
| Configurazione della destinazione | Menu, moduli, template, imposte, pagamenti, spedizioni, accessi e impostazioni linguistiche | Assegnare all’implementazione della destinazione |
| Trasferimento da estensione legacy | Abbonamento, prenotazione, pagamento parziale, checkout personalizzato, reporting | Definire una destinazione corrente oppure conservare come archivio storico |
| Continuità dei sistemi esterni | ID ERP, CRM, contabilità, fulfillment, marketplace | Mantenere identificatori durevoli e responsabilità sulle corrispondenze |
| Ritiro intenzionale | Estensioni abbandonate, route duplicate, campi obsoleti, contenuti inutilizzati | Escludere con una decisione aziendale documentata |
Un modello di migrazione coerente assegna a ogni valore mantenuto una destinazione autorevole. Non usa il vecchio schema J2Store come design della destinazione soltanto perché il database sorgente lo contiene.
Conclusione
Le differenze del modello dati J2Store derivano dal modo in cui l’e-commerce viene sovrapposto ad articoli, utenti, Categories, menu, alias, moduli e template Joomla. Il significato Product è diviso tra record di contenuto e record commerciali. Il significato Customer può estendersi tra identità Joomla e indirizzi o Orders J2Store. I modelli di vendita specializzati dipendono spesso da tabelle gestite da app, e gli Orders storici devono rimanere interpretabili anche quando tali app non sono più attive.
Poiché J2Store è oggi una piattaforma legacy, la migrazione deve preservare il significato aziendale senza riprodurre strutture tecniche obsolete. Il modello di destinazione più solido ricollega identità di articolo e Product, assegna valori Customer e Order al corretto responsabile nel ciclo di vita, tratta esplicitamente i dati delle estensioni e ritira i record che non hanno più un utilizzatore valido.
Domande frequenti
Perché gli articoli Joomla sono centrali nel modello dati J2Store?
J2Store utilizza gli articoli Joomla come base di contenuto dei Products. Contenuto dell’articolo, Category, alias, lingua, accesso e stato di pubblicazione possono quindi essere inseparabili da prezzo, SKU, stock, opzioni e record di acquisto J2Store.
J2Store è ancora la continuazione attiva della piattaforma?
No. Lo sviluppo di J2Store è stato interrotto e il repository archiviato. J2Commerce è il successore attivo. I dati J2Store esistenti restano valide informazioni sorgente, ma devono essere rappresentati nella struttura di destinazione scelta invece di essere considerati automaticamente operativi senza modifiche.
Le opzioni J2Store equivalgono sempre alle varianti su ogni piattaforma?
No. Una scelta sorgente può essere uno SKU con stock proprio, un modificatore di prezzo, un campo di personalizzazione, una specifica o un record di estensione. La struttura di destinazione deve seguire ciò che quella scelta modifica nel comportamento Product e Order.
Come devono essere rappresentati i Customers guest?
I dati di contatto e indirizzo dei guest devono rimanere associati all’Order storico, a meno che non esistesse realmente un account persistente. Creare utenti Joomla artificiali può alterare l’identità e duplicare le cronologie Customer.
Gli Orders storici ripristinano il comportamento attivo di pagamenti, spedizioni o imposte?
No. Gli Orders storici conservano etichette, importi, stati e riferimenti registrati. Il comportamento attivo del checkout appartiene alla configurazione di pagamento, spedizione, imposte e valute sulla destinazione.
Cosa dovrebbe accadere ai dati provenienti da un’estensione J2Store abbandonata?
Occorre stabilire se i record abbiano ancora un uso aziendale, legale o operativo. Quando esiste un responsabile corrente, vanno trasferiti in quella struttura; altrimenti devono essere conservati in archivio o ritirati deliberatamente anziché inseriti come campi opachi in record di destinazione non correlati.