Crea e aggiorna un sito di staging PrestaShop privato

Cosa faremmo noi

Concorderemmo la modifica e i relativi test di accettazione prima di creare la copia. Il percorso giusto dipende dal negozio esistente: moduli, integrazioni, tema, dati, mercati e persone che lo testeranno e manterranno. Una modifica alle consegne richiede indirizzi e corrieri rappresentativi; un aggiornamento di versione richiede una prova più ampia delle dipendenze del negozio. Escludi dal test i miglioramenti non correlati, così da poter risalire alla causa di un eventuale problema.

Usa una copia di staging pulita e isolata per provare la modifica prevista, poi pianifica il passaggio in produzione con un responsabile delle decisioni identificato e un percorso di ripristino. Decidi se distribuire un pacchetto testato nel negozio attuale oppure migrare il negozio e riconciliarne i dati finali. Sono piani di rilascio diversi: superare i test sulla copia di ieri non stabilisce cosa accadrà agli ordini di oggi.

Se vuoi affidare a noi un cambio di versione, il PrestaShop Upgrade Service: Any Version to PrestaShop 9 parte dai requisiti del tuo negozio e da una prova su staging.

Definisci cosa verificherà lo staging

Un sito di staging è una copia privata usata per provare le modifiche con file, dati, temi e moduli rappresentativi del negozio. Ti aiuta a trovare conflitti tra moduli, aggiornamenti falliti, problemi di checkout e regressioni delle prestazioni prima del deployment.

Conserva il lavoro di sviluppo nel controllo di versione o in un ambiente di sviluppo separato. Un aggiornamento della copia di staging può sostituire le modifiche locali. Mantieni anche backup indipendenti ripristinabili. Lo staging non è un backup e l'immutabilità dei backup esiste solo quando configuri archiviazione e conservazione appropriate.

Registra la versione di patch PrestaShop in produzione, versione ed estensioni PHP, versione del database, regole del server web, tema, moduli, processi e dipendenze esterne. Parti da questa base. Quando verifichi un aggiornamento, cambia una variabile prevista, come PHP o la versione di un modulo.

Usa lo staging per aggiornamenti del core o di PHP, installazione di moduli, modifiche ai temi, override, migrazioni del database e modifiche importanti a imposte, spedizioni o pagamenti. Il lavoro ordinario sui contenuti può usare una revisione proporzionata, ma una modifica a prezzi, spedizioni o imposte può comunque influire sul checkout e richiede verifiche.

Limita accesso ed effetti collaterali prima di copiare i dati

1. Crea directory, database e utente database separati per lo staging. Limita quell'utente al database di staging.
2. Applica autenticazione del server web, un elenco di rete degli accessi consentiti o una rete privata prima di inserire dati di produzione nell'ambiente. Includi negozio, amministrazione, file statici ed endpoint ausiliari.
3. Mantieni fermi traffico applicativo, processi cron, worker e attività programmate durante clonazione e bonifica.
4. Limita le connessioni in uscita affinché le credenziali copiate non possano raggiungere i servizi in produzione di pagamento, posta, spedizione, ERP, marketplace o webhook.
5. Conserva dump e credenziali fuori dalla directory web principale con permessi limitati.

La modalità manutenzione e robots.txt non offrono un controllo completo degli accessi. Un modulo che protegge la vetrina con una password non protegge ogni file o endpoint amministrativo. Password Protection controlla l'accesso alle richieste gestite dal front office; la sua pagina di aiuto spiega questo ambito limitato alla vetrina.

Usa credenziali di servizio riservate allo staging e un sistema di acquisizione delle email. Riduci al minimo o anonimizza i dati dei clienti in base ai test necessari. Conserva le relazioni e i formati richiesti per test significativi: eliminare indiscriminatamente indirizzi o record di personalizzazione può nascondere difetti del checkout. Preferisci clienti di prova inventati quando i loro dati sono sufficienti. Limita l'accesso ai dati personali copiati e rimuovi copie clonate e dump obsoleti.

