DataFirefly Staging Pro — Guida completa

Staging Pro crea una copia completa del tuo negozio (file + database) in una sottocartella protetta del tuo hosting attuale, senza alcun timeout grazie al suo motore di copia a lotti. Testi moduli, temi e aggiornamenti in totale sicurezza, poi riporti le tue modifiche in produzione tabella per tabella, con backup automatico e rollback con un clic. Questa guida copre l’installazione, la creazione di uno staging, le opzioni di protezione, il push in produzione e il rollback.

Installazione

1. Scarica l’archivio dfstagingpro.zip dal tuo account DataFirefly.
2. Back office PrestaShop → Moduli → Carica un modulo → invia lo ZIP.
3. All’installazione, il modulo crea le sue tabelle df_staging_env e df_staging_log, registra i suoi hook e aggiunge la scheda Parametri avanzati → Staging Pro.

Come funziona lo staging

Un ambiente di staging viene creato in una sottocartella nella radice del tuo negozio (ad esempio /staging-v2/) e usa un prefisso di tabelle dedicato (ad esempio dfs1_) nello stesso database della produzione. Non hai quindi bisogno né di un secondo server, né di un nuovo accesso MySQL, né di una configurazione DNS.

Il motore di copia lavora a lotti di pochi secondi e poi restituisce il controllo, riprendendo esattamente da dove si era fermato: copia dei file tramite una coda persistente, clonazione del database a pacchetti di righe. Un negozio di diversi gigabyte si clona senza errori, anche su hosting condiviso con un max_execution_time basso.

Creare uno staging

Vai su Parametri avanzati → Staging Pro e, nel pannello di creazione:

1. Inserisci un nome (solo minuscole, cifre e trattini, ad esempio v2). L’URL dello staging sarà tuo-negozio.com/staging-v2/.
2. Scegli le tue opzioni di protezione e copia (vedi sotto).
3. Fai clic su Crea. L’avanzamento è mostrato in tempo reale con una barra di avanzamento.

Al termine del processo, l’URL dello staging e, se applicabile, le credenziali htpasswd appaiono sulla riga dell’ambiente.

Opzioni di protezione e copia

• Proteggi con .htpasswd: aggiunge un’autenticazione HTTP (utente staging). La password può essere inserita o generata automaticamente, poi mostrata sul pannello.
• Disattiva le e-mail: blocca le e-mail in uscita dello staging (PS_MAIL_METHOD = 3). Nessun rischio di scrivere a un cliente reale.
• Disattiva i pagamenti: disattiva e sgancia dagli hook i moduli di pagamento noti sullo staging.
• Salta le statistiche: esclude dalla copia le tabelle grandi e non essenziali (connessioni, log, carrelli abbandonati…) per una copia molto più rapida.
• Senza dati clienti: crea vuote sullo staging le tabelle di clienti, indirizzi dei clienti, ordini, carrelli, messaggi, ospiti, newsletter e log GDPR. Gli indirizzi di fornitori, produttori e magazzini sono mantenuti, così come le tabelle di configurazione degli ordini (stati, modelli di messaggi, stati di reso, regole del carrello). Vedi la sezione dedicata più sotto.
• Symlink della cartella img/: crea un collegamento simbolico alle immagini invece di copiarle, per un enorme risparmio di spazio su disco.
• Modalità manutenzione: mette lo staging in manutenzione con il tuo IP di amministrazione in whitelist.

Il motore di copia a lotti

La creazione di uno staging concatena diverse fasi, ciascuna con budget di tempo e ripresa automatica: preparazione, copia dei file, clonazione del database, riscrittura degli URL, configurazione e protezione, e finalizzazione. La riscrittura degli URL copre shop_url, la configurazione (inclusi i valori serializzati e JSON, gestiti senza corruzione), oltre ai contenuti CMS, prodotti, categorie, marche, fornitori e negozi.

Refresh, multi-ambiente ed eliminazione

