Checklist di migrazione e aggiornamento a PrestaShop 9

Come procederemmo

Per un negozio PrestaShop 1.7 o 8 adatto, con moduli mantenuti e modifiche limitate, proveremmo prima ad aggiornare una copia di staging. Per un negozio 1.6, un tema non supportato o numerose modifiche personalizzate, di solito partiremmo valutando una nuova installazione PrestaShop 9 con migrazione dei dati mappata. Una ricostruzione è un percorso da valutare, non un obbligo automatico per ogni negozio personalizzato: spesso una singola integrazione che non funziona può essere adattata o sostituita da sola, come mostra l'esempio qui sotto.

Il PrestaShop Upgrade Service inizia con una verifica gratuita di versione, PHP, hosting, tema e moduli, prevede un preventivo fisso scritto prima dei lavori e viene svolto in staging mentre il negozio live continua a ricevere ordini; il passaggio dalla 1.6 è una migrazione con un preventivo più alto.

Prima di approvare uno dei due percorsi, chiedi i risultati della verifica di compatibilità, l'ambito dei dati, i controlli di accettazione e il piano di ripristino.

Scegli una destinazione supportata e un percorso adatto al tuo negozio

Una migrazione a una nuova versione principale di PrestaShop può cambiare PHP, componenti del framework, pagine amministrative, temi e punti di estensione. Censisci la tua installazione specifica prima di scegliere un aggiornamento o una ricostruzione. Mantieni una checklist scritta di accettazione e un punto decisionale per il ripristino.

Al 26 ottobre 2026, PrestaShop 9.2 è disponibile. Scegli una destinazione con patch supportata dai fornitori di pagamenti, spedizioni, tema e integrazioni. Un negozio che si carica ancora può comunque essere fuori dalla manutenzione software.

La manutenzione ufficiale di PrestaShop 1.6 è terminata il 30 giugno 2019; il successivo lavoro volontario era un'iniziativa separata. Consulta l'avviso di manutenzione e la spiegazione della manutenzione volontaria. La manutenzione regolare di 1.7 è terminata con l'uscita di 9.0.

L'updater della prima fase da 1.6 non è mantenuto. Provalo in isolamento e conserva un'istantanea a ogni fase. Una ricostruzione pulita è un'opzione separata, non la prova che l'aggiornamento a fasi sia tecnicamente impossibile. Controlla i percorsi ufficiali di Update Assistant.

Qualunque percorso tu valuti, sono checkout, evasione degli ordini e recupero in staging a stabilire se è praticabile. Una copia che si avvia e mostra il catalogo non ha ancora superato la valutazione.

La preparazione riduce i rischi, ma non può escludere difetti o guasti dell'infrastruttura. Non promettere una durata fissa dell'aggiornamento, un tempo di inattività preciso o un recupero del posizionamento basandoti sul numero di moduli o sulle dimensioni del catalogo, e non scegliere un percorso in base a una promessa di compatibilità universale.

Esempio: conserva il negozio, sostituisci l'ostacolo

Supponiamo che un negozio PrestaShop 8 abbia un tema mantenuto e strumenti di catalogo funzionanti, ma che il collegamento su misura al corriere non funzioni sulla destinazione proposta. Chiedi allo sviluppatore di isolare quel collegamento, definirne i requisiti relativi a dati ed etichette e provare un adattamento o una sostituzione in staging. Questo problema da solo non giustifica la ricostruzione dell'intero catalogo. Viceversa, per un negozio 1.6 con un tema non supportato, modifiche dirette al core e un collegamento alle scorte non documentato, serve un confronto dei costi dei due percorsi prima di iniziare.

Richiedi per iscritto il percorso scelto. Per un aggiornamento si tratta della sequenza a fasi che indica sorgente, updater, destinazione e ambiente PHP di ogni fase, oltre al punto di controllo da cui ogni fase può essere ripristinata (vedi la sezione sulla compatibilità PHP qui sotto). Per una nuova installazione si tratta della mappa dei dati e della procedura di trasferimento finale (vedi la sezione sul negozio pulito qui sotto).

Identifica versione in esecuzione e requisiti del server

Leggi la versione del negozio in esecuzione nel piè di pagina del back office o in Parametri avanzati > Informazioni. Verifica di essere in produzione anziché in una vecchia copia di staging. La versione di un modulo non è quella del negozio.