Verifica che richieste non autorizzate non possano recuperare un'immagine, un URL amministrativo, un backup della configurazione o un dump del database. Verifica il controllo degli accessi prima di consentire l'avvio dell'applicazione.

Scegli un ambiente hosting o container corrispondente

Container

Fissa l'immagine esatta dell'applicazione/PHP e la versione del database, preferibilmente con digest immutabili delle immagini. Un'immagine senza versione o un tag generico non riproducono la produzione. Usa un volume e un database separati per lo staging. Configura esplicitamente l'host del database dell'applicazione, come il nome di servizio Compose db.

Pubblica una porta locale solo quando necessario, per esempio 127.0.0.1:8080:80, dietro un percorso di accesso autenticato. Pubblicare 8080:80 generalmente espone la porta sulle interfacce dell'host. Segui la documentazione Docker sull'associazione delle porte e applica separatamente i controlli in uscita.

Avvia solo il database durante l'importazione. Attendi un controllo reale di disponibilità anziché una pausa fissa. Predisponi la configurazione di staging dell'applicazione clonata prima di avviarne servizio web o worker. Verifica l'entrypoint dell'immagine affinché installazione automatica o attività di avvio non possano essere eseguite con le impostazioni di produzione copiate.

Usa la versione effettiva del database di produzione per riprodurre un vecchio ambiente, poi verifica separatamente un percorso di aggiornamento supportato. MySQL 5.7 è una dipendenza precedente, non un nuovo valore predefinito per lo staging. Evita di condividere namespace di cache/sessioni con la produzione.

Sottodominio dal pannello hosting

Crea un sottodominio privato con directory principale dei documenti e database propri. Applica le restrizioni prima di importare. Verifica i permessi effettivi del piano: il nome di un pannello non determina la disponibilità di Docker e alcuni fornitori offrono supporto ai container.

Sviluppo locale

Docker, XAMPP, MAMP, WAMP o uno stack Linux locale possono essere utili per le prove. Riproduci i dettagli pertinenti dell'ambiente di esecuzione e ricontrolla i comportamenti specifici della piattaforma nell'ambiente di deployment. La sola etichetta del sistema operativo non determina se una prova locale sia utile.

Segui la guida Docker e la guida allo sviluppo locale per configurare l'ambiente.

Copia un database coerente e tutti i file

Crea un backup di ripristino e registra l'ora dello snapshot. Per le tabelle transazionali InnoDB, mysqldump --single-transaction può fornire uno snapshot coerente senza bloccare le normali scritture per l'intero dump. Non rende coerenti le tabelle non transazionali né protegge da modifiche simultanee allo schema. Coordina lo snapshot di file/database per caricamenti e download che cambiano.

Usa un account di backup con privilegi limitati e una configurazione client sicura o una richiesta interattiva della password. Evita password negli argomenti della shell e negli script. Verifica completamento del dump, codice di uscita e dimensioni del file prima di importarlo nel database di staging confermato. Attendi la disponibilità del database e interrompi se un'importazione fallisce.

Copia file nascosti, moduli, override, temi, immagini, download, caricamenti e risorse personalizzate. Escludi impostazioni di connessione specifiche dell'ambiente e cache di esecuzione dove opportuno. Per esempio, questi percorsi locali descrivono uno snapshot già ottenuto e una directory principale di staging separata:

rsync -av   --exclude='app/config/parameters.php'   --exclude='var/cache/'   --exclude='var/logs/'   /srv/prestashop-snapshot/   /srv/prestashop-staging/html/

La barra finale della sorgente copia il contenuto della directory, inclusi i file nascosti. Anche l'alternativa cp -a /srv/prestashop-snapshot/. /srv/prestashop-staging/html/ include i file nascosti, ma copia la configurazione che devi sostituire prima di qualsiasi richiesta applicativa.

Conferma sorgente e destinazione prima della sincronizzazione. Per gli aggiornamenti della copia che usano eliminazioni, esamina un'esecuzione di prova e proteggi i file riservati allo staging. Non impostare mai la directory principale dei documenti di produzione come destinazione.

