Migrazione a PrestaShop 9: Guida completa all'aggiornamento

Perché aggiornare a PrestaShop 9

PrestaShop 9 è il più grande cambiamento architetturale dalla transizione dalla versione 1.6 alla 1.7. Non è un semplice aggiornamento di versione — è una modernizzazione fondamentale della piattaforma. Se stai utilizzando PrestaShop 1.7 o 8.x, la domanda non è se dovresti aggiornare, ma quando e come farlo correttamente.

Ecco cosa porta PrestaShop 9:

Symfony 6.4 LTS sotto il cofano

PrestaShop 9 passa da Symfony 4.4 (PS 8.x) a Symfony 6.4 LTS. Si tratta di una release con supporto a lungo termine, il che significa che riceverai patch di sicurezza e correzioni di bug fino a novembre 2027. L’aggiornamento a Symfony porta una dependency injection moderna, un routing migliorato, una gestione degli errori superiore e un ciclo di vita delle richieste significativamente più veloce.

Per i proprietari di negozi, questo significa una base più stabile e sicura. Per gli sviluppatori, significa accesso a componenti e pattern moderni di Symfony attorno ai quali l’ecosistema PHP si è standardizzato.

PHP 8.2+ richiesto

PrestaShop 9 richiede PHP 8.2 come minimo, con pieno supporto per PHP 8.3. Non è una scelta arbitraria — PHP 8.2+ porta readonly classes, fibers, un sistema di tipi migliorato e miglioramenti prestazionali significativi. I benchmark mostrano un’esecuzione più veloce del 5-15% rispetto a PHP 7.4, con un minor consumo di memoria su tutta la linea.

Se sei ancora su PHP 7.4 o 8.0, il solo aggiornamento a PHP 8.2+ renderà il tuo negozio notevolmente più veloce — anche prima di toccare PrestaShop.

Twig ovunque nell’admin

Il back office ha completato la migrazione da Smarty a Twig. Ogni pagina di amministrazione ora funziona con template Twig, il che significa un rendering più veloce, una maggiore sicurezza (escaping automatico dell’output) e un motore di template effettivamente mantenuto e ben documentato. I controller admin legacy funzionano ancora attraverso un livello di compatibilità, ma la direzione è chiara: Twig è il presente e il futuro.

Hummingbird come tema predefinito

Il tema Classic è sostituito da Hummingbird come tema predefinito per il front office. Hummingbird è costruito su Bootstrap 5.3, utilizza le moderne CSS custom properties ed è significativamente più leggero di Classic. È progettato per le prestazioni — bundle CSS più piccoli, meno JavaScript e migliori punteggi Core Web Vitals fin da subito.

Miglioramenti della sicurezza

Symfony 6.4 porta un componente di sicurezza completamente rinnovato. L’hashing delle password utilizza algoritmi moderni (bcrypt/argon2), la protezione CSRF è più robusta e il sistema di autenticazione si basa sul security bundle di Symfony anziché sull’approccio legacy basato sui cookie di PrestaShop. Le vulnerabilità SQL injection e XSS nei percorsi di codice legacy sono state sistematicamente eliminate.

PrestaShop 9 non è un aggiornamento cosmetico. Cambia il funzionamento della piattaforma nel suo nucleo. Ecco perché è necessario affrontare l’aggiornamento in modo metodico — la ricompensa è un negozio più veloce, più sicuro e più manutenibile, ma solo se la migrazione viene eseguita correttamente.

Prima di iniziare: checklist dei prerequisiti

Non toccare il tuo negozio in produzione finché non hai verificato ogni elemento di questa lista. Saltare i prerequisiti è la causa numero uno degli aggiornamenti falliti.

Requisiti del server

• PHP 8.2 o 8.3 — verifica con php -v sul tuo server. PHP 8.1 NON funzionerà.
• MySQL 8.0+ o MariaDB 10.4+ — verifica con mysql --version. MySQL 5.7 non è più supportato.
• Estensioni PHP richieste: intl, gd, curl, zip, mbstring, openssl, pdo_mysql, fileinfo, dom, json
• Composer 2.x — necessario per la gestione delle dipendenze durante l’aggiornamento
• Almeno 256MB di PHP memory_limit — il processo di aggiornamento richiede molta memoria
• max_execution_time di almeno 600 secondi — i negozi grandi necessitàno di tempo per le migrazioni del database

Per controllare rapidamente la tua configurazione PHP:

# Check PHP version
php -v

# Check loaded extensions
php -m | grep -E "(intl|gd|curl|zip|mbstring|openssl|pdo_mysql)"

# Check memory limit and execution time
php -i | grep -E "(memory_limit|max_execution_time)"

# Check MySQL version
mysql --version

Requisiti della versione PrestaShop