La versione legacy 1.6 definisce comunemente _PS_VERSION_ in config/settings.inc.php. PrestaShop 1.7/8 espone la versione applicativa in app/AppKernel.php. In PrestaShop 9.1, quella classe delega VERSION a src/Core/Version.php. Considera un file copiato come un indizio, non come prova di una distribuzione completa.

Nel codice che ha già inizializzato il negozio, usa _PS_VERSION_ e version_compare() per i controlli di compatibilità. Registra versione PHP web e CLI, estensioni, limiti, versione database, tema attivo e versioni dei moduli.

php -v
php -m
php -i | rg 'memory_limit|max_execution_time'
# Run through the actual database connection:
# SELECT VERSION();

mysql --version indica il binario del client, non necessariamente il server collegato. SELECT VERSION() identifica il server raggiunto da quella connessione. Anche PHP CLI può differire dal pool PHP-FPM che serve il negozio.

PrestaShop 9 documenta una raccomandazione di memoria di 512M per script. Prevedi margine aggiuntivo misurato per aggiornamenti grandi e attività PDF/importazione. Controlla CURL, DOM, Fileinfo, GD, Iconv, Intl, JSON, Mbstring, OpenSSL, PDO/MySQL, SimpleXML e Zip, oltre alle impostazioni richieste dell'ambiente di esecuzione. Consulta i requisiti di sistema.

Le versioni di produzione distribuite in pacchetto contengono le dipendenze. Composer e gli strumenti di compilazione frontend servono nei flussi di compilazione dai sorgenti, non per ogni aggiornamento da pacchetto.

Controlla separatamente compatibilità del database e manutenzione del fornitore. MySQL 8.0 è entrato in Sustaining Support ad aprile 2026; non considerarlo automaticamente la destinazione per nuove installazioni. Scegli una versione mantenuta compatibile con il negozio esatto e l'ambiente hosting e verificane il comportamento SQL. Consulta gli avvisi sul ciclo di vita MySQL.

Pianifica la compatibilità PHP a ogni fase

Quella che segue è una mappa di compatibilità, non una raccomandazione a esporre pubblicamente vecchie versioni PHP:

Usa la matrice legacy, la matrice PrestaShop 8 e i requisiti 9.2 per sorgente/destinazione esatte.

PHP 7.4 ha raggiunto la fine del ciclo di vita il 28 novembre 2022; il supporto di sicurezza PHP 8.1 è terminato il 31 dicembre 2025. Controlla i rami PHP supportati e l'elenco di fine ciclo di vita. La compatibilità non rende un vecchio ambiente adatto a una nuova installazione pubblica.

1. Registra i requisiti PHP del negozio sorgente, dell'updater, delle fasi di aggiornamento e della destinazione, incluso l'ambiente che esegue importazioni e altre attività pianificate.
2. Scegli un percorso diretto da 1.7 a 9 solo quando la versione esatta di Assistant e la destinazione superano i controlli preliminari e hai provato ogni fase con PHP compatibile. Sorgente e destinazione non hanno una sovrapposizione PHP generalmente supportata; non aggirare i requisiti e non presumere un cambio automatico dell'ambiente di esecuzione.
3. Se quel percorso non completa il passaggio in modo affidabile, scegli un percorso intermedio verificato o una migrazione pulita.
4. Una fase facoltativa da 1.7.8 a 8.2 può essere eseguita con PHP 7.4; 8.2 può poi funzionare con PHP 8.1 per una transizione verificata verso 9. Mantieni questi ambienti intermedi fuori supporto isolati e temporanei.
5. Dopo aver raggiunto la destinazione, passa alla versione PHP mantenuta scelta e supportata dall'intero ambiente, quindi ripeti i test.

Non passare un'installazione 1.7 live a una versione PHP 8 qualsiasi solo perché l'host la offre, o per scoprire se la vecchia installazione si avvia: verificalo in staging. Mantieni allineati web, CLI e attività pianificate. Ripristinare soltanto la vecchia versione PHP ha senso solo se anche i file applicativi e il database ripristinati sono compatibili.

Analizza moduli, codice personalizzato e integrazioni

Crea un inventario da Gestione moduli e dal filesystem distribuito. Registra nome del modulo, versione, fornitore, scopo, associazioni ai negozi, configurazione, titolarità dei dati, attività pianificate ed endpoint esterni. Per ogni elemento scegli aggiornamento compatibile, sostituzione, rimozione o lavoro esplicito di migrazione.

Dai priorità a pagamento, checkout, corrieri, imposte, fatturazione, ERP/PIM, scorte, feed ed email. Un catalogo che si carica non dimostra che puoi accettare ed evadere ordini.