Per PrestaShop da 1.7 a 9, predisponi esplicitamente app/config/parameters.php con credenziali del database riservate allo staging. La configurazione precedente della versione 1.6 è config/settings.inc.php. Conserva o sostituisci le chiavi crittografiche consapevolmente, tenendo conto della compatibilità delle password e dei dati cifrati. Copiare le chiavi non giustifica mantenere credenziali esterne di produzione.

Diagnostica gli errori di importazione dall'output effettivo del database. Verifica versioni, set di caratteri, collazioni e compatibilità DDL. Aggiungere SET NAMES utf8mb4 non è una correzione generale per collazioni incompatibili o dati già codificati male. Usa le opzioni di dump e ripristino corrispondenti.

Riscrivi tutti gli URL dei negozi e bonifica le integrazioni

Lavora solo sul database di staging confermato mentre traffico applicativo e processi restano fermi. Individua il prefisso delle tabelle configurato e ogni URL dei negozi e riga di configurazione con ambito specifico. Non presumere che l'ID negozio sia 1.

Usa prima un'ispezione in sola lettura. Questi esempi usano il prefisso illustrativo ps_:

SELECT id_shop_url, id_shop, domain, domain_ssl,
       physical_uri, virtual_uri, main, active
FROM ps_shop_url
ORDER BY id_shop, id_shop_url;

SELECT id_configuration, id_shop_group, id_shop, name, value
FROM ps_configuration
WHERE name IN ('PS_SHOP_DOMAIN', 'PS_SHOP_DOMAIN_SSL')
ORDER BY id_shop_group, id_shop, name;

Definisci una corrispondenza esplicita per ogni riga URL pertinente verso il nome host e il percorso fisico/virtuale dello staging. Aggiorna le righe di configurazione corrispondenti in base al loro ambito effettivo o agli ID. Conserva la topologia multinegozio prevista. Esamina impostazioni dei moduli, reindirizzamenti, domini dei server multimediali, impostazioni canoniche e URL codificati alla ricerca di destinazioni di produzione residue. Se un URL torna ancora alla produzione, esamina la catena dei reindirizzamenti e gli header della risposta: una vecchia regola del server web, un reverse proxy o un'impostazione CDN possono reindirizzare prima che PrestaShop gestisca la richiesta. Mantieni nomi host e certificati dello staging separati dall'instradamento della produzione.

1. Sostituisci le credenziali di pagamento di produzione con credenziali sandbox oppure disattiva l'integrazione.
2. Disattiva l'acquisto di etichette e altre azioni di spedizione a pagamento. Usa un servizio di prova dove disponibile.
3. Disattiva o isola connessioni ERP/WMS, marketplace, scorte dei fornitori, CRM, marketing, analytics e webhook in uscita.
4. Configura la posta del core per disattivare l'invio o usare un sistema di cattura in Parametri avanzati > Email. Copri i client SMTP indipendenti dei moduli e le API email con cattura verificata o restrizioni in uscita.
5. Disattiva i processi di produzione in cron di sistema, timer, pannelli hosting, pianificatori dei moduli, worker delle code e pianificatori esterni.
6. Disattiva generazione/invio delle sitemap di staging nel modulo sitemap installato e rimuovi i file generati riservati alla produzione dove opportuno.
7. Usa controlli di accesso privati, più header noindex o regole robots come controlli aggiuntivi di indicizzazione.

Le sole impostazioni della posta del core non possono bloccare ogni trasporto indipendente dei moduli. La sola riscrittura DNS o degli URL non può neutralizzare una chiave di pagamento di produzione. Mantieni le restrizioni in uscita finché ogni integrazione non è stata verificata.

Svuota le cache e verifica il clone isolato

Dopo aver completato configurazione e bonifica dello staging, svuota le cache applicative appropriate alla versione come utente dell'applicazione. In un negozio moderno, le cache Smarty e del framework usano percorsi specifici dell'ambiente sotto var/cache. Le versioni precedenti hanno strutture diverse.

