Eliminare gli ordini di test: ripulire PrestaShop prima della messa online

Rivisto e aggiornato a giugno 2026 — verificati su PrestaShop 1.7, 8 e 9 l'assenza di un'azione nativa per eliminare gli ordini e il reset del contatore delle fatture.

Il giorno prima del lancio, il database del tuo PrestaShop è una scena del crimine che hai creato tu stesso. Hai inserito ordini per testare i prezzi dei corrieri, hai fatto passare due volte una carta dal gateway di pagamento per sicurezza, hai creato "asdf asdf" per controllare il modulo dell'indirizzo e hai attivato ogni stato ordine per vedere partire le email. Tutto ha funzionato — ed è proprio questo il problema. Ognuno di quegli ordini di test è ormai finito nelle statistiche, nella sequenza delle fatture e nell'elenco clienti, e la prima mattina di vendita reale ti darà silenziosamente un'immagine falsa dell'andamento del negozio. Questa guida riguarda un'attività precisa: rimuovere in modo pulito gli ordini di test prima della messa online, su un negozio che non ha ancora ricevuto ordini reali — perché, una volta che esistono ordini e fatture veri, PrestaShop rende volutamente difficile eliminarli, per ragioni legali e contabili.

Il perimetro è volutamente ristretto. Pulire carrelli, log e tabelle delle connessioni per migliorare le prestazioni nel tempo è un'altra routine — la differenza tra "lancio la prossima settimana" e "il mio database cresce da due anni" — e le teniamo separate, così elimini solo ciò che serve davvero prima del lancio.

Perché un ordine di test dimenticato costa più di quanto sembri

Eliminare un ordine sembra una questione estetica. Non lo è. In PrestaShop un ordine non è una sola riga — è un piccolo grafo di righe distribuite su una dozzina di tabelle, alcune delle quali alimentano report e contatori su cui farai affidamento dal primo giorno. Lasciale lì ed ecco cosa si rompe, concretamente:

• Il tuo primo dato di fatturato è sbagliato, e non puoi accorgertene. La dashboard e le pagine Statistiche sommano ps_orders (e ps_order_detail) senza sapere quali righe erano semplici test dei prezzi dei corrieri. Il fatturato del primo giorno, il valore medio dell'ordine e il tasso di conversione risultano gonfiati da ordini mai avvenuti, quindi proprio nel momento in cui ti serve un segnale pulito — "il nuovo negozio sta davvero vendendo?" — i dati sono al massimo della sporcizia.
• La tua prima fattura reale ha il numero #38. In PrestaShop i numeri di fattura vengono assegnati da un contatore progressivo, non dall'ordine. Quaranta ordini di test che hanno generato fatture consumano quaranta numeri, quindi la prima fattura vera del tuo commercialista parte con un numero a metà della trentina, non sequenziale, con trentasette predecessori invisibili. È esattamente il tipo di vuoto che un controllo fiscale ti chiede di spiegare.
• La lista clienti è cosparsa di fantasmi. "Test User", "asdf asdf" e i tuoi tre account usa e getta restano in ps_customer accanto alle persone reali. Ogni segmento, esportazione e statistica sul "numero di clienti" li conta. Esporta quell'elenco in uno strumento email e gli indirizzi di test — se ne hai usati di reali — ricevono comunicazioni di marketing.
• Lo stock si è mosso per vendite mai avvenute. Se gli ordini di test sono stati effettuati su prodotti reali con la gestione dello stock attiva, ognuno ha scritto una riga in ps_stock_mvt e ha decrementato la quantità. Elimina male l'ordine e il movimento di magazzino resta, così l'inventario del giorno del lancio è silenziosamente errato. (Riconciliarlo è un lavoro sui dati di stock a sé stante — vedi gestione dell'inventario quando i fogli di calcolo non bastano più.)

Quindi? Un ordine di test che dimentichi di eliminare non si limita a sporcare una schermata — corrompe le tre cose che un lancio dovrebbe darti: un dato di fatturato onesto, una sequenza di fatture pulita e una lista clienti affidabile. Rimuoverli richiede quindici minuti e ti restituisce un database che puoi davvero leggere.

Non esiste un pulsante pulito "elimina ordine" — ed è importante

Ecco la prima sorpresa: PrestaShop nativo (1.7, 8, 9) non offre una normale azione di back office per eliminare un ordine. Gli ordini sono trattati come documenti finanziari e devono essere conservati per integrità legale e contabile, quindi i menu delle azioni massive e delle righe che cercheresti di usare semplicemente non offrono un'opzione "Elimina" come accade per gli elenchi prodotti o clienti. È una scelta progettuale, non una dimenticanza.

Proprio per questo, l'unico modo sicuro per rimuovere ordini di test è farlo prima che esistano ordini reali. Le opzioni realistiche sono:

• Ripristinare un backup pulito pre-lancio. Il reset più semplice e sicuro: prendi lo snapshot precedente all'inizio dei test e torna a quello. Tutto ciò che segue presuppone che tu preferisca non farlo, ma questa è l'opzione con rischio zero di righe orfane.
• Lavorare su un database di staging. Testa su una copia, poi distribuisci in produzione un database pulito che non ha mai visto un ordine di test.
• Usare un modulo o uno script dedicato alla pulizia degli ordini. Rimuovere correttamente un ordine significa attraversare l'intero grafo delle righe correlate: per questo deve occuparsene uno strumento testato sulla versione, non un'azione amministrativa cliccata a mano. Eseguilo solo su un negozio con zero ordini reali.

E anche quando un ordine viene rimosso (da un modulo o dalla logica oggetto Order::delete() propria di PrestaShop), non pulisce mai tutto ciò che ruota attorno all'ordine a un livello di distanza:

• Il cliente (ps_customer) e i suoi indirizzi (ps_address) — rimuovere un ordine non elimina mai la persona che lo ha effettuato. I clienti fittizi sopravvivono.
• Il carrello di origine (ps_cart, ps_cart_product) — il carrello diventato ordine resta lì come carrello "abbandonato".
• La riga della fattura (ps_order_invoice) e il contatore dei numeri di fattura — rimuovere l'ordine non riporta indietro il numero consumato.
• Qualsiasi movimento di magazzino (ps_stock_mvt) già scritto su prodotti reali.

Quindi la rimozione dell'ordine è solo il primo passaggio, non tutto il lavoro. Lo schema che ti lascia davvero pulito è: rimuovere gli ordini su un negozio pre-lancio, poi eliminare i relativi clienti e carrelli, poi impostare esplicitamente il prossimo numero di fattura. Qui sotto trovi come gestire ogni parte in modo deterministico.

La pulizia pre-lancio, passo dopo passo

1. Esegui prima il backup del database — non è negoziabile. Fai un dump reale del database: lo strumento di backup del tuo hosting, phpMyAdmin o Adminer, oppure un mysqldump se hai accesso shell. (Nota: SQL Manager in Parametri avanzati serve per eseguire query salvate sui tuoi dati, non per fare un backup completo — non affidarti a quello per questa operazione.) La rimozione degli ordini è distruttiva e non esiste annullamento. Se qualcosa qui sotto ti sorprende, ripristini e riprovi.
2. Crea un elenco definitivo degli ID degli ordini di test. In Ordini → Ordini, ordina per data e identifica ogni ordine precedente al lancio. Annota l'intervallo degli ID — quasi sempre sono un blocco contiguo all'inizio (da 1 in poi). La trappola qui è il lancio graduale: se hai ricevuto veri ordini iniziali, quegli ID sono mescolati ai test. Elenca esplicitamente quelli reali, così non elimini mai un cliente pagante.
3. Rimuovi gli ordini. Poiché PrestaShop nativo non ha un'azione di back office per eliminare gli ordini, questo è il passaggio che richiede un modulo dedicato alla pulizia o un piccolo script che chiami Order::delete() su ogni ID di test — oppure, più semplicemente, il ripristino del backup pulito pre-lancio. Fallo solo su un negozio con zero ordini reali.
4. Elimina i clienti di test. Vai in Clienti → Clienti, trova gli account palesemente fittizi ed eliminali — questo rimuove anche i loro indirizzi. Anche qui, fai attenzione agli acquirenti del lancio graduale che vuoi conservare.
5. Imposta esplicitamente a 1 il prossimo numero di fattura. Vai in Ordini → Fatture e in Opzioni fattura imposta Prossimo numero di fattura disponibile a 1 — fallo solo su un negozio in cui non è mai stata emessa alcuna fattura reale e verifica che non sia già iniziata una sequenza legale di fatturazione. (Questo imposta direttamente il numero iniziale; non aspettarti che impostarlo a 0 faccia "partire automaticamente da 1".) Fai lo stesso per la numerazione delle bolle di consegna se hai testato le consegne (Ordini → Bolle di consegna). È il passaggio che quasi tutti dimenticano, ed è quello che il tuo commercialista nota — ma se esistono già fatture reali, lascia stare la sequenza e consulta invece i tuoi requisiti contabili.
6. Svuota la cache. Parametri avanzati → Prestazioni → Svuota cache. Contatori e viste elenco vengono memorizzati in cache; senza questo passaggio l'amministrazione può ancora mostrare totali obsoleti.
7. Verifica sui numeri, non sulla memoria. Apri Ordini → Ordini (dovrebbe essere vuoto o contenere solo ordini reali del lancio graduale), Clienti e la dashboard. Se il fatturato non è zero (o il valore reale del tuo lancio graduale), qualcosa non è stato eliminato — torna al backup e all'elenco prima di lanciare con dati sporchi.

Quando hai decine di ordini di test: la strada SQL

Cliccare cinquanta ordini uno alla volta è noioso e soggetto a errori. Se ti muovi con sicurezza in Parametri avanzati → Database → Gestore SQL (che va bene per query di indagine in sola lettura), puoi almeno delimitare con precisione i dati di test — ma, come spiega la sezione successiva, la rimozione vera e propria dovrebbe passare da codice testato, non da un DELETE scritto a mano. Il motivo è lo schema di PrestaShop: molte tabelle non hanno chiavi esterne con eliminazione a cascata, quindi cancellare prima il record padre lascia orfani i figli invece di rimuoverli, e il set completo delle tabelle correlate è facile da sottostimare.

Per prima cosa, trova gli ordini di test in modo da lavorare su ID reali, non su supposizioni. Per esempio, tutto ciò che è stato inserito prima della data di lancio:

SELECT id_order, reference, total_paid, date_add FROM ps_orders WHERE date_add < '2026-06-13 00:00:00' ORDER BY id_order;

È nettamente preferibile lasciare che la logica Order::delete() propria di PrestaShop gestisca le righe figlie (eseguila da un piccolo script sui tuoi ID di test) invece di scrivere la cancellazione a mano. Un vero ordine PrestaShop tocca molte più tabelle della mezza dozzina ovvia — dettagli e storico ordine, ma anche corrieri dell'ordine, messaggi, resi e note, personalizzazioni, fatture, imposte e righe ps_order_payment associate per riferimento ordine anziché tramite un ordinato collegamento figlio id_order — più tutte le tabelle appartenenti ai moduli aggiunte dalla tua installazione. È proprio per questo che un elenco DELETE scritto a mano è pericoloso: ogni tabella che dimentichi diventa un orfano invisibile.

Perciò questa guida volutamente non ti consegna una ricetta SQL parziale del tipo "elimina queste N tabelle in quest'ordine" — quella ricetta sarebbe incompleta per quasi qualsiasi negozio reale. Usa la logica oggetto (Order::delete()) o uno script di pulizia testato sulla versione che enumeri ogni tabella correlata, incluse le righe di pagamento che deve cercare per riferimento. Poi ripulisci separatamente i satelliti — clienti, carrelli, contatore fatture.

Quindi? Saltare una tabella correlata non è pignoleria — se sbagli, lasci righe orfane invisibili che continuano a sporcare i report pur sembrando eliminate nell'amministrazione. È esattamente la modalità di errore che tutta questa operazione deve prevenire, ed è il motivo per cui ci affidiamo a codice testato invece che a un blocco SQL copiato e incollato.

Una precisazione onesta: troncare le tabelle degli ordini (TRUNCATE ps_orders e simili) è l'opzione brutale che vedrai suggerita online. È veloce e reimposta gli ID auto-incrementali a 1 — cosa allettante per un lancio — ma aggira ogni salvaguardia, non tocca le tabelle satellite e può distruggere senza problemi un ordine del lancio graduale. Considerala solo su un negozio con zero dati reali e solo con un backup di cui hai verificato il ripristino.

Ripulire i dati demo mentre ci sei

Gli ordini di test sono il blocco da risolvere prima del lancio, ma se hai installato PrestaShop con dati demo, il catalogo di esempio è un altro problema pre-lancio — e conviene gestirlo nella stessa sessione. Installato con dati demo, PrestaShop può includere prodotti, categorie, fornitori, marchi e pagine CMS di esempio (i segnaposto "Delivery", "Legal Notice", "About us") — quali siano esattamente varia in base a versione, distribuzione e lingua. Lasciarli lì comporta due rischi: un prodotto reale che finisce per sbaglio in una categoria demo e Google che indicizza una pagina "Termini e condizioni" ancora piena di testo segnaposto Lorem ipsum.

Rimuovi o riscrivi, in Catalogo e Design → Pagine: prodotti e categorie demo, e le pagine CMS segnaposto (sostituiscile con i tuoi testi legali reali, non limitarti a nasconderle). Fallo dal back office o con una procedura di importazione controllata — non eliminare manualmente file sotto /img, che contiene le immagini reali di prodotti, categorie, marchi, fornitori, tema e sistema, non solo quelle demo. Rimuovere i prodotti demo dal back office pulisce i relativi record immagine nel modo sicuro; se poi vuoi recuperare spazio su disco, rigenera o elimina le immagini inutilizzate solo con un backup pronto. Se parti da un grande catalogo demo e importi quello reale, farlo in modo pulito via CSV è un'attività a parte — vedi importazione ed esportazione prodotti in PrestaShop.

Prevenzione: evita di creare lo stesso caos la prossima volta

Testerai di nuovo — a ogni cambio tema, aggiornamento di un modulo di pagamento e upgrade di PrestaShop. L'obiettivo è fare in modo che i test futuri non lascino residui nei dati live:

• Testa su una copia di staging, non sul negozio live. Un'installazione duplicata in cui ogni ordine di test, rimborso e cambio di stato avviene di lato. È il vantaggio più importante: la tua ps_orders live contiene solo vendite reali, quindi non c'è nulla da pulire.
• Usa la modalità sandbox per i pagamenti. Stripe, PayPal e la maggior parte dei gateway offrono una chiave di test/sandbox che elabora transazioni fittizie senza addebiti reali. Testa la procedura di pagamento senza mai toccare una carta live — e ricordati di riportare ogni gateway in modalità live prima del lancio (una chiave sandbox dimenticata è il bug di lancio speculare).
• Contrassegna il test live inevitabile. Se devi testare in produzione, usa un marcatore riconoscibile — un cliente chiamato ZZ-TEST, un pattern email dedicato, una nota nell'ordine — così un unico filtro ordinabile fa emergere ogni riga di test da eliminare. Il senso degli ordini di test chiaramente marcati si collega a come gestisci in generale gli stati ordine; se ti ritrovi a testare ripetutamente le email di stato, l'automazione di quelle transizioni è trattata in personalizzazione e automazione dei flussi degli stati ordine.

Domande frequenti

Come elimino un ordine di test in PrestaShop?

PrestaShop nativo (1.7, 8, 9) non ha un'azione di back office "Elimina ordine" — gli ordini sono trattati come documenti finanziari e conservati per scelta progettuale. L'unico modo sicuro per rimuovere ordini di test è farlo prima che esistano ordini reali: ripristinare un backup pulito pre-lancio, distribuire un database di staging che non abbia mai visto un ordine di test, oppure eseguire un modulo/script di pulizia testato sulla versione che chiami Order::delete() sui tuoi ID di test. Esegui prima il backup del database; la rimozione degli ordini è distruttiva e non c'è annullamento.

Perché la mia prima fattura reale parte dal numero 38 invece che da 1?

I numeri di fattura provengono da un contatore progressivo, non dall'ordine, quindi ogni ordine di test che ha generato una fattura ha consumato un numero. Dopo aver eliminato i test, vai in Ordini → Fatture → Opzioni fattura e imposta Prossimo numero di fattura disponibile a 1 — ma solo su un negozio in cui non è mai stata emessa alcuna fattura reale. Impostarlo a 0 non fa "partire automaticamente da 1"; imposta direttamente il numero iniziale. Se esistono già fatture reali, lascia stare la sequenza.

Eliminare un ordine rimuove anche cliente e carrello?

No. Rimuovere un ordine non elimina mai la persona che lo ha effettuato (ps_customer) né i suoi indirizzi (ps_address), e il carrello diventato ordine resta lì come carrello "abbandonato" (ps_cart). Inoltre non riporta indietro il contatore dei numeri di fattura né eventuali movimenti di magazzino già scritti. Quindi la rimozione dell'ordine è il primo passaggio, non tutto il lavoro — poi devi eliminare separatamente clienti e carrelli di test e reimpostare il contatore.

Posso semplicemente eseguire una query DELETE o troncare le tabelle degli ordini?

Meglio di no. Un ordine reale tocca molte più tabelle della mezza dozzina ovvia — dettagli e storico ordine, corrieri, messaggi, resi, note, personalizzazioni, fatture, imposte e righe ps_order_payment collegate per riferimento ordine anziché per id_order — più le tabelle appartenenti ai moduli. Un DELETE scritto a mano che ne dimentica una lascia righe orfane invisibili che continuano a sporcare i report pur sembrando eliminate. TRUNCATE è più veloce e reimposta gli ID a 1, ma aggira ogni salvaguardia e distruggerà un ordine del lancio graduale. Usa invece Order::delete() o uno script di pulizia testato. Una SELECT in sola lettura per trovare prima gli ID di test va bene.

Come evito di creare di nuovo questo problema?

Testa su una copia di staging, non sul negozio live — così la tua ps_orders live contiene sempre e solo vendite reali. Usa la modalità sandbox/test di ogni gateway per provare i pagamenti (e ricordati di riportare ogni gateway in live prima del lancio). Se devi testare in produzione, contrassegna gli ordini con un marcatore riconoscibile (un nome cliente ZZ-TEST o un pattern email dedicato), così un unico filtro ordinabile fa emergere ogni riga di test da eliminare.

Dove si colloca nel quadro più ampio

Eliminare gli ordini di test è un passaggio una tantum prima del lancio. Le abitudini che mantengono pulito e affidabile il database degli ordini dopo la messa online sono una disciplina separata e continua — correggere l'ordine reale occasionale uscito male con la modifica degli ordini, rimandare una conferma a un cliente che l'ha persa tramite il reinvio delle conferme d'ordine, estrarre dati puliti per il commercialista con le esportazioni CSV per ordini e fatture, e la routine quotidiana che mantiene tutto scorrevole in flussi di gestione ordini che ti fanno risparmiare ore.

Il principio per il giorno del lancio è semplice: gli unici ordini nel database dovrebbero essere quelli effettuati davvero da un cliente. Tira fuori gli ordini di test — nell'ordine giusto, con il contatore fatture reimpostato e il backup al sicuro — e il primo dato di fatturato del negozio ti dirà la verità. Da quel momento, ogni report pulito che leggerai sarà una piccola ricompensa per i quindici minuti spesi ora. Se un database ordinato e statistiche accurate contano nel modo in cui gestisci il negozio, è proprio questo il tipo di affidabilità dietro le quinte che i nostri moduli PrestaShop sono pensati per proteggere.