• Leggi gli intervalli PrestaShop e PHP dichiarati da ogni modulo e i suoi vincoli di dipendenza. Chiedi ai fornitori di temi e moduli di confermare il supporto per la destinazione e la versione PHP esatte, poi verifica quanto dichiarato con la tua configurazione.
• Esamina override personalizzati, template copiati, controller su misura, endpoint cron, client API, URL di callback e percorsi amministrativi scritti nel codice. Includi le modifiche apportate direttamente ai file del core o dei moduli.
• Controlla API rimosse e traduzioni rispetto alla destinazione esatta, poi riproduci eventuali errori.
• Usa link/route generati per il back office invece di concatenare nomi di cartelle e token.
• Verifica chiavi Webservice e client/ambiti delle nuove Admin API come integrazioni separate.
• Indica per ogni integrazione un responsabile in grado di fornire credenziali sandbox, casi di test e supporto al lancio.

PrestaShop 8 usa Symfony 4.4; 9 usa Symfony 6.4. Le pagine amministrative moderne usano Twig e Symfony, mentre i controller legacy mantengono percorsi di compatibilità. Non puoi presumere che il ciclo di rendering o l'override di template di un vecchio controller controlli una pagina migrata.

Tools::displayPrice() è rimosso in 9. Usa formatPrice($amount, $currencyIsoCode) del locale corrente nel contesto appropriato. Rivedi singolarmente vecchie chiamate di traduzione amministrativa e metodi legacy del ciclo di vita invece di imporre una ricetta universale di assegnazione nel costruttore/alle proprietà.

Preferisci hook supportati, sottoscrittori di eventi e decorazione dei servizi Symfony dove adatto. Gli override legacy delle classi esistono ancora per le classi pertinenti ma possono entrare in conflitto e richiedono controlli delle firme. Analizza parametri degli hook, esecuzione e markup del front office con il tema scelto. Consulta la guida alla struttura del codice.

Aggiorna i moduli in staging in un ordine controllato. Esegui il backup dei dati prima di disinstallare o reimpostare qualsiasi cosa. Disattiva tramite Gestione moduli o l'azione supportata prestashop:module disable con il contesto del negozio previsto. Aggiornare solo module.active non gestisce correttamente le associazioni ai negozi.

Cosa chiedere al tuo sviluppatore o alla tua agenzia

• Quali moduli essenziali hanno una versione compatibile testata e quali dipendono da sviluppi non ancora preventivati o da una nuova licenza?
• Quali modifiche esistono soltanto nei file distribuiti, anziché nel pacchetto del fornitore o nel repository dei sorgenti?
• Chi proverà pagamenti, trasferimenti delle scorte, etichette ed esportazioni contabili con i rispettivi fornitori?
• Quale ambiente di esecuzione serve le richieste del browser e quale esegue importazioni e altre attività pianificate?
• Quali prove dimostreranno il completamento e chi decide se un controllo fallito blocca il lancio?

Conserva le risposte insieme all'inventario. Segna un fornitore sconosciuto o un'integrazione non documentata come dipendenza irrisolta, indicando chi deve occuparsene.

Se usi i nostri moduli, Module Updates & Remote Assist mostra le versioni installate e gli aggiornamenti disponibili per la tua licenza e ti permette di scegliere installazioni e aggiornamenti nel back office. Non sostituisce il backup completo e corrispondente del negozio né la prova di ripristino descritti qui sotto.

Crea backup corrispondenti e prova in staging

Prima di cambiare versioni, schema, moduli o temi, esegui il backup dell'intero negozio e del database corrispondente e annota come tornare all'installazione originale. Includi file nascosti, media caricati, moduli, dati dei moduli, personalizzazioni del tema e configurazione. Salva la configurazione del server web e di PHP-FPM, le impostazioni SMTP, le credenziali di pagamento, gli URL dei webhook, le attività pianificate e le regole CDN in un registro operativo protetto.

Questo esempio presuppone un percorso di accesso MySQL protetto chiamato shop-backup e una cartella di backup ad accesso limitato già esistente. Scegli nome database e percorsi reali prima dell'uso.

mysqldump --login-path=shop-backup --single-transaction --quick prestashop > /srv/backups/prestashop-before-update.sql
tar -C /var/www -czf /srv/backups/prestashop-before-update-files.tar.gz html

Controlla stato di uscita dei comandi, spazio disponibile e integrità degli archivi. Un dump transazionale dipende da tabelle transazionali e dall'assenza di modifiche allo schema in conflitto. Coordina un'istantanea di file/database e usa un blocco delle scritture appropriato dove necessario. Non inserire password negli argomenti dei comandi o in archivi pubblici.