Usa l'operazione supportata di svuotamento dell'applicazione dalla directory principale di staging confermata. In un container, eseguila tramite il servizio applicativo nella sua directory di lavoro del negozio. Docker exec non espande da solo i caratteri jolly della shell; una shell dell'host può espandere un carattere jolly senza virgolette sul filesystem sbagliato. Evita ricette di eliminazione estese.

Se le impostazioni di deployment lo richiedono, reimposta OPcache dell'ambiente web di staging tramite la procedura dell'hosting/servizio. Una reimpostazione solo CLI normalmente non reimposta la cache di PHP-FPM. Verifica permessi e ricostruzione della cache prima di aprire il percorso web con accesso limitato.

1. Conferma che l'applicazione si connetta solo al database di staging.
2. Verifica gli URL di homepage, categorie, prodotti e amministrazione di ogni negozio per trovare reindirizzamenti verso la produzione.
3. Esamina i log per errori di database, permessi, template e PHP.
4. Esegui un ordine di prova con ogni metodo di pagamento sandbox, comprese le notifiche di pagamento asincrone dove usate. Verifica che il fornitore punti all'URL di callback dello staging e possa raggiungere l'endpoint richiesto senza esporre il resto della copia. Controlla imposte, spedizioni, sconti, scorte e rimborsi.
5. Attiva un'email di prova e conferma che raggiunga solo il sistema di cattura.
6. Controlla i tentativi di connessione in uscita e verifica che i servizi di produzione restino bloccati.
7. Verifica che i processi restino fermi salvo quelli esplicitamente attivati per una prova.

Usa un profilo browser separato per ridurre gli errori operativi quando lavori con produzione e staging. Controlla i nomi dei cookie e gli attributi Domain, soprattutto quando staging e produzione condividono un dominio padre: alcuni cookie possono raggiungere entrambi gli host. Usa il profilo browser separato per tenere distinte le sessioni. Identifica chiaramente il nome host e l'amministrazione dello staging.

Prova l'aggiornamento di un modulo di consegna

Supponiamo che i tuoi negozi britannico e francese condividano un modulo di consegna e che gli ordini accettati vengano esportati a un magazzino. Prima di aggiornarlo, documenta un carrello rappresentativo per ogni mercato: indirizzo, lingua, valuta, prodotti, corriere, costo di consegna e totale finale. Includi un carrello che dovrebbe essere rifiutato dalle restrizioni del corriere. Questi diventano risultati attesi, anziché una semplice verifica che il checkout si apra.

Sulla copia isolata, installa la versione proposta e confronta gli stessi carrelli. Completa un pagamento sandbox ed esamina corriere, indirizzo di consegna e dati di esportazione dell'ordine risultante senza inviarli al magazzino di produzione. Verifica che non sia stata acquistata alcuna etichetta a pagamento. Se una tariffa concordata con il corriere non ha un equivalente di test, documenta questa lacuna e concorda separatamente una verifica controllata in produzione.

Esamina le esportazioni in coda oltre alle richieste immediate. Una connessione al magazzino bloccata può lasciare attività in attesa di un nuovo tentativo; non collegare in seguito quella coda di staging all'account di produzione per vedere se si svuota. Usa una destinazione di test isolata o esamina i dati in coda. Conserva risultati attesi ed effettivi insieme alla versione del pacchetto, così il personale può approvare la modifica sulla base di riscontri.

Verifica un modulo e prova il deployment

1. Leggi i requisiti del modulo per versione, PHP, tema, multinegozio e licenza. Esamina contenuto del pacchetto e dipendenze esterne. Una ricerca di stringhe per eval o decodifica base64 non è una revisione di sicurezza completa.
2. Crea uno snapshot di recupero dello staging e registra pagine e tempi di riferimento.
3. Installa lo ZIP della versione esatta tramite Gestione moduli. Verifica errori di installazione, tabelle create, registrazione degli hook e log.
4. Salva la configurazione e prova la funzionalità prevista. Verifica pagine home, categoria, prodotto, carrello, checkout e account, secondo pertinenza.
5. Verifica mobile, lingue/valute supportate e ogni contesto multinegozio che usi. Esamina errori del browser e richieste fallite.
6. Completa i percorsi sandbox di acquisto, annullamento e rimborso. Verifica i moduli esistenti importanti insieme alla nuova funzionalità.
7. Confronta tempi ripetuti e comportamento delle pagine in condizioni equivalenti di cache e traffico.
8. Verifica aggiornamento, disattivazione e disinstallazione su una copia eliminabile. Alcuni moduli conservano intenzionalmente dati commerciali; confronta la pulizia con la politica documentata.

