Se J2Store viene scelto come piattaforma di destinazione, la preparazione deve considerare che i Products sono costruiti sugli articoli Joomla e possono essere estesi tramite diversi tipi di Product e applicazioni. Un Product può dipendere da contenuti Joomla, Categories, menu, moduli, gruppi di utenti, opzioni, varianti, download, Products raggruppati, applicazioni per prenotazioni o abbonamenti, plugin di pagamento e spedizione, override dei template e tabelle personalizzate.
Un pacchetto di preparazione affidabile rende visibile ogni dipendenza prima dell’inizio della migrazione. Deve definire azione, responsabile, evidenza e condizione di prontezza per ogni area principale, mantenendo separati i record e-commerce storici dalla configurazione live della destinazione. Poiché molte installazioni J2Store sono longeve o fortemente estese, il pacchetto deve inoltre documentare chi è responsabile delle decisioni di manutenzione, ripristino e compatibilità della piattaforma sorgente.
Confermare accesso alla sorgente, ripristino e responsabilità sul ciclo di vita
Iniziare verificando accesso funzionante a Joomla Administrator e J2Store, accesso a hosting e database, filesystem e media, nonché ad attività pianificate o servizi esterni. Registrare versioni di Joomla, J2Store, PHP, database, template ed estensioni.
| Azione di preparazione | Responsabile | Evidenza | Condizione di prontezza |
|---|---|---|---|
| Confermare l’accesso amministrativo | Amministratore Joomla/J2Store | Account funzionanti e riepilogo dei ruoli | Products, Customers, Orders, applicazioni e strutture Joomla possono essere ispezionati. |
| Creare backup ripristinabili | Responsabile dell’infrastruttura | Esportazione database, archivio filesystem, note sui media e procedura di ripristino | La sorgente può essere ripristinata indipendentemente dal negozio live. |
| Registrare l’ambiente installato | Responsabile tecnico | Inventario versioni per Joomla, J2Store, PHP, database, template, plugin, moduli e applicazioni | Lo stack reale della sorgente è documentato, inclusi componenti obsoleti o personalizzati. |
| Assegnare la responsabilità sul ciclo di vita | Responsabili aziendali e tecnici | Responsabile nominato per hosting, sicurezza, compatibilità, sostituzione delle estensioni e ripristino | L’ambito della migrazione non viene usato come sostituto della manutenzione dell’ambiente sorgente o di destinazione. |
| Preservare gli identificatori | Coordinatore della migrazione | ID di articolo, Product, Category, opzione, variante, Customer, utente, Order, applicazione ed esterni | I collegamenti tra record possono essere tracciati dopo l’estrazione. |
Se il negozio non è più mantenuto attivamente, registrarlo esplicitamente. Evitare pulizia, aggiornamenti o rimozione di estensioni prima che backup immutabile ed evidenza dello schema siano completi, perché una tabella o un plugin apparentemente inutilizzati potrebbero ancora contenere storico Order o Product.
Preparare Products basati sugli articoli e tipi di Product
J2Store utilizza gli articoli Joomla come Products. La preparazione deve preservare sia l’identità dell’articolo Joomla sia il record e-commerce J2Store. I tipi di Product possono includere strutture semplici, variabili, configurabili, scaricabili, flexivariable, advanced variable, prenotabili, in abbonamento, raggruppate, bundle o definite da applicazioni, a seconda dell’installazione.
| Pattern Product | Evidenza | Condizione di prontezza |
|---|---|---|
| Product semplice | ID articolo/Product, SKU, prezzo, stock, profilo fiscale, peso, immagini, collegamenti Category e Order campione | Identità di contenuto e identità commerciale puntano allo stesso articolo vendibile. |
| Product variabile | Opzioni, combinazioni generate, SKU, prezzo, stock, peso, immagine e stato per combinazione | Ogni combinazione vendibile è tracciabile e completa. |
| Product flexivariable o advanced variable | Record delle combinazioni, stato di pubblicazione, input non di variante e campi personalizzati | Combinazioni di varianti e valori inseriti dal Customer sono separati. |
| Product scaricabile | Record dei file, limiti di download, scadenza, route dell’area Customer e Order completato di esempio | Sono documentate le relazioni Product-to-file e Order-to-accesso. |
| Product raggruppato o bundle | Parent, componenti, quantità, logica prezzi/sconti, proprietario dello stock e Order campione | Composizione e relazione di inventario sono esplicite. |
| Product di prenotazione o abbonamento | Risorsa/piano, pianificazione, stato, dipendenza di pagamento, comportamento dei gruppi Joomla e record storici | La responsabilità dell’applicazione specializzata è documentata. |
Classificare ogni famiglia Product in base a ciò che cambia quando l’acquirente seleziona un’opzione: SKU, stock, prezzo, peso, spedizione, imposte, accesso ai file, disponibilità di prenotazione, calendario dell’abbonamento o input del Customer. Questo determina se il valore appartiene a una vera variante, a un’opzione Product, a un input di riga Order o a un record dell’applicazione.
Preparare opzioni, varianti, immagini e input Customer
Le strutture di opzioni J2Store possono produrre risultati diversi in base al tipo di Product e alle applicazioni installate. Un Product variabile può generare una matrice di combinazioni con SKU, prezzo e stock indipendenti. Un advanced variable Product può combinare dimensioni di variante con input liberi. Un Product raggruppato può rifiutare Products che hanno già opzioni.
| Area di preparazione | Evidenza | Condizione di prontezza |
|---|---|---|
| Definizioni delle opzioni | Nomi, tipi, valori, ordinamento, assegnazioni Product ed effetti sul prezzo | Vocabolari di opzioni equivalenti e distinti sono compresi. |
| Combinazioni di varianti | Parent Product, combinazione di valori, SKU, prezzo, stock, immagine, stato e chiave esterna | Ogni child vendibile ha un’identità stabile. |
| Testo o file inseriti dal Customer | Definizione dell’input e valori di riga Order campione | L’input occasionale non viene confuso con metadati Product riutilizzabili. |
| Immagini Product e varianti | File principale, thumbnail, aggiuntivi e specifici per combinazione | I media sono associati al Product o alla variante corretti. |
| Combinazioni dismesse o inutilizzate | Stato, uso nello storico Orders e decisione di ritiro | I riferimenti storici sono preservati anche se la combinazione live viene esclusa. |
Non rigenerare le matrici di varianti prima di aver registrato le combinazioni originali e i relativi ID. La rigenerazione può modificare l’identità o eliminare dati collegati alle combinazioni esistenti. Se è necessaria una pulizia, mantenere un registro di corrispondenza tra sorgente e struttura ripulita.
Preparare Joomla Categories, menu, moduli e URL
Poiché i Products J2Store sono articoli Joomla, la loro scoperta dipende da Joomla Categories, ordinamento degli articoli, voci di menu, moduli, livelli di accesso, lingue, viste del template e route delle applicazioni. Preparare queste relazioni per Products e pagine storefront di valore elevato.
| Relazione di scoperta | Evidenza | Condizione di prontezza |
|---|---|---|
| Articolo Product verso Category | ID articolo/Product e gerarchia Category | Il posizionamento Product è intenzionale e tracciabile. |
| Ordinamento Category e articoli | Valori di ordinamento sorgente e regole di visualizzazione dei menu | L’ordine di merchandising importante è documentato dove necessario. |
| Voce di menu verso vista del negozio | Tipo di menu, alias, parent, lingua, livello di accesso e destinazione | Sono note le route di Product, Category, cart, checkout, profilo, download e account. |
| Assegnazione dei moduli | Posizione, assegnazione al menu, lingua e responsabile | I moduli storefront sono classificati come contenuto, presentazione o output applicativo. |
| URL e redirect | Percorso corrente, responsabile dell’oggetto, intento della destinazione ed estensione di routing | Le route prioritarie hanno una sola destinazione prevista. |
| Relazione multilingua | Assegnazioni linguistiche e associazioni Joomla | Famiglie Product e di navigazione tradotte sono tracciabili. |
Un’esportazione Product non ricrea menu o moduli Joomla. Preparare le evidenze di contenuto e route necessarie per distinguere la migrazione dei dati dall’implementazione di template e navigazione sulla destinazione.
Preparare Customers, utenti Joomla, gruppi e indirizzi
I Customers J2Store possono essere collegati a utenti Joomla, Orders guest, indirizzi, gruppi Joomla, profili specifici delle applicazioni, campi fiscali, dati aziendali e identificatori esterni. Preparare queste relazioni separatamente.
| Pattern account | Evidenza | Condizione di prontezza |
|---|---|---|
| Customer registrato | ID utente Joomla, profilo Customer, email, gruppi, indirizzi, stato e Orders | Email duplicate e account con più gruppi hanno un trattamento documentato. |
| Customer guest | Identità e indirizzi a livello Order | Lo storico guest resta comprensibile senza creare account non supportati. |
| E-commerce basato su gruppi | Gruppo Joomla, collegamento Product, stato Order di attivazione, effetto su prezzi/accessi e applicazione responsabile | L’assegnazione al gruppo è rappresentata come relazione aziendale e non come semplice etichetta. |
| Account aziendale o fiscale | Campi azienda, identificativo fiscale, stato di esenzione e ID account esterno | L’identità aziendale ha un responsabile nominato. |
| Dipendenza di autenticazione | Origine password, SSO/social login, MFA, flusso di reset e responsabile della comunicazione | L’accesso all’account è pianificato senza presumere la portabilità delle credenziali sorgente. |
Quando un’applicazione aggiunge un utente a un gruppo Joomla dopo l’acquisto, acquisire Product, gruppo selezionato, stato Order che attiva l’azione, appartenenza corrente e storico campione. Questo flusso può controllare contenuti o servizi protetti dopo la vendita.
Preparare Orders ed evidenze storiche e-commerce
Preparare intestazioni Order, righe Order, riferimenti Product e variante, opzioni selezionate, input Customer, indirizzi di fatturazione e spedizione, prezzi, sconti, imposte, etichette di pagamento e spedizione, stati, commenti, tracking, fatture, download, abbonamenti, prenotazioni, voucher e record di applicazioni quando presenti.
| Record storico | Evidenza | Condizione di prontezza |
|---|---|---|
| Cronologia dello stato Order | Definizioni degli stati, timestamp, commenti e significato operativo | Ogni stato può essere interpretato senza dipendere dalla vecchia interfaccia. |
| Righe Product | ID articolo/Product/variante, SKU, valori selezionati, quantità, prezzo e imposta | L’articolo acquistato rimane identificabile anche se il catalogo live cambia. |
| Contesto del pagamento | Etichetta del metodo e riferimento della transazione | Le evidenze storiche di pagamento sono disponibili senza trasferire credenziali. |
| Contesto della spedizione | Etichetta del metodo, costo, tracking e note di fulfillment | L’evidenza storica di consegna è distinta dalla configurazione attuale del corriere. |
| Accesso ai download | File Product, stato Order, limite, scadenza e collegamento Customer | Lo storico dei diritti di accesso digitali è tracciabile. |
| Storico gestito da app | Abbonamento, prenotazione, bundle, assegnazione gruppo, voucher o record loyalty | I record applicativi correlati sono collegati a Order e Customer corretti. |
Creare un glossario degli stati per Order, pagamento, spedizione, download, abbonamento e prenotazione. Termini simili come New, Confirmed, Pending, Failed o Completed possono avere significati operativi diversi in base all’estensione.
Inventariare applicazioni, plugin, campi personalizzati e tabelle personalizzate
Le applicazioni J2Store possono gestire Products raggruppati, bundle, costi aggiuntivi, sconti quantità, azioni sui gruppi Customer, prenotazioni, abbonamenti, download, spedizioni, pagamenti, analytics e altri record. Plugin Joomla, override dei template e tabelle personalizzate possono estendere le stesse entità.
Per ogni dipendenza importante, documentare:
- nome e versione;
- scopo aziendale;
- tabelle e campi;
- chiavi Product, Customer, utente e Order;
- attività pianificate o event trigger;
- servizi e identificatori esterni;
- responsabile sulla destinazione o decisione di ritiro;
- record sorgente rappresentativi.
Non descrivere il requisito soltanto come “dati dell’app”. Nominare l’entità: abbonamento, prenotazione, componente bundle, commissione, assegnazione gruppo, diritto di download, campo checkout personalizzato, listing o stato di integrazione. Una definizione chiara dell’entità è necessaria prima di scegliere una destinazione.
Separare i record storici dalla configurazione live della destinazione
Etichette e importi storici possono migrare come evidenza, ma comportamento live di imposte, pagamenti, spedizioni, email, cron, template, sicurezza ed estensioni deve essere implementato separatamente.
| Evidenza sorgente | Responsabilità separata sulla destinazione |
|---|---|
| Etichetta metodo di pagamento e ID transazione | Account gateway, credenziali, callback, controlli antifrode e test live |
| Metodo di spedizione, costo e tracking | Account corriere, zone, tariffe, ritiro, imballaggio e configurazione fulfillment |
| Importo fiscale storico ed etichetta profilo | Registrazioni fiscali correnti, aliquote, esenzioni e regole di calcolo |
| Relazione Product e gruppo Customer | Accesso corrente, prezzi o automazione della membership |
| Storico download | Protezione file corrente, area Customer, consegna email e policy di accesso |
| Storico abbonamento o prenotazione | Supporto gateway corrente, attività pianificate, regole di capacità, notifiche e logica di rinnovo |
| URL Store esistenti | Menu di destinazione, alias, output template, redirect e implementazione della ricerca |
Il pacchetto di preparazione è pronto quando evidenza sorgente e responsabilità sull’implementazione della destinazione sono entrambe esplicite. Non deve affermare che i record storici configurino le operazioni future.
Selezionare campioni rappresentativi per il test di migrazione
Scegliere campioni difficili e ricchi di relazioni anziché soltanto Products semplici e puliti. Includere:
- un Product semplice collegato a un articolo Joomla e a una Category;
- un Product variable o flexivariable con dati di combinazione indipendenti;
- un advanced variable Product con input del Customer, se utilizzato;
- un Product scaricabile con storico di accesso;
- un Product raggruppato, bundle, prenotabile o in abbonamento, se utilizzato;
- una route Product multilingua o con accesso limitato;
- un Customer con più indirizzi o gruppi;
- un Order guest e un Order di Customer registrato;
- un Order con evidenza di sconto, imposte, pagamento, spedizione e tracking;
- un record gestito da applicazione o un identificatore esterno.
Per ogni campione, registrare ID sorgente, record Joomla e J2Store collegati, motivo della selezione, evidenza richiesta e ogni comportamento live assegnato intenzionalmente all’implementazione della destinazione.
Stabilire il controllo finale di prontezza
| Domanda di prontezza | Condizione per essere pronti |
|---|---|
| Il negozio può essere ripristinato? | Esistono backup immutabili di database e filesystem con un responsabile del ripristino. |
| La responsabilità sul ciclo di vita è chiara? | Hosting, sicurezza, compatibilità, sostituzione delle estensioni e ripristino hanno responsabili nominati. |
| Tipi di Product e varianti sono classificati? | Ogni pattern Product importante ha evidenza sorgente e un campione rappresentativo. |
| Le relazioni Joomla sono mappate? | Articoli Product, Categories, menu, moduli, lingue, livelli di accesso e URL sono tracciabili. |
| Customers e Orders sono comprensibili? | Collegamenti utenti, gruppi, indirizzi, stati, totali e storico gestito dalle app sono documentati. |
| Applicazioni e dati personalizzati hanno un responsabile? | Ogni dataset attivo ha schema, responsabile, chiave sorgente e decisione sulla destinazione. |
| La configurazione della destinazione è separata? | Le responsabilità per checkout, pagamento, spedizione, imposte, cron, template e sicurezza sono assegnate. |
| Gli elementi irrisolti sono sotto controllo? | Ogni dipendenza irrisolta ha un responsabile, una scadenza e un effetto sull’ambito. |
Backup mancanti, responsabilità poco chiara sul ciclo di vita, varianti rigenerate senza registro sorgente, tabelle app sconosciute o storico di Product specializzati non tracciabile devono bloccare l’ambito interessato.
Conclusione
La preparazione di una migrazione verso J2Store deve preservare il collegamento tra articoli Joomla e record e-commerce, considerando al tempo stesso tipi di Product, varianti, file, Customers, Orders, applicazioni, URL e personalizzazioni accumulate nel tempo. Il pacchetto di preparazione deve mostrare chi è responsabile di ogni azione, quale evidenza dimostra la relazione sorgente e quale condizione rende pronto l’ambito.
Questo approccio mantiene distinti i record storici dalla configurazione live della destinazione ed evita che il comportamento di estensioni legacy venga nascosto dentro una generica esportazione Product o Order.
Domande frequenti
Che cosa deve essere preparato per primo prima di una migrazione J2Store?
Confermare accesso a Joomla, J2Store, hosting, database, filesystem, media e attività pianificate. Creare backup immutabili e documentare versioni sorgente e applicazioni installate prima di qualsiasi pulizia o aggiornamento.
Perché i Products J2Store richiedono evidenze sia Joomla sia e-commerce?
J2Store utilizza gli articoli Joomla come Products. Contenuti, Categories, lingua, accesso, menu e route possono appartenere a Joomla mentre SKU, prezzo, stock, opzioni, varianti e relazioni Order appartengono a J2Store.
Come devono essere preparati i variable Products J2Store?
Registrare le definizioni delle opzioni e ogni combinazione generata con Parent Product, valori selezionati, SKU, prezzo, stock, immagini, stato e identificatori esterni. Non rigenerare le combinazioni prima di preservare la mappa delle identità originali.
Quali evidenze servono per i Products scaricabili?
Preparare collegamenti Product-to-file, posizioni dei file, limiti di download, impostazioni di scadenza, route dell’area Customer, stati Order rilevanti e Orders completati rappresentativi che mostrino lo storico di accesso.
Come devono essere documentate applicazioni J2Store e tabelle personalizzate?
Nominare applicazione ed entità, registrare tabelle, chiavi, relazioni Product/Customer/Order, trigger, attività pianificate, dipendenze esterne e record rappresentativi. Evitare di trattare tutte le informazioni gestite dalle estensioni come generici dati personalizzati.
Quali record vanno scelti per il test rappresentativo di una migrazione J2Store?
Scegliere Products semplici basati su articoli, Products con varianti, tipi di Product avanzati o specializzati, route con accesso limitato o multilingua, Customers complessi, Orders guest e registrati, accesso digitale, dati gestiti da applicazioni e identificatori esterni.