In Docker, includi i mount/volumi persistenti effettivi e i dati del database o un dump logico. Registra versioni di immagini/ambiente e proprietà numerica. Copiare soltanto l'immagine del container non conserva ordini live o file caricati.

1. Conserva un backup esterno al server con credenziali separate.
2. Prepara la destinazione isolata prima che si avvii l'applicazione copiata o qualsiasi attività pianificata: database e dominio propri e accesso limitato. Disattiva pagamenti reali, email in uscita ai clienti, webhook live e scritture esterne pianificate, oppure indirizzali verso connessioni sandbox e una casella di posta di test.
3. Ripristina lì file e database. Verifica che la copia usi davvero il database e le destinazioni di staging, non soltanto un dominio diverso.
4. Verifica catalogo, conteggi degli ordini, immagini, accessi dei clienti e fatture rappresentative.
5. Esegui l'aggiornamento o la migrazione pianificati, comprese tutte le transizioni PHP. Conserva gli errori e registra le correzioni.
6. Ripeti partendo da una nuova istantanea corrispondente, così che la procedura scritta includa ogni passaggio necessario.
7. Prova anche il recupero: torna all'installazione originale partendo da file applicativi, database, media e configurazione corrispondenti e da un PHP compatibile.

Se durante la prova modifichi la configurazione a mano, registra queste modifiche nella procedura, così il ripristino successivo non si ricollega silenziosamente alla produzione.

I file di backup sul disco non dimostrano che il recupero funzioni e il conteggio delle righe è utile, ma non è un test di ripristino completo. Prova i flussi di lavoro e gli accessi reali. Proteggi i dati sensibili dei clienti anche in staging. La guida ai backup tratta il processo di recupero più ampio e la guida allo staging privato ti aiuta a organizzare la copia.

Esegui la procedura Update Assistant già collaudata

Usa una versione attuale di Update Assistant distribuita in pacchetto compatibile con il negozio sorgente, poi segui i controlli preliminari e la procedura della destinazione selezionata. Canali e opzioni attuali differiscono dalle vecchie schermate di "1-Click Upgrade". La selezione online della destinazione dipende anche dall'ambiente PHP.

Esamina requisiti e azioni sui moduli prima di iniziare. Distingui la disattivazione temporanea da disinstallazioni o reimpostazioni proposte, che possono rimuovere impostazioni o dati commerciali. Conserva e migra quei dati prima di accettare un'azione distruttiva. Consulta la procedura Assistant e la guida della versione stessa.

Come si svolge in pratica un aggiornamento da PrestaShop 8 a 9, e dove si inceppa su un negozio attivo, lo mostra il caso di studio di 4eck Media (in tedesco).

Prova prima esattamente questa procedura in staging. In produzione, ripeti la procedura scritta invece di improvvisare:

1. Pianifica il passaggio già provato e assegna un operatore, la checklist di accettazione, un orario per decidere sul ripristino e gli errori che lo fanno scattare.
2. In Parametri negozio > Generale > Manutenzione, imposta Abilita negozio su No. Aggiungi solo gli IP di manutenzione previsti e verifica da un indirizzo esterno.
3. Controlla anche gli altri processi che scrivono: attività cron, importazioni ERP, code e callback. La modalità manutenzione da sola non blocca ogni scrittura esterna.
4. Esegui il backup finale corrispondente e registra l'ultimo punto di riconciliazione di ordini e pagamenti, le callback dei fornitori in sospeso e le importazioni in coda (vedi la sezione sul passaggio qui sotto).
5. Esegui il percorso Assistant e le transizioni PHP verificati. Monitora avanzamento e log PHP/applicativi corretti.
6. In caso di errore, conserva i log e diagnostica il passaggio esatto. Non aggiornare la pagina, rieseguire o terminare un processo alla cieca.
7. Dopo il successo, ricostruisci le cache come utente di esecuzione previsto e verifica la proprietà dei file generati.
8. Riattiva i moduli approvati in un ordine controllato ed esegui i test di accettazione, compresi checkout, email, callback, reindirizzamenti e restrizioni di indicizzazione, prima della riapertura.

I comandi CLI della cache per una destinazione compatibile includono:

php bin/console cache:clear --env=prod
php bin/console cache:warmup --env=prod