Conferma le autorizzazioni per dominio di produzione, dominio di staging, localhost e prova della singola licenza. Non presumere che ogni modulo offra attivazioni locali gratuite illimitate o un periodo demo identico. Per domande sulle licenze mypresta.rocks, usa la guida alle licenze o contatta l'assistenza.

Se vuoi affidare a noi l'installazione e la verifica di un pacchetto esistente, il PrestaShop Module Installation & Configuration Service copre la configurazione concordata e il percorso del cliente o del personale.

Approva il risultato e pianifica il passaggio in produzione

Chiedi al titolare o al tester designato di approvare il risultato operativo, lasciando allo sviluppatore la responsabilità dei riscontri tecnici. Mantieni visibili i difetti irrisolti e le integrazioni non testate; un'installazione senza errori non equivale all'accettazione del percorso di acquisto.

1. Documenta l'istantanea del negozio testata, l'ambiente di esecuzione, le versioni dei pacchetti e le modifiche alla configurazione. Un successivo aggiornamento dei dati o una modifica al codice possono invalidare il risultato.
2. Conserva risultati attesi ed effettivi per mercati, dispositivi e integrazioni interessati, inclusi errori e percorsi di ripristino.
3. Conferma chi eseguirà il deployment, chi può fermare il passaggio e chi monitorerà poi ordini, pagamenti ed evasione.
4. Concorda la finestra di rilascio ed eventuali sospensioni di ordini, modifiche del personale o importazioni. Usa la prova per stimare l'interruzione anziché promettere una durata fissa.
5. Dimostra il ripristino su una copia eliminabile e definisci l'errore che lo attiva. Includi nel piano le modifiche al database e le nuove attività commerciali.

Prima del deployment in produzione, esegui un nuovo backup ripristinabile della produzione e concorda la procedura per tornare indietro. Distribuisci il pacchetto testato e la configurazione prevista durante una finestra appropriata. Esegui un test rapido delle funzioni essenziali in produzione e monitora log e flusso degli ordini. Escludi dalla configurazione di produzione credenziali riservate allo staging, ordini di prova e restrizioni specifiche dello staging. Mantieni le impostazioni di privacy e consenso previste per la produzione.

Tieni separati i file di rilascio dai dati operativi finali

Per una modifica a un modulo o tema, distribuisci i file testati e le impostazioni previste sui dati attuali di produzione usando la procedura supportata di installazione o aggiornamento. Non sostituire il database di produzione con quello di staging. Ordini di prova, clienti anonimizzati e vecchi valori delle scorte non devono finire in produzione.

Per una migrazione di versione o un negozio sostitutivo, prova separatamente la riconciliazione finale dei dati. Identifica cosa è cambiato dall'istantanea: ordini, clienti, scorte, modifiche al catalogo, rimborsi e stato delle integrazioni. Usa il processo supportato dalla migrazione per la copia finale o il trasferimento incrementale, tenendo conto delle differenze di schema. Se non esiste un processo incrementale supportato, prova una sospensione delle scritture che copra l'istantanea finale della produzione, la migrazione e la validazione, e concorda l'interruzione prima di approvare il passaggio. Un'unione alla cieca di tabelle selezionate può rompere le relazioni anche se il numero di ordini visibile coincide.