• Devi essere su PrestaShop 8.1 o 8.2 prima. Gli aggiornamenti diretti da 1.7.x o 1.6.x a 9.x non sono supportati.
• Se sei su PS 1.7.x, aggiorna prima alla 8.2, stabilizza, poi aggiorna alla 9.x.
• Se sei su PS 1.6.x — fermati. Hai bisogno di una ricostruzione completa, non di un aggiornamento. Consulta la sezione “Installazione pulita” qui sotto.

Audit di compatibilità dei moduli

Qui è dove la maggior parte degli aggiornamenti fallisce. Prima di aggiornare, devi sapere quali dei tuoi moduli sono compatibili con PS9 e quali no.

1. Fai un elenco completo di ogni modulo installato (Back Office → Moduli → Gestione moduli)
2. Per ogni modulo di terze parti, contatta il fornitore e chiedi: “La versione X.Y è compatibile con PrestaShop 9?”
3. Per ogni modulo che non ha compatibilità confermata, ti serve un piano: aggiornarlo, sostituirlo o rimuoverlo
4. Presta particolare attenzione ai moduli di pagamento — un gateway di pagamento incompatibile significa zero ricavi

Non dare per scontato che un modulo sia compatibile perché “funzionava su PS 8”. PrestaShop 9 rimuove API e modifica il comportamento del core. Un modulo che funzionava perfettamente sulla 8.2 può andare in crash sulla 9.0 perché richiama una funzione che non esiste più.

Compatibilità del tema

• Se stai usando il tema predefinito Classic, dovrai passare a Hummingbird o a un tema di terze parti compatibile con PS9
• Se stai usando un tema acquistato, verifica la compatibilità con PS9 presso lo sviluppatore del tema
• I temi personalizzati basati su Classic richiederanno un lavoro significativo — la struttura dei template è cambiata
• I child theme di Hummingbird sono il percorso consigliato per il futuro

Tempistica aziendale

• Non aggiornare mai durante i periodi di picco delle vendite (Black Friday, Natale, promozioni importanti)
• Programma l’aggiornamento durante il periodo di minor traffico — tipicamente a metà settimana, di mattina presto
• Prevedi almeno 48 ore di monitoraggio dopo l’aggiornamento prima del prossimo picco
• Tieni pronto un piano di rollback (trattato più avanti)

Prima di tutto: backup di tutto

Questo non è opzionale. Non è “consigliato”. È il singolo passaggio più importante. Se l’aggiornamento fallisce e non hai un backup, perdi il tuo negozio. Punto.

Backup del database

Il database contiene tutto ciò che conta — prodotti, clienti, ordini, configurazioni, impostazioni dei moduli. Esegui il backup con mysqldump:

# Standard mysqldump � works on any server
mysqldump -u root -p --single-transaction --quick --lock-tables=false prestashop > ~/backup_pre_ps9_$(date +%Y%m%d_%H%M%S).sql

# If your database is large (>1GB), add compression
mysqldump -u root -p --single-transaction --quick --lock-tables=false prestashop | gzip > ~/backup_pre_ps9_$(date +%Y%m%d_%H%M%S).sql.gz

Se il tuo PrestaShop gira in Docker:

# Replace 'my-shop-db' with your actual database container name
docker exec my-shop-db mysqldump -u root -p'YOUR_PASSWORD' --single-transaction --quick prestashop > ~/backup_pre_ps9_$(date +%Y%m%d_%H%M%S).sql

Spiegazione dei flag:

• --single-transaction — acquisisce uno snapshot coerente senza bloccare le tabelle (fondamentale per InnoDB)
• --quick — recupera le righe una alla volta invece di memorizzarle tutte in memoria (essenziale per tabelle grandi)
• --lock-tables=false — evita il blocco delle tabelle durante il dump, così il negozio resta online

Verifica che il backup funzioni importandolo in un database di test:

# Create a test database and import the backup
mysql -u root -p -e "CREATE DATABASE prestashop_backup_test;"
mysql -u root -p prestashop_backup_test < ~/backup_pre_ps9_XXXXXXXX_XXXXXX.sql

# Check that it imported correctly
mysql -u root -p prestashop_backup_test -e "SELECT COUNT(*) FROM ps_product; SELECT COUNT(*) FROM ps_orders;"

# Clean up
mysql -u root -p -e "DROP DATABASE prestashop_backup_test;"

Backup dei file

Esegui il backup dell’intera directory di PrestaShop — tutti i file PHP, temi, moduli, immagini caricate, tutto:

# Full file backup with tar
tar -czf ~/prestashop_files_pre_ps9_$(date +%Y%m%d_%H%M%S).tar.gz /var/www/html/

# If you want to exclude cache and logs (they're regenerated anyway)
tar -czf ~/prestashop_files_pre_ps9_$(date +%Y%m%d_%H%M%S).tar.gz \
  --exclude='var/cache' \
  --exclude='var/logs' \
  /var/www/html/

Per i negozi basati su Docker, esegui il backup del volume montato:

tar -czf ~/prestashop_files_pre_ps9_$(date +%Y%m%d_%H%M%S).tar.gz /path/to/docker/html/