Usa il binario PHP e l'identità corretti. Correggi l'accesso ai percorsi scrivibili selezionati invece di assegnare ricorsivamente tutto il codice di produzione all'utente web. Mantieni il blocco delle scritture in manutenzione fino al completamento dei controlli.

Crea un negozio pulito e mappa i dati

Una nuova destinazione è utile quando sostituisci un tema 1.6, riprogetti il negozio o elimini personalizzazioni accumulate. Viene creata e testata in staging mentre il vecchio negozio continua a vendere, quindi solo il trasferimento finale richiede un blocco delle scritture. Comporta però anche un progetto di migrazione dei dati: non tutte le tabelle, le password, i documenti o le integrazioni possono essere copiati senza modifiche.

1. Installa la destinazione supportata in un ambiente pulito e protetto.
2. Scegli un tema compatibile e installa i moduli compatibili richiesti.
3. Configura lingue, valute, imposte, corrieri, pagamenti, email e pagine legali.
4. Mappa categorie, prodotti, combinazioni, caratteristiche, attributi, immagini, scorte, prezzi e metadati SEO.
5. Mappa clienti, indirizzi e gruppi di clienti, verificando la continuità delle password o il processo di reimpostazione necessario.
6. Mappa ordini storici, fatture, note di credito, pagamenti, numerazione dei documenti e relazioni, dove necessario per assistenza e contabilità.
7. Includi i dati commerciali specifici dei moduli, le associazioni ai negozi e i riferimenti delle integrazioni, non solo le tabelle principali del catalogo.
8. Verifica totali, identificatori, associazioni, riferimenti alle immagini e accesso per i clienti.

L'importazione CSV nativa supporta determinate entità di catalogo/clienti; non è una migrazione completa di ordini/pagamenti/documenti storici. Un servizio o script di migrazione dedicato richiede una mappa esplicita di campi/relazioni e una trasformazione verificata.

Esempio di mappa di migrazione

Chiedi come un'esecuzione ripetuta della migrazione evita di duplicare i record e come vengono gestiti nel trasferimento finale i record modificati o eliminati nella sorgente. La prova è utile solo se la stessa procedura può essere eseguita di nuovo sui dati finali.

Non ripristinare un insieme selezionato di tabelle 1.6 sopra uno schema 9 nuovo. Definizioni delle tabelle, righe di negozio/lingua e identificatori differiscono. Conserva riferimenti, relazioni e numerazione dei documenti legali con un processo consapevole dello schema.

Gli hash delle password sono a senso unico. Il funzionamento degli accessi dopo la migrazione dipende dallo strumento di migrazione, dalle chiavi legacy e dal supporto agli algoritmi di hashing della destinazione; copiare solo le righe dei clienti non garantisce la continuità delle password. Prova account reali migrati sulla destinazione isolata. Se servono reimpostazioni, usa il flusso supportato di reimpostazione della password e concorda prima del lancio una comunicazione chiara ai clienti.

Il trasferimento finale delle modifiche avvenute dopo l'istantanea di prova si svolge al momento del passaggio (vedi sotto); richiedi la sua procedura scritta insieme alla mappa dei dati.

Mantieni un tema compatibile o crea un tema figlio

Un aggiornamento del core non richiede sempre la conversione a Hummingbird. Classic resta disponibile nelle versioni 9 pertinenti. Puoi mantenere un tema basato su Classic compatibile e verificato o pianificare una migrazione del tema separata. Un tema 1.6 richiede sostituzione o un porting consistente per PrestaShop moderno.

Mantieni un tema compatibile se supera i percorsi cliente necessari; un aggiornamento del core non implica di per sé una riprogettazione. Tratta una riprogettazione come un lavoro con un ambito separato e controlli di accettazione propri. Quando il tema attuale non può seguire il negozio sulla destinazione, il front office va ricostruito in entrambi i percorsi, e questo fa pendere la valutazione verso un negozio pulito.

Hummingbird è diventato predefinito per le nuove installazioni 9.1. Usa Bootstrap 5.3 e proprietà CSS personalizzate insieme a una compilazione SCSS. Modifiche alle variabili durante l'esecuzione e modifiche che richiedono una pipeline Sass/compilazione sono attività diverse. Verifica hook, selettori, layout responsive e markup di terze parti.

Per un tema acquistato, chiedi la compatibilità esatta con destinazione e PHP, il percorso di aggiornamento, la copertura della licenza e il supporto per i moduli di checkout. Non dare per scontato che un tema funzioni solo perché i suoi template mostrano una homepage. Se sostituisci il tema, prova catalogo, posizioni dei moduli, controlli su mobile e checkout con i tuoi prodotti reali.