Al passaggio concordato, coordina scritture del checkout, lavoro del personale, importazioni, worker e notifiche di pagamento ritardate, così l'attività commerciale non può dividersi tra vecchio e nuovo negozio. Riconcilia i record finali e le code delle integrazioni prima di avviare l'evasione. Dopo la riapertura, ripristinare un backup precedente può perdere nuovi ordini o aggiornamenti dei pagamenti; il recupero deve tenere conto di queste attività. Ripristinare solo i vecchi file PHP non può annullare una migrazione incompatibile del database.

Cosa chiedere allo sviluppatore o all'agenzia

• Quali differenze rispetto alla produzione restano nello staging e cosa ci impediscono di verificare?
• Quali file, impostazioni e modifiche allo schema distribuirai e quali dati resteranno dove sono?
• Come verranno riconciliati gli ultimi ordini, pagamenti, rimborsi e movimenti di magazzino se viene trasferito l'intero negozio?
• Dove sono i riscontri di accettazione e i passaggi di ripristino e chi è responsabile di un incidente dopo la riapertura?

Ripeti l'isolamento a ogni aggiornamento della copia

Aggiorna la copia prima di prove significative quando il clone non rappresenta più la produzione. Scegli una cadenza in base alle versioni e alle modifiche del catalogo, anziché a una promessa fissa sui tempi di configurazione o aggiornamento della copia.

1. Conserva tutto il lavoro che deve sopravvivere all'aggiornamento della copia.
2. Riapplica le restrizioni di accesso e in uscita, poi interrompi traffico applicativo, processi e worker.
3. Ottieni e verifica un nuovo snapshot. Interrompi in caso di errore nel dump, trasferimento o importazione.
4. Importa nel database di staging e sincronizza i file di staging confermati.
5. Predisponi nuovamente le impostazioni di connessione di staging e mappa ogni URL dei negozi.
6. Riapplica cattura delle email, credenziali sandbox, controlli dei pianificatori, minimizzazione dei dati e restrizioni delle integrazioni. Il nuovo database ha ripristinato le impostazioni di produzione.
7. Svuota le cache di staging e verifica i permessi di esecuzione.
8. Ripeti i controlli di isolamento e del flusso di acquisto prima di consentire l'uso con accesso limitato.

Automatizza questa procedura con passaggi che restano bloccati in caso di errore: verifica disponibilità del database, codici di uscita dei comandi e backup non vuoti e interrompi al primo errore. Segnala un aggiornamento della copia riuscito solo dopo la validazione. Mantieni separati lo snapshot di produzione e la configurazione di staging affinché un aggiornamento della copia non possa ripristinare silenziosamente l'accesso ai servizi di produzione.

Usa la guida alla verifica dei moduli e la guida ai backup per mantenere la checklist di rilascio.

Domande dei titolari dei negozi

E se un'integrazione non ha una sandbox?

Usa un sostituto isolato oppure esamina la richiesta senza inviarla e indica l'interazione reale come non testata. Concorda l'eventuale validazione necessaria in produzione con il fornitore e con il responsabile della fatturazione o dell'evasione. Una richiesta bloccata dimostra l'isolamento, non la riuscita dell'integrazione.

Lo sviluppatore può aggiornare lo staging durante l'accettazione del personale?

Concorda una finestra di test e identifica la build in esame. Un aggiornamento della copia cambia i dati e può azzerare la configurazione, quindi avvisa i tester e ripeti le verifiche interessate. Non combinare risultati di build diverse come se descrivessero lo stesso rilascio.

Perché lo staging può sembrare più veloce del negozio in produzione?

Può avere meno visitatori, risorse diverse o un comportamento diverso di cache e servizi esterni. Documenta queste differenze prima di confrontare i tempi. Un acquisto su uno staging poco trafficato fornisce riscontri funzionali utili, ma non dimostra la capacità della produzione.

Quando dobbiamo rimuovere una copia di staging?

Conservala solo finché serve a uno scopo concordato di test o assistenza. Quando la dismetti, rimuovi l'applicazione esposta e i dump obsoleti, revoca le credenziali ed elimina i processi e le autorizzazioni di accesso. Gestisci i backup di ripristino conservati secondo la loro politica di conservazione separata.