• Refresh: ricostruisce uno staging esistente dallo stato attuale della produzione (elimina e poi ricrea la cartella e il prefisso), con un clic.
• Multi-ambiente: crea tutti gli staging di cui hai bisogno (v2, hotfix, test di moduli…), ognuno indipendente.
• Eliminazione: elimina la cartella e le tabelle di un ambiente in modo budgetizzato, senza timeout.

Push in produzione

Una volta validati i test, il pulsante Push permette di riportare le tue modifiche in produzione, tabella per tabella:

1. Fai clic su Push sulla riga dell’ambiente: appare l’elenco delle tabelle, con il numero di righe di ciascuna.
2. Seleziona esattamente le tabelle da trasferire.
3. Conferma. Prima di ogni sostituzione, la tabella di produzione corrispondente viene salvata automaticamente tramite una rinomina con timestamp verso un prefisso dfbak{timestamp}_.

Gli URL vengono riscritti nel verso staging → produzione durante il trasferimento. Le tabelle critiche (shop_url, configuration, shop, sessioni e tabelle del modulo) sono protette e non possono mai essere inviate.

Rollback

Il pulsante Rollback ripristina la produzione dall’ultimo backup del push, con un clic. Il modulo rinomina le tabelle di backup dfbak…_ per riportarle al loro posto originale.

Protezioni e registro

• Tutte le azioni sono bloccate se il negozio attuale è esso stesso uno staging, per evitare operazioni a cascata.
• Un registro dettagliato è disponibile per ambiente tramite il pulsante Logs.
• Poiché un robots.txt in una sottocartella non viene rispettato dai motori, la vera protezione anti-indicizzazione si basa sull’header X-Robots-Tag e sul meta noindex; l’opzione .htpasswd resta la protezione più sicura.

Compatibilità e note tecniche

• PrestaShop 8.0 a 9.x, compatibile con hosting condiviso e multilingua.
• Controller di amministrazione legacy (nessun controller Symfony) per la compatibilità PS8/PS9.
• Endpoint AJAX del back office tramite il 4° argomento di getAdminLink(); rendering JSON tramite un metodo dedicato.
• Staging = sottocartella nella radice + prefisso di tabelle dfs{id}_ nello stesso database MySQL.
• Backup del push con timestamp sotto il prefisso dfbak{YmdHis}_, da eliminare dopo la validazione.

Staging senza dati clienti

L’opzione Senza dati clienti, disponibile dalla versione 1.1.0, crea lo staging senza alcun dato personale. Le tabelle interessate vengono create con la loro struttura esatta, ma restano vuote. È la scelta consigliata per affidare uno staging a un fornitore esterno, per un test di tema o di modulo che non tocca il checkout e per ridurre la superficie GDPR dei tuoi ambienti di test.

Cosa non viene copiato

• Clienti, gruppi di clienti, discussioni e messaggi dell’assistenza, sessioni clienti, ospiti e statistiche di connessione.
• Ordini e tutta la famiglia associata: dettagli, cronologia, fatture, pagamenti, corrieri, regole del carrello applicate, note di credito e resi.
• Carrelli, prodotti dei carrelli, liste dei desideri, messaggi, iscrizioni alla newsletter, log GDPR e log delle e-mail.
• Indirizzi dei clienti: la tabella address viene copiata con un filtro, vengono escluse solo le righe collegate a un cliente.

Cosa viene mantenuto

• Indirizzi di fornitori, produttori, magazzini e punti vendita.
• Tabelle di configurazione degli ordini: stati degli ordini e le loro traduzioni, modelli di messaggi, stati di reso, tipi di note di credito.
• Regole del carrello, buoni sconto, corrieri, imposte e l’intero catalogo.
• Dipendenti del back office: accedi allo staging con le tue credenziali abituali.

Autenticazione HTTP e hosting cPanel / LiteSpeed

Dalla versione 1.0.1, il file .htpasswd viene generato nel formato APR1-MD5 (quello del comando htpasswd -m), letto da Apache, LiteSpeed e nginx. La versione 1.0.0 usava bcrypt, che LiteSpeed (molto diffuso dietro cPanel) non sa leggere: lo staging rispondeva quindi 404 su tutte le pagine.