Una base completa per un tema figlio

Questo esempio presuppone Hummingbird installato e comandi eseguiti dalla radice del negozio. Crea la cartella config, eredita le risorse del tema genitore e registra esplicitamente un foglio di stile figlio separato.

mkdir -p themes/shop-child/config themes/shop-child/assets/css themes/shop-child/templates
cp themes/hummingbird/preview.png themes/shop-child/preview.png

Crea themes/shop-child/config/theme.yml:

parent: hummingbird
name: shop-child
display_name: Shop Child
version: 1.0.0
author:
  name: Shop Team
assets:
  use_parent_assets: true
  css:
    all:
      - id: shop-child-overrides
        path: assets/css/shop-overrides.css
        media: all
        priority: 1100

Crea themes/shop-child/assets/css/shop-overrides.css:

body { --shop-child-ready: 1; }

Abilita il tema figlio in Design > Tema & Logo. Ricostruisci le cache, apri il pannello Network del browser e verifica che le risorse del tema genitore e shop-overrides.css restituiscano 200. Controlla la proprietà personalizzata calcolata --shop-child-ready sul body. Questo verifica il caricamento del foglio di stile prima di aggiungere modifiche reali al design.

Copia solo i template da modificare, conservandone il percorso sotto templates/. Confrontali in seguito con gli aggiornamenti del genitore. Consulta la struttura dei temi figli e la guida ai temi figli.

Conserva URL, impostazioni di indicizzazione e callback esterni

Crea l'inventario dei vecchi URL a partire da catalogo, scansioni, sitemap, log e dati di Search Console. Gli esempi di indicizzazione di Search Console non sono un'esportazione completa di tutti gli URL indicizzati. Includi i modelli di URL gestiti dai moduli, così che un cambio di route non interrompa silenziosamente indirizzi già usati da clienti o sistemi esterni.

Conserva gli URL funzionanti dove possibile. Per equivalenti modificati, usa reindirizzamenti permanenti verificati come 301 o 308. Controlla contenuto finale, tag canonici, link interni, alternative linguistiche e feed. Non reindirizzare pagine eliminate non pertinenti alla homepage e non promettere un periodo di recupero fisso.

Usa un modulo sitemap come gsitemap o un altro generatore implementato; l'aggiornamento del core non stabilisce da solo una procedura completa per sitemap XML. Verifica URL canonici indicizzabili e con risposta riuscita prima dell'invio. Rimuovi restrizioni noindex/autenticazione dello staging solo dalla destinazione live prevista.

Per esempio, apri un vecchio indirizzo di prodotto in ogni lingua pertinente e segui il reindirizzamento fino al prodotto equivalente live. Controlla l'indirizzo canonico finale, i link alle lingue e la voce nella sitemap. Verifica che la destinazione live non abbia più le restrizioni di accesso e l'impostazione noindex dello staging, mentre la copia di staging resta protetta.

Se il dominio o il percorso cambiano, aggiorna webhook/IPN di pagamento, endpoint ERP, URL dei feed, email, tracciamento e attività pianificate. Prova le operazioni autenticate invece di considerare un semplice HTTP 200 come prova che un'attività cron abbia completato il suo compito commerciale.

La guida a URL e reindirizzamenti contiene mappa, esempi server e controlli di lancio.

SEO Revolution supporta i flussi di lavoro per reindirizzamenti e sitemap; per la configurazione usa la sua guida del modulo.

Smart SEO Friendly URL Manager supporta route personalizzate e cronologia degli URL; usa la sua guida del modulo quando conservi o modifichi questi modelli.

Verifica il negozio prima della riapertura

Esegui questi controlli a ogni prova in staging e di nuovo sulla destinazione di lancio prima della riapertura. Per ogni area raccogli prove, non impressioni.

Verifica la cattura del pagamento nella dashboard del fornitore, non solo lo stato dell'ordine. Conferma fatture, email e variazioni delle scorte previste ed evita addebiti duplicati involontari. Usa le sandbox dei fornitori dove disponibili; concorda e riconcilia qualsiasi transazione live controllata di basso importo, così che i test non causino addebiti, spedizioni o messaggi ai clienti involontari.

Trasforma la checklist in carrelli realistici

