Se Zen Cart viene scelto come piattaforma di destinazione, la preparazione deve rendere comprensibile lo store di origine reale prima che venga finalizzata la configurazione della migrazione. Un’installazione attiva da molti anni può combinare Products nativi, Categories collegate, attributi, download, gruppi di prezzo Customer, totali Order, EZ-Pages, define pages, template, plugin, override, file di lingua e campi di database personalizzati. La vetrina può apparire coerente anche quando i record che la sostengono sono distribuiti tra diversi responsabili tecnici e aziendali.
L’obiettivo della preparazione è trasformare questo ambiente in evidenze controllate sullo store di origine. Ogni area principale deve definire l’azione da completare, la persona responsabile della risposta, le evidenze da fornire e la condizione che rende l’area pronta. In questo modo record ordinari, configurazione della piattaforma, dati posseduti dai plugin e codice personalizzato possono essere distinti prima dell’inizio della configurazione della migrazione.
Stabilire l’accesso all’origine e documentare l’ambiente Zen Cart
Iniziare identificando l’installazione esatta. Registrare versione di Zen Cart, ambiente di hosting, database, document root, percorso amministrativo, language pack attivi, valute, zone fiscali, template, plugin, override e sincronizzazioni esterne. Lo stesso store visibile può funzionare in modo diverso quando un’installazione usa funzionalità native correnti e un’altra dipende da plugin precedenti o modifiche dirette ai file.
Preparare l’accesso all’origine richiesto per il percorso di migrazione selezionato. Accesso al database, hosting, area amministrativa o file non devono essere presentati come scelte intercambiabili. Il responsabile tecnico deve fornire l’accesso corrispondente all’installazione effettiva e restare disponibile quando occorre chiarire permessi, allowlist, percorsi dei file o prefissi del database.
| Azione | Responsabile | Evidenza | Condizione di preparazione |
|---|---|---|---|
| Registrare l’ambiente Zen Cart e PHP esatto | Responsabile hosting o tecnico | Screenshot delle versioni, nota sull’ambiente, versione del database | L’installazione di origine e il relativo contesto di compatibilità sono inequivocabili. |
| Confermare l’accesso all’origine | Responsabile degli accessi | Stato della connessione, dettagli dell’allowlist, prefisso del database, nota sulla root dei file | La connessione richiesta raggiunge lo store di origine corretto. |
| Inventariare template, override e plugin | Sviluppatore o agenzia | Template attivo, elenco plugin, directory degli override, registro dei file modificati | Dati nativi e funzionamento dipendente dal codice possono essere separati. |
| Registrare lingue, valute, zone fiscali e unità | Responsabile e-commerce | Evidenze delle impostazioni ed elenco delle lingue attive | I valori a livello di store che influenzano il significato di Products e Orders sono documentati. |
| Identificare importazioni e sincronizzazioni esterne | Responsabile delle integrazioni | Pianificazione dei flussi di dati, elenco dei sistemi esterni, dettagli dell’ultima esecuzione | I valori che possono cambiare durante la preparazione hanno una fonte autorevole definita. |
Creare un registro delle modifiche una volta raccolte queste evidenze. Le normali attività commerciali possono continuare, ma nuovi plugin, modifiche al database, ristrutturazioni importanti degli attributi o cambiamenti agli URL devono essere registrati, in modo che il modello preparato dello store di origine non diventi obsoleto senza controllo.
Preparare Products, attributi, download e relazioni di prezzo
Zen Cart usa gli attributi Product per rappresentare valori selezionabili, testo inserito dal Customer, caricamenti di file, informazioni di sola lettura, rettifiche di prezzo o peso e file scaricabili. Option Names, Option Values e assegnazione dell’attributo a un Product sono record distinti. Alcune installazioni usano inoltre funzionalità per lo stock delle varianti o attributi dipendenti, native nella versione corrente oppure fornite da un plugin.
Preparare un inventario dei Products che includa Product ID, model o SKU, stato, prezzo, classe fiscale, quantità, funzionamento dello stock, peso, tipo Product, Manufacturer, Category principale, Categories collegate, immagini, Specials, stato featured, sconti quantità, gruppi di prezzo Customer, attributi e riferimenti ai download quando utilizzati. Le evidenze devono mostrare quali valori identificano una scelta effettivamente vendibile e quali sono soltanto descrittivi o inseriti dal Customer.
| Modello nello store di origine | Azione di preparazione | Evidenza | Condizione di preparazione |
|---|---|---|---|
| Taglia, colore o formato selezionabile | Registrare Option Name, Option Value, assegnazione dell’attributo, ordine e stato obbligatorio/predefinito | Product ID rappresentativi ed esportazione degli attributi | Il vocabolario delle scelte e la relazione con il Product sono completi. |
| Attributo che modifica prezzo o peso | Registrare rettifica, prefisso, inclusione nel prezzo base, trattamento dello sconto e Product proprietario | Campione dei prezzi e impostazioni degli attributi | L’effetto commerciale è esplicito e non dedotto dall’etichetta. |
| Input di testo o file | Separare l’input specifico dell’acquisto dai valori riutilizzabili delle opzioni | Elenco Products e righe Order rappresentative | I dati inseriti dall’acquirente non saranno confusi con una variante a stock. |
| Product scaricabile | Registrare file, attributo, giorni di scadenza, numero di download e posizione di archiviazione | Manifest Product/file e file originali accessibili | La relazione Product-to-download e il file di origine sono disponibili. |
| Stock a livello di variante o regola di dipendenza | Identificare responsabile nativo o plugin, combinazioni, SKU e quantità | Tabella delle combinazioni o esportazione del plugin | Le relazioni indipendenti di stock e dipendenza sono documentate. |
| Prezzi per gruppo Customer o quantità | Registrare Product, gruppo, soglia, importo e date | Inventario delle relazioni di prezzo | I prezzi condizionali non vengono ridotti al prezzo base del Product. |
Non normalizzare le etichette degli attributi né unire valori delle opzioni senza approvazione aziendale. Nomi simili possono avere significati diversi per prezzo, stock, download o riga Order.
Documentare Categories, Products collegati, Manufacturers e modalità di scoperta
I Products Zen Cart hanno una Category principale e possono essere collegati anche ad altre Categories. Gerarchia delle Categories, posizionamento dei Products collegati, navigazione per Manufacturer, Specials, Products featured, elenchi dei nuovi Products e ricerca possono tutti influenzare la scoperta. La preparazione deve distinguere la classificazione del catalogo dai menu dei template e dalle sideboxes.
Preparare l’albero delle Categories con ID, relazioni padre-figlio, stato, contenuto per lingua, immagini, ordine, restrizioni per tipo Product e percorsi importanti. Per ogni Product presente in più Categories, registrare Category principale e Categories collegate. Un posizionamento collegato non deve essere scambiato per un record Product duplicato.
| Area di scoperta | Responsabile | Evidenza | Condizione di preparazione |
|---|---|---|---|
| Gerarchia delle Categories | Responsabile catalogo | Esportazione padre-figlio ed elenco delle Categories da mantenere | Ogni Category mantenuta ha un genitore e uno scopo noti. |
| Category principale e Categories collegate | Responsabile merchandising | Relazioni Product-to-Category | Il posizionamento condiviso è visibile senza creare Products duplicati. |
| Record Manufacturer | Responsabile brand | Elenco Manufacturer, assegnazioni ai Products, note sui percorsi pubblici | Il significato pubblico del brand è separato dai dati interni del fornitore. |
| Specials, featured e nuovi elenchi | Responsabile merchandising | Elenchi Products attivi e regole sulle date | Il merchandising dipendente da data o stato è identificato. |
| Menu e sideboxes | Responsabile vetrina | Screenshot e note sul layout/modulo | La presentazione è separata dalle relazioni del catalogo. |
Preparare Customers, gruppi di prezzo, indirizzi e storico degli Orders
La preparazione dei Customers deve distinguere identità dell’account, voci della rubrica, stato di autorizzazione, preferenza newsletter, gruppo di prezzo, livello per il commercio all’ingrosso quando utilizzato, saldo gift certificate, Reviews e identificatori esterni. Un gruppo di prezzo Customer può influenzare il funzionamento commerciale e deve essere documentato come relazione, non conservato soltanto come etichetta.
La preparazione degli Orders deve preservare le evidenze storiche. Selezionare Orders che rappresentino checkout come ospite e con account registrato, attributi, download, sconti, Coupons o gift certificate, imposte, etichette di spedizione e pagamento, commenti, cronologia degli stati, indirizzi di fatturazione e spedizione differenti e totali Order generati da plugin. Mantenere gli indirizzi e le descrizioni Product registrati al momento dell’Order distinti dai dati correnti del Customer e del catalogo.
| Area dei record | Azione di preparazione | Evidenza | Condizione di preparazione |
|---|---|---|---|
| Identità Customer | Identificare duplicati, stati di autorizzazione, gruppi di prezzo e chiavi esterne | Elenco delle eccezioni Customer | Le eccezioni di identità hanno un responsabile e una decisione. |
| Rubriche degli indirizzi | Separare indirizzi riutilizzabili dei Customers dagli snapshot negli Orders | Esempi di indirizzi Customer e Order | I dati correnti dell’account e lo storico delle transazioni non vengono confusi. |
| Gruppi di prezzo o per il commercio all’ingrosso | Registrare appartenenza e ogni relazione Product o prezzo che ne dipende | Matrice tra gruppo e regola | Il significato commerciale è documentato oltre il nome del gruppo. |
| Stati e commenti Order | Registrare etichette, sequenza, visibilità per il Customer e Orders rappresentativi | Inventario degli stati | Gli stati storici possono essere interpretati senza dipendere soltanto dall’etichetta. |
| Totali Order | Identificare subtotale, imposte, spedizione, sconto, gift certificate, commissione e righe di plugin | Set rappresentativi dei totali | Ogni rettifica materiale ha un responsabile noto nello store di origine. |
| Storico dei download | Registrare attributi dei file acquistati, accesso residuo e relazione con l’Order | Orders associati ai download | Il contesto dell’acquisto digitale è incluso nelle evidenze di origine. |
I record storici non devono essere modificati semplicemente per renderli uniformi. Documentare separatamente le anomalie quando spiegano la transazione originale.
Inventariare plugin, override, template e dati personalizzati
I plugin Zen Cart possono aggiungere campi, tabelle, regole di prezzo, logiche di stock, totali Order, percorsi SEO, proprietà Customer, reportistica, flussi di dati o integrazioni. Anche override e modifiche dirette possono cambiare il funzionamento senza creare un record plugin evidente. La preparazione deve identificare quali dati aziendali sono posseduti da ciascun componente.
Creare un registro delle dipendenze con nome del plugin, versione, scopo, stato attivo, elementi interessati, aggiunte al database, file modificati o sovrascritti, sistemi esterni e persona in grado di confermare se il funzionamento resta necessario. Usare “plugin Zen Cart” o il nome specifico del componente, così le estensioni della piattaforma non vengono confuse con le funzionalità aggiuntive del servizio di migrazione.
| Effetto della dipendenza | Evidenze da preparare | Condizione di preparazione |
|---|---|---|
| Estensione per attributi o stock delle varianti | Record delle combinazioni, chiavi Product, campi SKU e quantità | Ogni combinazione attiva ha un responsabile definito nello store di origine. |
| Modulo dei totali Order o del checkout | Riepilogo della configurazione e Orders storici rappresentativi | I valori storici sono separabili dalla configurazione corrente dello store. |
| Plugin SEO o URL | Impostazioni di rewrite, esempi di percorsi e tabelle di redirect | I percorsi importanti di origine possono essere ricostruiti. |
| Estensione Customer o fedeltà | Campi, saldi, cronologia transazioni e chiavi Customer | I dati attivi dell’account hanno una decisione esplicita per la destinazione. |
| Integrazione ERP, marketplace o di evasione degli ordini | ID esterni, direzione della sincronizzazione e fonte autorevole | I sistemi che continueranno a operare possono identificare lo stesso Product, Customer o Order. |
| Contenuto dipendente dal template | Percorsi del template, screenshot e origine del contenuto | Il contenuto aziendale è separato dal codice di presentazione. |
Preparare EZ-Pages, define pages, media ed evidenze sugli URL
I contenuti Zen Cart possono essere pubblicati tramite EZ-Pages, define pages, descrizioni Product e Category, banner, sideboxes, file di template e file di lingua. Preparare un inventario che identifichi il responsabile del contenuto, lingua, percorso corrente, posizione nel menu o nella sidebox, link incorporati, immagini e destinazione prevista.
Registrare gli URL prioritari di Products, Categories, Manufacturers, EZ-Pages, policy, contatti e pagine informative. I percorsi nativi di Products e Categories possono utilizzare ID e percorsi di Category, mentre i plugin SEO possono sostituirli con URL riscritti. L’inventario dei percorsi deve quindi indicare se ogni URL importante è nativo, generato da plugin, statico o reindirizzato esternamente.
Eseguire il backup delle immagini originali e dei file scaricabili con i relativi percorsi. Il database può contenere i nomi dei file senza contenere i file stessi. Segnalare file mancanti, URL di immagini esterne, differenze di maiuscole/minuscole nei percorsi e miniature generate che non rappresentano gli originali di origine.
Creare un pacchetto di origine Zen Cart ripristinabile
Preservare uno stato di origine Zen Cart recuperabile prima di qualsiasi pulizia strutturale o esecuzione della migrazione. Il pacchetto deve includere database, albero di file rilevante, directory dei download, riferimenti di configurazione, evidenze su template e plugin e una nota sull’ambiente riferita allo stesso stato dello store.
| Componente del pacchetto | Responsabile | Evidenza | Condizione di preparazione |
|---|---|---|---|
| Backup del database | Amministratore del database | Dump con timestamp e nota sul prefisso del database | Il dump è completo e appartiene allo store previsto. |
| File e download | Responsabile hosting o tecnico | Archivio dei file o albero di origine accessibile | Immagini originali, download, template, override e plugin sono disponibili. |
| Registro dell’ambiente | Responsabile tecnico | Nota con versioni PHP, database, server e Zen Cart | Il funzionamento dipendente dalla versione può essere interpretato. |
| Registro degli accessi | Responsabile del progetto | Responsabile dell’accesso e stato della connessione | L’accesso richiesto è disponibile senza esporre credenziali nella documentazione. |
| Registro delle modifiche | Amministratore dello store | Modifiche successive al limite temporale delle evidenze | Le modifiche strutturali tardive possono essere incorporate deliberatamente. |
Selezionare campioni rappresentativi per il test di migrazione
Preparare un manifest compatto dei campioni con ID di origine, motivazione aziendale, file collegati e relazioni attese nell’origine. Deve includere sia record ordinari sia le relazioni che hanno maggiore probabilità di essere interpretate male. Il manifest dei campioni Zen Cart è pronto quando ogni aspettativa sull’origine, dipendenza da plugin o attributi, file collegato e identificatore è completo e assegnato a un revisore.
Includere almeno:
- un Product semplice, un Product inattivo e un Product collegato a più Categories;
- un Product ricco di attributi con effetti su prezzo o peso;
- input di testo o file, stock delle varianti o attributi dipendenti quando utilizzati;
- un Product scaricabile con file di origine e storico degli acquisti;
- Products con Specials, prezzi quantità o prezzi per gruppo Customer;
- Customers appartenenti a gruppi di prezzo o autorizzazione rilevanti;
- Orders con attributi, commenti, indirizzi differenti, gift certificate, totali insoliti e download;
- URL prioritari sia nativi sia riscritti;
- un record attivo posseduto da un plugin e un esempio di contenuto dipendente dal template.
Applicare il gate finale di preparazione Zen Cart
Zen Cart è pronto per il passaggio successivo della migrazione quando lo store di origine può essere spiegato senza assunzioni non documentate.
| Domanda di preparazione | Risultato richiesto |
|---|---|
| L’installazione esatta è nota? | Versione, hosting, database, lingue, template, override e plugin sono registrati. |
| Le relazioni Product sono complete? | Attributi, download, Categories, prezzi, media ed estensioni dello stock sono rappresentati. |
| Customers e Orders sono interpretabili? | Gruppi, indirizzi, stati, totali, commenti e ID esterni hanno un responsabile. |
| Plugin e dati personalizzati sono classificati? | Ogni dipendenza attiva ha uno scopo aziendale e una decisione per la destinazione. |
| Contenuti e percorsi sono inventariati? | EZ-Pages, define pages, media e URL importanti nativi o riscritti sono documentati. |
| Backup e accessi sono pronti? | Il pacchetto di origine è ripristinabile e gli accessi richiesti sono disponibili. |
| Il set di campioni è rappresentativo? | Record ordinari e complessi sono elencati con ID di origine e relazioni attese. |
Gli elementi irrisolti devono entrare in un registro decisionale con un responsabile e una data di scadenza. La preparazione è incompleta quando una tabella plugin critica, un file scaricabile, un collegamento Category, una relazione di prezzo o un identificatore esterno è ancora descritto soltanto come sconosciuto.
Conclusione
La preparazione di Zen Cart è più solida quando lo store viene trattato come un catalogo connesso e uno storico transazionale, non come una semplice esportazione di Products. Attributi, download, Categories collegate, gruppi di prezzo Customer, totali Order, EZ-Pages, plugin, override, template e file originali richiedono ciascuno un responsabile chiaro e un insieme di evidenze.
Un pacchetto di origine ripristinabile, un manifest di campioni rappresentativi e un gate di preparazione esplicito costituiscono la base per la configurazione della migrazione.
Domande frequenti
Perché gli attributi Zen Cart devono essere preparati separatamente dai campi Product?
Gli attributi collegano Option Names e Option Values ai Products e possono influire su prezzo, peso, selezione obbligatoria, input dell’acquirente, download o stock. Una riga Product piatta non può preservare in modo affidabile queste relazioni.
Qual è la differenza tra una Category principale e una Category collegata?
Un Product ha una Category principale e può essere collegato a Categories aggiuntive. Registrare entrambe le relazioni affinché il posizionamento aggiuntivo non venga interpretato come Product duplicato o perso durante la preparazione del catalogo.
Un backup del database Zen Cart include immagini e file scaricabili?
No. Il database normalmente memorizza riferimenti. Immagini originali, download, template, override e file dei plugin devono essere preparati anche dal file system.
Come devono essere documentati i dati dei plugin Zen Cart?
Registrare plugin, versione, elementi interessati, campi o tabelle, ID di origine rappresentativi, dipendenze esterne e scopo aziendale che deve continuare. I dati attivi richiedono un responsabile esplicito; i record obsoleti possono essere destinati all’archivio o all’esclusione.
Quali Orders devono essere inclusi nel set di campioni di origine?
Includere Orders ordinari e Orders con attributi, sconti, gift certificate, indirizzi di fatturazione e spedizione differenti, commenti, totali insoliti, download e riferimenti esterni. Questi casi rendono visibili relazioni che gli Orders di base non mostrano.
Gli URL Zen Cart riscritti devono essere trattati come URL Product nativi?
Non automaticamente. Registrare se ogni percorso importante è nativo, generato da un plugin SEO, statico o reindirizzato esternamente. Questa responsabilità determina le evidenze necessarie per riprodurre la relazione del percorso.