Conserva i tuoi backup in almeno due posizioni — il server stesso E una posizione esterna (il tuo computer locale, un bucket di cloud storage o un server diverso). Un backup che esiste solo sullo stesso disco del tuo negozio non è un vero backup.

Note sulla configurazione

Prima di iniziare, documenta queste impostazioni (ti serviranno se dovrai riconfigurare):

• Il tuo app/config/parameters.php (credenziali del database, configurazione del mailer, chiave dei cookie)
• Il tuo file .htaccess (specialmente se hai aggiunto regole di rewrite personalizzate)
• La configurazione SMTP/email dal back office
• Le chiavi API e le impostazioni del gateway di pagamento
• Le configurazioni dei cron job
• Eventuali configurazioni personalizzate del server (regole Nginx, impostazioni del pool PHP-FPM)

Fai degli screenshot delle pagine di impostazioni critiche del back office. Quando qualcosa va storto durante l’aggiornamento, avere un riferimento visivo di “come appariva prima” è prezioso.

Processo di aggiornamento passo dopo passo

Ci sono due percorsi legittimi per arrivare a PrestaShop 9: l’aggiornamento in-place tramite il modulo ufficiale, oppure un’installazione pulita con migrazione dei dati. Ognuno ha il suo ambito di applicazione.

Approccio 1: modulo Auto-Upgrade (aggiornamento 1-Click)

Il percorso di aggiornamento ufficiale utilizza il modulo autoupgrade (chiamato anche “1-Click Upgrade”). Questo modulo gestisce automaticamente la sostituzione dei file, la migrazione del database e la pulizia post-aggiornamento.

Preparazione

1. Installa o aggiorna il modulo 1-Click Upgrade all’ultima versione dal PrestaShop Marketplace
2. Vai su Back Office → Moduli → 1-Click Upgrade
3. Il modulo mostrerà la tua versione attuale e gli obiettivi di aggiornamento disponibili
4. Esegui la Checklist pre-aggiornamento — il modulo controllerà la compatibilità del tuo server e segnalerà potenziali problemi

Abilita la modalità di manutenzione

# Or do it from the back office: Shop Parameters ? General ? Maintenance ? Enable
# Make sure to whitelist your own IP address

Questo è essenziale. Non vuoi che i clienti effettuino ordini mentre il database è in fase di migrazione.

Esegui l’aggiornamento

1. Nel modulo 1-Click Upgrade, seleziona la versione di destinazione (PrestaShop 9.x)
2. Scegli “Major upgrade” come canale di aggiornamento
3. Rivedi le opzioni di aggiornamento:
   • Backup di file e database — abilitalo (cintura e bretelle, anche se hai già fatto il backup manualmente)
   • Disattiva i moduli non nativi — abilitalo per prevenire conflitti tra moduli durante l’aggiornamento
   • Rigenera i template email — abilitalo se non li hai personalizzati
4. Clicca su “Aggiorna PrestaShop ora”
5. NON chiudere la scheda del browser, NON navigare altrove — attendi il completamento del processo

L’aggiornamento può richiedere da 5 minuti (negozio piccolo) a oltre 30 minuti (catalogo ampio, molti moduli). Vedrai un log di avanzamento che mostra ogni passaggio.

Dopo il completamento dell’aggiornamento