• Usa un carrello ospite e uno di un cliente esistente, includendo prezzo di gruppo, buono sconto e destinazione di consegna pertinenti. Confronta imposte e spese di consegna con la sorgente nelle stesse condizioni.
• Prova carrelli appena al di sotto e al di sopra di una soglia configurata per spedizione gratuita o sconto. Includi aliquote miste o casi di clienti professionali se il negozio li usa.
• Completa un pagamento sandbox, esci prima di tornare al negozio e verifica che la callback del fornitore produca comunque lo stato d'ordine previsto. Ripeti una callback con gli strumenti di test supportati dal fornitore e controlla che non si duplichino ordini, messaggi o variazioni delle scorte.
• Esegui un rimborso tramite il flusso concordato e controlla il record del fornitore, il documento di credito e il trattamento delle scorte. La sola modifica dello stato dell'ordine non dimostra che il denaro sia stato restituito.

Per ogni caso, registra carrello iniziale, risultato atteso, risultato osservato e prove. Chiedi al personale che evade gli ordini di approvare il proprio flusso di lavoro.

Conserva i log nei primi cicli operativi completi: importazioni pianificate, regolamento dei pagamenti, resi e picchi di traffico possono esporre casi sfuggiti ai controlli al lancio. Confronta successo del checkout, incassi, code di assistenza e pagine di destinazione principali con il riferimento iniziale.

Effettua il passaggio in un'unica finestra pianificata

Continua a vendere durante la preparazione e le prove; solo il passaggio finale richiede una pausa controllata delle scritture. Eseguilo come procedura a sé, già provata, con un operatore, la checklist di accettazione e le condizioni di errore che fanno scattare il ripristino concordate in anticipo.

1. Blocca il checkout del vecchio negozio e ferma gli altri processi che scrivono: modalità manutenzione più attività cron, importazioni, code e callback, come nei passaggi 2 e 3 della procedura Update Assistant descritta sopra. Questo vale anche per il vecchio negozio nel percorso con nuova installazione.
2. Registra il punto di riconciliazione: l'ultimo ordine ed evento di pagamento riconciliati, le callback dei fornitori in sospeso, le importazioni in coda e le variazioni delle scorte. Concorda con ogni fornitore dove verranno ricevuti o rinviati gli eventi in ritardo, e chi li controlla, invece di bloccare le callback alla cieca.
3. Esegui il backup finale corrispondente.
4. Percorso di aggiornamento: applica la procedura provata a quello stato finale di produzione, oppure usa un metodo di trasferimento provato a parte che conservi tutte le modifiche intermedie. Non promuovere senza modifiche un vecchio database di staging: mancherebbero tutti gli ordini ricevuti dopo l'istantanea di prova.
5. Percorso con nuova installazione: trasferisci le differenze finali successive all'istantanea di prova (ordini, clienti, scorte, pagamenti e dati dei moduli modificati) e riconciliale con la sorgente.
6. Completa i controlli sulla destinazione possibili prima del passaggio. Passa alla destinazione live con la procedura provata, poi verifica checkout, email, callback dei fornitori, reindirizzamenti e impostazioni di indicizzazione tramite i percorsi di produzione prima di riaprire il checkout. Mantieni protetta la copia di staging separata.
7. Se dopo il trasferimento resta una vecchia installazione separata, mantienila isolata e in sola lettura per la consultazione autorizzata. Per un aggiornamento sul posto, conserva l'istantanea pre-aggiornamento corrispondente e la procedura di ripristino testata. Lascia scrivibile solo il checkout di produzione scelto: riaprire entrambi i checkout per evitare la riconciliazione crea due flussi di ordini in concorrenza.
8. Monitora il negozio durante i cicli di importazione, evasione e pagamento pertinenti.

Diagnostica i problemi comuni dopo l'aggiornamento

Inizia dal primo controllo sicuro: conserva le prove e riproduci il problema in uno staging protetto con l'ambiente di esecuzione e le estensioni previsti, prima di modificare il negozio live.