Il blocco di protezione aggiunge inoltre una pagina di errore 401 inline. Su cPanel, l’errore 401 viene reindirizzato globalmente a /401.shtml, una pagina che in PrestaShop non esiste: la sottorichiesta finisce nel dispatcher della produzione e restituisce la sua pagina 404, così il browser non mostra mai la finestra di login. La pagina inline aggira questo reindirizzamento.

Infine, la riga ErrorDocument 404 del .htaccess copiato viene riscritta verso la sottocartella di staging: un errore sullo staging mostra la pagina 404 dello staging, non quella della produzione.

Autoverifica alla creazione

Al termine della configurazione, il modulo invia una richiesta HEAD al robots.txt dello staging, con le credenziali se la protezione è attiva, poi senza credenziali per verificare che il server risponda 401. Il risultato viene registrato nei log dell’ambiente:

• 200 con credenziali e 401 senza: tutto in ordine.
• Il server rifiuta il blocco di autenticazione: il modulo rimuove il blocco e il .htpasswd, disattiva l’opzione e mostra «Ready with warning» sulla riga dell’ambiente. Lo staging resta quindi accessibile senza password; attiva la modalità manutenzione.
• Codice 0: il server non riesce a chiamare se stesso (richieste in uscita bloccate). Apri manualmente l’URL dello staging.

FAQ e risoluzione dei problemi

Il modulo funziona su un hosting condiviso? Sì. Il motore di copia a lotti con ripresa automatica evita qualsiasi timeout, qualunque sia il max_execution_time del server.

La creazione si è interrotta, cosa faccio? Riapri il pannello di Staging Pro: l’ambiente riprende automaticamente la copia da dove si era fermato.

Lo staging può inviare e-mail ai miei clienti? No se l’opzione «Disattiva le e-mail» è attiva (consigliato): le e-mail in uscita sono bloccate sullo staging.

Dopo un push, come lo annullo? Usa il pulsante Rollback, che ripristina l’ultimo backup automatico. Poi ricordati di eliminare le tabelle dfbak* obsolete.

Posso creare più staging contemporaneamente? Sì, il numero di ambienti è illimitato e ognuno è totalmente indipendente.

Lo staging risponde 404 ovunque, o la finestra di login non appare? È il sintomo corretto nella 1.0.1 sugli hosting cPanel / LiteSpeed. Aggiorna il modulo e lancia un Refresh dell’ambiente; consulta la sezione «Autenticazione HTTP e hosting cPanel / LiteSpeed» qui sopra.

Posso creare uno staging senza i dati dei miei clienti? Sì, seleziona «Senza dati clienti» alla creazione. Vedi la sezione «Staging senza dati clienti» qui sopra.

Cronologia delle versioni

1.1.0 (4 settembre 2026)

• Nuova opzione «Senza dati clienti»: clienti, indirizzi dei clienti, ordini, carrelli, messaggi, ospiti, newsletter e log GDPR creati vuoti sullo staging.
• Gli indirizzi di fornitori, produttori e magazzini sono mantenuti, così come le tabelle di configurazione degli ordini.
• Protezione del push: queste tabelle vengono rimosse dall’elenco e rifiutate lato server su uno staging creato senza dati clienti.

1.0.1 (3 settembre 2026)

• Protezione htpasswd: hash generato in APR1-MD5, compatibile con Apache e LiteSpeed (bcrypt veniva rifiutato su alcuni hosting cPanel, rendendo lo staging irraggiungibile).
• Finestra di login HTTP: pagina 401 inline, per gli hosting che reindirizzano gli errori 401 a una pagina inesistente.
• Riga ErrorDocument del .htaccess riscritta verso la sottocartella di staging.
• Autoverifica al termine della creazione: controllo HTTP dello staging, rimozione automatica della protezione se il server la rifiuta e avviso nella dashboard.

1.0.0 (11 giugno 2026)

Prima versione pubblica.