# Clear all caches � this is not optional
rm -rf var/cache/*

# If using CLI (recommended):
php bin/console cache:clear --env=prod
php bin/console cache:warmup --env=prod

# Fix file permissions
chown -R www-data:www-data /var/www/html/var/
chown -R www-data:www-data /var/www/html/themes/
chmod -R 755 /var/www/html/var/

Riabilita i moduli uno alla volta

Se hai scelto di disattivare i moduli non nativi durante l’aggiornamento, non abilitarli tutti insieme. Abilitali uno alla volta:

1. Abilita il modulo
2. Controlla il front office e il back office per verificare la presenza di errori
3. Se funziona, passa al modulo successivo
4. Se causa problemi, disabilitalo e contatta il fornitore del modulo

Questo approccio metodico ti dice esattamente quale modulo ha causato un problema, invece di trovarti davanti a un negozio rotto con 30 moduli abilitati senza idea di quale sia il colpevole.

Approccio 2: installazione pulita + migrazione dei dati

A volte il percorso più pulito è ripartire da zero. Installa PrestaShop 9 da zero e migra i tuoi dati al suo interno. Questo approccio richiede più lavoro ma ti offre un’installazione immacolata senza alcun bagaglio legacy.

Quando scegliere l’installazione pulita

• Stai aggiornando da PS 1.6.x (l’aggiornamento in-place non è supportato per salti così grandi)
• Il tuo negozio attuale ha anni di override accumulati, hack e tabelle di moduli abbandonati
• Vuoi comunque cambiare tema
• Il tuo database è diventato gonfio con carrelli abbandonati, vecchi log e dati orfani
• Tentativi precedenti di aggiornamento sono falliti

Il processo

1. Installa PrestaShop 9 da zero su una nuova directory o server
2. Configura il tuo tema (Hummingbird o un tema compatibile con PS9)
3. Installa i tuoi moduli (solo versioni compatibili con PS9)
4. Migra i tuoi dati utilizzando:
   • L’import CSV di PrestaShop per prodotti, categorie e clienti
   • Migrazione diretta del database tramite script SQL personalizzati
   • Strumenti di migrazione di terze parti
5. Riconfigura gateway di pagamento, spedizioni, tasse ed email
6. Testa tutto sulla nuova installazione
7. Cambia il DNS o scambia la document root quando sei pronto

Migrazione dei dati tramite import CSV

Lo strumento di import integrato di PrestaShop (Back Office → Parametri avanzati → Importazione) gestisce:

• Categorie
• Prodotti (con combinazioni, immagini, caratteristiche e stock)
• Clienti
• Indirizzi
• Produttori e Fornitori

Esporta dal tuo vecchio negozio, ripulisci i file CSV e importa in quello nuovo. È un lavoro tedioso per cataloghi grandi, ma offre il risultato più pulito.

Migrazione dei dati tramite SQL

Per sviluppatori esperti, la migrazione diretta via SQL è più veloce per grandi volumi di dati:

# Export specific tables from old database
mysqldump -u root -p old_prestashop \
  ps_product ps_product_lang ps_product_shop \
  ps_category ps_category_lang ps_category_shop \
  ps_customer ps_address \
  ps_image ps_image_lang ps_image_shop \
  ps_stock_available \
  > ~/migration_data.sql

# You'll need to review and adjust the SQL for schema changes between versions
# Column names, table structures, and foreign keys may differ

La migrazione SQL richiede una conoscenza approfondita dello schema del database di PrestaShop. Se non sei a tuo agio nello scrivere e fare debug di SQL complesso, usa il metodo di import CSV o assumi uno sviluppatore. Una migrazione SQL mal eseguita può corrompere i tuoi dati in modi estremamente difficili da correggere.

Quale approccio è migliore?

Per la maggior parte dei proprietari di negozi che utilizzano PS 8.x con un numero ragionevole di moduli ben mantenuti, l’auto-upgrade è la scelta giusta. L’installazione pulita ha senso quando si proviene da una versione molto vecchia o si vuole cogliere l’occasione per fare pulizia.

Compatibilità dei moduli: cosa si rompe in PrestaShop 9

Questa sezione è per sviluppatori e proprietari di negozi tecnicamente curiosi. Capire cosa è cambiato ti aiuta a valutare se i tuoi moduli sopravviveranno all’aggiornamento.

Template Smarty rimossi dall’admin

Questo è il più grande cambiamento che rompe la compatibilità. In PS 8.x, i controller admin legacy potevano ancora utilizzare template Smarty (file .tpl) per le pagine del back office. In PS 9, l’admin è completamente basato su Twig. I controller legacy sono incapsulati da un LegacyController di Symfony che renderizza il loro output attraverso Twig.

Cosa significa in pratica:

• I moduli con pagine admin personalizzate che usano AdminController + Smarty funzionano ancora, ma vengono renderizzati all’interno del nuovo layout Twig tramite un livello di compatibilità
• Gli override dei template admin (file in override/controllers/admin/templates/) potrebbero non funzionare come previsto
• Le variabili Smarty assegnate in initContent() possono andare perse perché LegacyController incapsula il rendering in modo diverso — la variabile Smarty content deve essere riassegnata esplicitamente
• Il metodo display() di AdminController non viene più chiamato da PS 9 — LegacyController lo bypassa completamente

Cambiamenti al sistema di override

PrestaShop scoraggia gli override fin da PS 1.7, e PS 9 inasprisce ulteriormente le restrizioni:

• Gli override delle classi core funzionano ancora tecnicamente, ma sono sempre più fragili man mano che il codice core si sposta verso i servizi Symfony
• Gli override dei controller non sono affidabili — il livello di routing di Symfony potrebbe non caricarli come previsto
• Gli override dei template nelle directory override/ sono deprecati per le pagine admin
• L’approccio consigliato ora è tramite hook, decorator Symfony e event subscriber

Se hai moduli che dipendono fortemente dagli override, sono quelli più a rischio di rompersi durante l’aggiornamento. Controlla la directory override/ nella cartella di ogni modulo.

Cambiamenti degli hook

PrestaShop 9 aggiunge nuovi hook e modifica alcuni di quelli esistenti:

• Diversi hook legacy nell’area admin sono stati rimossi o rinominati
• Nuovi hook sono disponibili per le pagine admin basate su Symfony
• Gli hook del front office rimangono in gran parte compatibili (Hummingbird utilizza gli stessi punti di hook di Classic)
• L’ordine di esecuzione degli hook potrebbe cambiare in alcuni casi — se il tuo modulo dipende dall’essere chiamato prima o dopo un altro hook, testalo

Deprecazioni dei controller legacy

Diversi pattern dei controller admin che funzionavano in PS 8.x si comportano diversamente in PS 9:

• $this->l() (la funzione di traduzione) è stata rimossa dai controller admin — usa $this->module->l('string', 'ControllerClassName') al suo posto
• Tools::displayPrice() è stata rimossa — usa Context::getContext()->getCurrentLocale()->formatPrice($amount, $currencyIsoCode)
• $this->meta_title, $this->fields_list e $this->bulk_actions del controller admin devono essere assegnati DOPO la chiamata a parent::__construct() perché il riferimento al modulo non è disponibile prima
• La directory admin ora è backoffice/ per impostazione predefinita (non admin-dev o una stringa casuale) — i percorsi admin hardcoded smetteranno di funzionare

Come verificare se i tuoi moduli sono pronti per PS9

Per ogni modulo installato:

1. Controlla il sito del fornitore — cerca dichiarazioni esplicite di compatibilità con PS 9
2. Verifica la presenza di override — guarda dentro modules/tuomodulo/override/. Qualsiasi file lì è un segnale di attenzione.
3. Cerca chiamate a funzioni deprecate — cerca nei file PHP del modulo:
   • Tools::displayPrice(
   • $this->l( nei file dei controller admin
   • Classi AdminController con metodi display() complessi
   • Percorsi della directory admin hardcoded
4. Controlla il config.xml del modulo o il file PHP principale per l’impostazione ps_versions_compliancy — include la 9.x?

# Quick command to find potential PS9 issues in a module
# Run this from inside the module directory

# Check for overrides
find override/ -type f 2>/dev/null && echo "WARNING: Module uses overrides"

# Check for removed functions
grep -rn "Tools::displayPrice" *.php controllers/ classes/ 2>/dev/null
grep -rn '$this->l(' controllers/admin/ 2>/dev/null

# Check version compatibility declaration
grep -A2 "ps_versions_compliancy" *.php

Migrazione del tema: Hummingbird è ora il predefinito

PrestaShop 9 viene distribuito con Hummingbird come tema predefinito, sostituendo Classic. Se stai usando Classic o un tema basato su Classic, hai bisogno di un piano di migrazione.

Cosa è cambiato in Hummingbird

• Bootstrap 5.3 sostituisce Bootstrap 4 — i nomi delle classi, il sistema a griglia e le classi utility sono cambiati
• CSS Custom Properties sono usate estensivamente per la tematizzazione — colori, spaziature e tipografia sono configurati tramite variabili CSS anziché variabili SCSS
• Meno JavaScript — Hummingbird si affida maggiormente alle funzionalità native del browser e meno ai plugin jQuery
• Sistema di build moderno — compilazione degli asset basata su Webpack con tree shaking appropriato
• Design responsive-first — il layout mobile è la base, il desktop è il miglioramento (a differenza di Classic che era desktop-first)

Se stai usando il tema Classic

Il tema Classic non è incluso in PS 9. Le tue opzioni sono:

1. Passa a Hummingbird — il percorso più semplice. Crea un child theme per le tue personalizzazioni.
2. Acquista un tema compatibile con PS9 — molti fornitori di temi hanno rilasciato versioni per PS9.
3. Porta le tue personalizzazioni di Classic su un child theme di Hummingbird — richiede lavoro di sviluppo frontend ma offre il miglior risultato a lungo termine.

Creare un child theme di Hummingbird

Un child theme ti permette di personalizzare Hummingbird senza modificare i file core del tema (così le tue modifiche sopravvivono agli aggiornamenti del tema):

# Create child theme directory structure
mkdir -p themes/my-child-theme/assets/css
mkdir -p themes/my-child-theme/templates

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

parent: hummingbird
name: my-child-theme
display_name: My Custom Theme
version: 1.0.0
author:
  name: Your Name

Aggiungi i tuoi stili personalizzati in themes/my-child-theme/assets/css/custom.css. Hummingbird carica automaticamente custom.css dai child theme con la priorità più bassa (caricato per ultimo), quindi i tuoi stili sovrascriveranno il tema genitore.

Per sovrascrivere un template specifico, copialo da themes/hummingbird/templates/ allo stesso percorso relativo nel tuo child theme. Copia solo i file che devi modificare — tutto il resto viene ereditato automaticamente dal tema genitore.

Se stai usando un tema acquistato

Contatta il fornitore del tuo tema e fai queste domande specifiche:

• È disponibile una versione compatibile con PS9?
• È basata su Hummingbird o è un tema standalone?
• La mia licenza attuale copre la versione PS9?
• Qual è il percorso di migrazione dalla versione attuale?

Se il fornitore non ha una versione PS9 e non può darti una tempistica, inizia a pianificare il passaggio a Hummingbird ora.

Checklist post-aggiornamento

Hai completato l’aggiornamento e il back office si carica. Non festeggiare ancora. Verifica sistematicamente ogni funzione critica del tuo negozio.

Test del front office

Test del back office

Verifica del gateway di pagamento

Questa sezione merita un capitolo a parte perché impatta direttamente sui ricavi. Per OGNI metodo di pagamento:

1. Effettua un vero ordine di test (o usa la modalità sandbox se disponibile)
2. Verifica che il pagamento sia registrato nella dashboard del provider di pagamento
3. Verifica che lo stato dell’ordine si aggiorni correttamente in PrestaShop
4. Testa i rimborsi se il tuo flusso di lavoro lo richiede
5. Controlla gli URL webhook/IPN — l’aggiornamento potrebbe aver modificato le strutture degli URL

Verifica delle spedizioni

• Verifica che tutti i corrieri mostrino tariffe corrette per le diverse zone
• Testa le soglie di spedizione gratuita
• Se utilizzi il calcolo delle tariffe in tempo reale (basato su API), verifica che la connessione funzioni ancora
• Controlla che l’inserimento del numero di tracking e le email di notifica funzionino

Cron Job

Controlla ogni attività automatizzata che viene eseguita a intervalli programmati:

• Email di abbandono carrello
• Sincronizzazione dello stock
• Generazione dei feed (Google Shopping, Facebook, ecc.)
• Generazione della sitemap
• Aggiornamento dei tassi di cambio
• Eventuali script cron personalizzati

Gli URL dei cron cambiano spesso tra le versioni principali. Aggiorna le voci del tuo crontab:

# Check your current cron jobs
crontab -l

# PS 9 cron URLs may have changed � verify each one loads correctly
curl -s -o /dev/null -w "%{http_code}" "https://yourshop.com/modules/yourmodule/cron.php?token=XXXXX"

Verifica SEO

• Controlla che i friendly URL funzionino ancora (pagine di categoria, pagine prodotto)
• Verifica che la sitemap venga generata correttamente
• Controlla che il robots.txt sia corretto
• Testa le pagine di destinazione chiave che si posizionano bene — assicurati che esistano ancora agli stessi URL
• Se gli URL sono cambiati, imposta immediatamente i redirect 301

Problemi comuni durante l’aggiornamento e soluzioni

Schermata bianca della morte

Il problema più comune dopo l’aggiornamento. Vedi una pagina bianca vuota senza alcun messaggio di errore.

Soluzione:

1. Abilita la modalità debug modificando config/defines.inc.php:

   define('_PS_MODE_DEV_', true);

2. Ricarica la pagina — ora dovresti vedere l’errore PHP effettivo
3. Se vedi ancora la schermata bianca, controlla i log degli errori PHP:

   # Apache
   tail -50 /var/log/apache2/error.log
   
   # Nginx + PHP-FPM
   tail -50 /var/log/php-fpm/error.log
   
   # PrestaShop's own log
   tail -50 /var/www/html/var/logs/prod.log

4. Cause comuni:
   • Memoria PHP esaurita — aumenta memory_limit in php.ini a 512M
   • Estensione PHP mancante — installa l’estensione richiesta e riavvia PHP
   • Problema di permessi file — esegui chown -R www-data:www-data /var/www/html/var/

Errore 500 Internal Server Error

Solitamente causato da problemi con il file .htaccess o problemi di configurazione PHP dopo l’aggiornamento.

Soluzione:

# Check if .htaccess is the problem � temporarily rename it
mv /var/www/html/.htaccess /var/www/html/.htaccess.bak

# If the site loads without .htaccess, regenerate it from back office:
# Shop Parameters ? Traffic & SEO ? Generate .htaccess file

# Or manually restore the default PS 9 .htaccess

Controlla anche:

• Che Apache mod_rewrite sia abilitato: a2enmod rewrite && systemctl restart apache2
• Che il tuo virtual host Apache consenta gli override di .htaccess: AllowOverride All
• Che la versione PHP sia effettivamente 8.2+ per il processo web (non solo per la CLI)

Conflitti tra moduli dopo l’aggiornamento

Sintomi: il back office si carica parzialmente, errori in sezioni specifiche, errori JavaScript nella console.

Soluzione — il metodo di isolamento:

1. Disabilita TUTTI i moduli non nativi:

   # Via database if back office is broken
   mysql -u root -p prestashop -e "UPDATE ps_module SET active = 0 WHERE name NOT IN ('ps_banner','ps_contactinfo','ps_emailsubscription','ps_featuredproducts','ps_imageslider','ps_linklist','ps_mainmenu','ps_searchbar','ps_sharebuttons','ps_socialfollow','ps_wirepayment','ps_checkpayment');"

2. Svuota la cache: rm -rf var/cache/*
3. Verifica che il negozio funzioni con i soli moduli nativi
4. Abilita i moduli uno alla volta, svuotando la cache tra uno e l’altro
5. Quando trovi il modulo problematico, aggiornalo, sostituiscilo o contatta il fornitore

Traduzioni mancanti o non funzionanti

Dopo l’aggiornamento, alcune stringhe di traduzione potrebbero mancare o essere visualizzate come chiavi grezze (come Modules.YourModule.SomeString).

Soluzione:

• Vai su Internazionale → Traduzioni ed esporta/importa il tuo language pack
• Per le traduzioni dei moduli, resetta le traduzioni del modulo: disinstalla e reinstalla il modulo (nota: questo potrebbe resettare la configurazione — esegui un backup prima)
• PrestaShop 9 utilizza il sistema di traduzione di Symfony in modo più intensivo — i file di traduzione in vecchio formato (in modules/tuomodulo/translations/) potrebbero dover essere convertiti

Problemi di cache

La cache obsoleta è alla base di un numero sorprendente di problemi post-aggiornamento. In caso di dubbio, svuota tutto:

# Nuclear cache clear
rm -rf var/cache/*

# Symfony cache rebuild
php bin/console cache:clear --env=prod --no-warmup
php bin/console cache:warmup --env=prod --no-optional-warmers

# Fix ownership after cache rebuild
chown -R www-data:www-data var/

# Also clear your browser cache � old cached JS/CSS can cause phantom issues

Immagini non visualizzate

I percorsi delle immagini o il sistema di recupero delle immagini potrebbero cambiare tra le versioni.

Soluzione:

• Rigenera le miniature: Design → Impostazioni immagini → Rigenera miniature
• Controlla che i permessi della directory img/ siano corretti
• Se utilizzi una CDN, svuota la cache della CDN
• Verifica che il nuovo formato degli URL delle immagini corrisponda a ciò che il tuo tema si aspetta

Login admin non funzionante

Gli algoritmi di hashing delle password sono cambiati in PS 9 (MigratingPasswordHasher di Symfony con bcrypt/argon2). Nella maggior parte dei casi, le password esistenti funzioneranno perché l’hasher migra automaticamente al primo accesso. Ma se sei bloccato fuori:

# Reset admin password � PS 9 requires Symfony's password hasher
# Do NOT use raw MD5 or direct SQL UPDATE on the password field

# Instead, use PrestaShop's CLI (if available):
php bin/console prestashop:user:change-password --email=admin@yourshop.com

# Or create a temporary PHP script to reset the password properly
# (delete this file immediately after use!)

Non lasciare mai script di reset password sul tuo server. Creali, usali, cancellali — tutto in una sola sessione. Uno script di reset dimenticato è una vulnerabilità di sicurezza.

Quando assumere uno sviluppatore vs. fare da soli

Sii onesto sulle tue competenze tecniche. Un aggiornamento fallito può costarti giorni di fatturato e fiducia dei clienti. Ecco una guida realistica:

Probabilmente puoi fare da solo se:

• Stai aggiornando da PS 8.2 a 9.x (un solo salto di versione)
• Hai meno di 10 moduli di terze parti, tutti confermati compatibili con PS9
• Stai usando un tema standard (Classic → Hummingbird, o un tema acquistato con supporto PS9)
• Ti trovi a tuo agio con SSH, la riga di comando e le operazioni sul database
• Hai un ambiente di staging funzionante su cui testare prima
• Il tuo negozio non ha override personalizzati o modifiche al core

Dovresti assumere uno sviluppatore se:

• Stai aggiornando da PS 1.6.x o versioni iniziali della 1.7.x (grande divario di versione)
• Hai 20+ moduli, specialmente se alcuni usano override
• Hai un tema personalizzato che deve essere portato su Hummingbird
• Il tuo negozio ha modifiche personalizzate al core o file di override
• Non ti trovi a tuo agio con la riga di comando o le operazioni sul database
• Il tuo negozio genera ricavi giornalieri significativi e il downtime è costoso
• Hai tentato l’aggiornamento sullo staging e hai incontrato problemi che non riesci a risolvere

Cosa cercare in uno sviluppatore

• Esperienza specifica con PrestaShop — non semplicemente “sviluppatore PHP” o “sviluppatore e-commerce”. L’architettura di PrestaShop è unica, e gli sviluppatori generici spenderanno ore fatturabili per imparare cose che uno specialista PS già conosce.
• Esperienza specifica con PS 9 — chiedi se hanno già completato aggiornamenti a PS 9. La migrazione a Symfony 6.4 ha insidie specifiche.
• Un piano di progetto chiaro — dovrebbero proporre: audit → aggiornamento su staging → test → aggiornamento in produzione → monitoraggio.
• Supporto post-aggiornamento — i problemi spesso emergono 1-2 settimane dopo l’aggiornamento quando vengono attivati casi limite. Assicurati che il supporto sia incluso.

Fasce di prezzo tipiche

Queste sono stime approssimative basate sulle tariffe di mercato nel 2025-2026:

• Aggiornamento semplice (PS 8.x → 9.x, pochi moduli, tema standard): 500-1500 EUR
• Aggiornamento medio (PS 1.7.x → 9.x, porting del tema personalizzato, moduli moderati): 2000-5000 EUR
• Aggiornamento complesso (PS 1.6.x → 9.x, ricostruzione completa, molti moduli personalizzati): 5000-15000+ EUR

Questi prezzi riflettono la realtà che un aggiornamento di versione principale non è un’operazione con un solo clic. Se qualcuno ti fa un preventivo di 200 EUR per un aggiornamento da PS 1.6 a PS 9, o non comprende la portata del lavoro oppure taglierà angoli che ti costeranno di più in seguito.

Piano di rollback: se le cose vanno male

Hai fatto i backup (li hai fatti, vero?). Ecco come usarli se l’aggiornamento fallisce in modo catastrofico.

Rollback dall’Auto-Upgrade

Se hai usato il modulo 1-Click Upgrade e ha creato il proprio backup:

1. Vai su Back Office → Moduli → 1-Click Upgrade
2. Clicca su “Rollback” e seleziona il backup pre-aggiornamento
3. Il modulo ripristinerà sia i file che il database

Se il back office è completamente inaccessibile, dovrai ripristinare manualmente:

Rollback manuale — Database

# Drop the current (broken) database and recreate it
mysql -u root -p -e "DROP DATABASE prestashop; CREATE DATABASE prestashop;"

# Import your backup
mysql -u root -p prestashop < ~/backup_pre_ps9_XXXXXXXX_XXXXXX.sql

# For Docker:
docker exec -i my-shop-db mysql -u root -p'PASSWORD' -e "DROP DATABASE prestashop; CREATE DATABASE prestashop;"
docker exec -i my-shop-db mysql -u root -p'PASSWORD' prestashop < ~/backup_pre_ps9_XXXXXXXX_XXXXXX.sql

Rollback manuale — File

# Remove the upgraded files
rm -rf /var/www/html/*

# Restore from your backup
tar -xzf ~/prestashop_files_pre_ps9_XXXXXXXX_XXXXXX.tar.gz -C /

# Fix permissions
chown -R www-data:www-data /var/www/html/

# Clear cache
rm -rf /var/www/html/var/cache/*

Verifica che il rollback abbia funzionato

1. Accedi al front office — il tuo negozio si carica?
2. Accedi al back office — riesci a fare il login?
3. Controlla alcuni ordini — i dati sono intatti?
4. Effettua un ordine di test — il checkout funziona?
5. Disabilita la modalità di manutenzione una volta confermato che tutto funziona

Dopo un rollback, NON tentare immediatamente di eseguire l’aggiornamento di nuovo. Analizza prima cosa è andato storto. Controlla i log dell’aggiornamento, identifica il passaggio che ha fallito, cerca l’errore specifico e correggi la causa principale nel tuo ambiente di staging prima di toccare nuovamente la produzione.

L’emergenza “senza backup”

Se non hai fatto i backup (succede — non facciamo finta che non sia così), le tue opzioni sono limitate ma non inesistenti:

• Backup del provider di hosting: Molti host conservano backup giornalieri per 7-30 giorni. Controlla il pannello del tuo hosting o contatta immediatamente il supporto.
• Binary log del database: Se il binary logging di MySQL è abilitato, il recovery point-in-time potrebbe essere possibile. Questo richiede competenze specifiche.
• Il backup del modulo autoupgrade: Se hai selezionato “crea backup” durante l’aggiornamento, cerca in /admin/autoupgrade/backup/ i file di backup del modulo.
• Accetta e vai avanti: Se il recupero non è possibile, concentrati sulla riparazione del negozio aggiornato anziché cercare di tornare indietro. A volte andare avanti è l’unica via.

Riepilogo: il percorso di aggiornamento in sintesi

1. Audit — controlla i requisiti del server, la compatibilità dei moduli, la compatibilità del tema
2. Backup — database (mysqldump), file (tar), note sulla configurazione
3. Staging — testa l’intero aggiornamento su un ambiente di staging prima
4. Pianificazione — scegli una finestra a basso traffico con tempo di margine per eventuali problemi
5. Aggiornamento — modalità di manutenzione attiva, esegui l’aggiornamento, svuota le cache
6. Test — front office, back office, checkout, pagamenti, spedizioni, email
7. Monitoraggio — controlla i log degli errori per 48 ore dopo la messa in produzione
8. Pulizia — disabilita la modalità debug, rimuovi i file temporanei, aggiorna la documentazione

PrestaShop 9 è un miglioramento significativo rispetto ai suoi predecessori. La base Symfony 6.4, il requisito PHP 8.2+ e l’admin basato su Twig creano una piattaforma più stabile, veloce e manutenibile. L’aggiornamento richiede una pianificazione attenta, ma il risultato vale lo sforzo — un motore di e-commerce moderno che ti servirà bene per gli anni a venire.

Prenditi il tuo tempo, testa accuratamente e non saltare i backup. Il tuo futuro te stesso ti ringrazierà.