• Pagina bianca o errore 500: esamina prima i log del server web, di PHP-FPM e di PrestaShop e conserva l'eccezione. In uno staging protetto abilita temporaneamente il debug per identificare l'eccezione, poi disattivalo. Controlla estensioni, memoria, codice incompatibile e percorsi scrivibili.
• Errori di riscrittura: conserva le regole personalizzate ed esamina moduli Apache/AllowOverride o location Nginx. Verifica le modifiche alle regole nel contesto previsto; rimuovere pubblicamente .htaccess può eliminare anche protezioni di sicurezza.
• Conflitto tra moduli: usa le azioni supportate di disattivazione dei moduli e isola le modifiche sulla copia. Non eseguire un aggiornamento SQL globale del campo active con un elenco ipotetico di moduli nativi da escludere, e non reimpostare o disinstallare moduli durante un aggiornamento live senza backup, riproduzione in staging e piano di ripristino.
• Traduzioni mancanti: controlla nomi di dominio, file/cataloghi di traduzione, contesto lingua/negozio e cache. Reinstallare non è una soluzione generale alle traduzioni e può eliminare dati del modulo.
• CSS o JavaScript non aggiornati: controlla prima gli URL delle risorse, poi ricostruisci le cache dell'applicazione e del tema e svuota la cache CDN/browser pertinente.
• Immagini mancanti: controlla indirizzi, percorsi e permessi delle risorse prima di rigenerare qualsiasi cosa, poi rigenera solo le miniature necessarie, se serve. Controlla il CDN separatamente.
• Accesso amministrativo: controlla URL, cookie, HTTPS, stato del dipendente, log di autenticazione e consegna dell'email di reimpostazione. Usa la procedura integrata di reimpostazione della password dei dipendenti.

Il core PrestaShop usa il proprio servizio Crypto Hashing, compresi bcrypt e verifica MD5 legacy. Non attribuire tutta la gestione delle password del negozio a MigratingPasswordHasher di Symfony. L'autenticazione moderna del back office e i cookie del front office usano meccanismi diversi.

Non esiste un comando standard di recupero prestashop:user:change-password in questo core. Evita SQL diretto sulle password e script pubblici di reimpostazione. Se l'email di reimpostazione non arriva, correggi la consegna o usa una procedura di recupero amministrativo specificamente supportata.

Per una diagnosi dettagliata, usa la guida alla risoluzione dei problemi.

Ripristina in sicurezza e consegna il risultato

Decidi prima di iniziare quale errore impone il ripristino. Conserva log e stato fallito per la diagnosi. Un ripristino deve abbinare file, database, ambiente PHP, configurazione e media persistenti corrispondenti.

1. Mantieni il negozio in manutenzione e controlla i processi esterni che scrivono.
2. Verifica se la procedura di ripristino collaudata di Assistant può usare il backup pre-aggiornamento previsto.
3. Per un ripristino manuale, usa una destinazione pulita e un database vuoto separato.
4. Ripristina l'istantanea completa corrispondente, inclusi i file nascosti. Non sovrapporre un archivio al codice aggiornato e non presumere che rm -rf /var/www/html/* abbia rimosso i file nascosti.
5. Collega l'ambiente ripristinato al suo database e al dominio/ambiente corretto, correggi i permessi necessari e ricostruisci le cache generate.
6. Prima della riapertura, riconcilia ordini, pagamenti o eventi esterni accettati dopo l'istantanea. Ripristinare il backup di ieri dopo aver ricevuto nuovi ordini richiede un piano di riconciliazione esplicito: un ripristino non cancella la transazione di un fornitore né un'operazione di magazzino.
7. Verifica accesso, catalogo, checkout, email e integrazioni secondo la checklist di recupero.

Un ripristino del solo database con file nuovi lascia un'installazione mista. Se PHP è cambiato, ripristina anche le versioni compatibili del servizio web e della CLI. Mantieni isolato l'ambiente fallito finché non hai log e dati necessari all'indagine.

Senza un backup adeguato, chiedi subito all'host informazioni su istantanee e conservazione, controlla l'inventario dei backup di Assistant e valuta il recupero a un punto nel tempo dove esistono log binari. Un aggiornamento fallito non può essere annullato in sicurezza copiando pochi vecchi file. Potrebbero servire un recupero specialistico o una correzione della versione aggiornata.

Dopo il recupero, riproduci in staging il passaggio che fallisce e correggilo prima di riprovare in produzione.

Decidi chi deve eseguire la migrazione

Usa la complessità del negozio effettivo, la tua capacità di ripristinarlo e il costo dell'interruzione per scegliere lavoro interno o uno specialista. Chiedi a uno sviluppatore inventario scritto, mappa dati/URL, percorso collaudato, test di accettazione, piano di ripristino e consegna del monitoraggio. Basa preventivi e stime di indisponibilità su quell'ambito anziché su fasce generiche di prezzi di mercato.

Alla consegna, documenta nuove versioni, ambiente di esecuzione, temi, impostazioni modificate, titolarità delle credenziali, attività pianificate, URL e responsabili delle integrazioni, limiti noti, passaggi di ripristino dei backup e responsabilità dell'assistenza. Verifica che l'output di debug in produzione sia disattivato e che strumenti e accessi temporanei siano stati rimossi.