Compatibilità PrestaShop 9: Tutti i nostri moduli sono pronti
PrestaShop 9 è arrivato. Il tuo stack di moduli è pronto?
PrestaShop 9 è arrivato con la più significativa revisione architetturale da quando la piattaforma ha adottato Symfony nella versione 1.7. Ho preparato i nostri moduli per questa release fin dalle prime build alpha, e in quel processo ho imparato esattamente cosa si rompe, cosa si degrada silenziosamente e cosa i proprietari di negozi devono verificare prima ancora di pensare a cliccare "Aggiorna".

Questa non è un riepilogo del changelog. È la guida pratica che avrei voluto avere quando ho aperto per la prima volta una beta di PrestaShop 9 e ho visto metà dei moduli di terze parti nel mio negozio di test generare errori 500. Che tu sia un proprietario di negozio che sta valutando il suo stack di moduli, uno sviluppatore freelance che prepara una migrazione per un cliente, o un'agenzia che gestisce decine di installazioni PrestaShop, questa guida ti accompagna attraverso l'intero processo di audit della compatibilità.
Cosa è cambiato in PrestaShop 9 (e perché rompe le cose)
Prima di poter verificare i tuoi moduli, devi capire cosa ha cambiato PrestaShop 9 a livello architetturale. Non sono aggiornamenti cosmetici. Sono cambiamenti fondamentali che toccano ogni modulo che interagisce con il back office, il livello database o il tema front-end.
Symfony 6.4: il cambiamento principale
PrestaShop è passato da Symfony 4.4 a Symfony 6.4. Non è un aggiornamento incrementale. È un salto attraverso due major version di Symfony, ciascuna delle quali ha introdotto le proprie deprecazioni e rimozioni. Per gli sviluppatori di moduli, la conseguenza più critica è come funzionano i controller.
In Symfony 4.4, potevi usare $this->get('service_name') all'interno dei controller per recuperare qualsiasi servizio dal container. In Symfony 6.4, i controller devono essere definiti come servizi con dependency injection corretta. Il vecchio FrameworkBundleAdminController funziona ancora in PrestaShop 9, ma è ufficialmente deprecato e verrà rimosso in PrestaShop 10. Qualsiasi modulo che estende questa classe sta vivendo in prestito.
Cosa significa per te: se le pagine admin di un modulo funzionano oggi su PrestaShop 9 ma usano il pattern legacy del controller, potrebbero smettere di funzionare completamente su PrestaShop 10. Vuoi moduli che abbiano già migrato a PrestaShopAdminController con constructor injection.
Librerie rimosse da cui probabilmente dipendi
PrestaShop 9 ha rimosso dal core diverse librerie che i moduli usavano gratuitamente:
- Guzzle HTTP client è stato sostituito dal client HTTP di Symfony. Qualsiasi modulo che effettua chiamate API esterne tramite Guzzle genererà un errore fatale "class not found" a meno che non includa la propria copia.
- SwiftMailer è stato sostituito da Symfony Mailer. I moduli che inviano email direttamente (notifiche ordine, avvisi, report) devono usare la nuova interfaccia mailer.
- Tactician command bus è stato sostituito da Symfony Messenger. I moduli che usano pattern CQRS con Tactician necessitano di una riscrittura completa della gestione comandi/query.
La parte subdola: questi fallimenti non si manifestano sempre immediatamente. Un modulo potrebbe installarsi e visualizzare perfettamente la sua pagina di configurazione, ma crashare nel momento in cui tenta di inviare una richiesta HTTP o dispatchare un comando. Non li troverai con un rapido test "si installa?".
33 hook sono stati rimossi
PrestaShop 9 ha rimosso 33 hook. Non è un refuso. Trentatré punti di integrazione su cui i moduli facevano affidamento semplicemente non esistono più. Le rimozioni rientrano in tre categorie:
- Hook legacy della pagina prodotto (l'intera vecchia interfaccia di modifica prodotto è stata rimossa, portando con sé tutti i suoi hook): actionAdminProductsControllerXxx, actionAdminActivateAfter/Before, actionAdminDeactivateAfter/Before, actionAdminDeleteAfter/Before e actionAdminSortAfter/Before
- Hook del controller login (ora gestiti dalla sicurezza Symfony): actionAdminLoginControllerBefore, actionAdminLoginControllerLoginBefore/After, actionAdminLoginControllerForgotBefore/After e actionAdminLoginControllerResetBefore/After
- Hook del layout legati al vecchio ciclo di vita dell'AdminController (initHeader, initContent, initFooter, display) sono effettivamente morti perché PrestaShop 9 gestisce il layout tramite componenti Twig
Se un modulo registra uno di questi hook, non crasherà, ma l'hook semplicemente non si attiverà mai. Il modulo perde silenziosamente funzionalità. Questo è probabilmente peggio di un crash perché potresti non accorgerti per settimane che una funzione ha smesso di funzionare.
PHP 8.1 minimo, PHP 8.4 raccomandato
PrestaShop 9 richiede PHP 8.1 come minimo. Questo elimina i negozi che ancora girano su PHP 7.4 o 8.0. Ancora più importante, significa che i moduli devono gestire le funzionalità di PHP 8.1+ e il controllo dei tipi più rigoroso. Le funzioni che precedentemente restituivano tipi misti ora necessitano di dichiarazioni esplicite del tipo di ritorno. I parametri nullable necessitano del prefisso ? o dei tipi unione. I giorni della tipizzazione lassista di PHP sono finiti.
Testo tutti i nostri moduli contro PHP 8.1, 8.2, 8.3 e 8.4 specificamente perché ogni versione minore di PHP introduce nuovi avvisi di deprecazione che possono riempire i tuoi log e, in ambienti con reporting degli errori rigoroso, causare warning visibili ai clienti.
Gestione avanzata dello stock: eliminata
L'intero sistema di Gestione Avanzata dello Stock è stato rimosso da PrestaShop 9. Questo include ordini ai fornitori, magazzini e la vecchia interfaccia di gestione stock. Se uno dei tuoi moduli interagisce con i dati del magazzino, gli hook degli ordini ai fornitori o l'API di gestione avanzata dello stock, si romperà. Questa rimozione riguarda anche le tabelle del database, quindi i moduli che interrogano direttamente le tabelle relative allo stock otterranno errori SQL.
Deprecazione del Singleton Context
Il singleton Context che ogni sviluppatore PrestaShop conosce e ama (o tollera) sta venendo gradualmente eliminato. PrestaShop 9 ha introdotto servizi di contesto dedicati: EmployeeContext, ShopContext, CurrencyContext, CountryContext, LanguageContext e altri. I moduli che usano Context::getContext() funzionano ancora, ma i moduli costruiti su pratiche moderne dovrebbero transitare verso questi servizi dedicati.
La funzione di traduzione non esegue più l'escape dell'HTML
Questo è un cambiamento sottile ma pericoloso. La funzione trans() in PrestaShop 9 non esegue più automaticamente l'escape delle entità HTML. Nelle versioni precedenti, passare input utente attraverso trans() forniva un livello di protezione XSS quasi per caso. In PrestaShop 9, i moduli devono usare esplicitamente htmlspecialchars() su qualsiasi contenuto dinamico passato alle traduzioni. I moduli che non aggiornano questo stanno potenzialmente introducendo vulnerabilità di sicurezza.
Tema Hummingbird e Bootstrap 5
PrestaShop 9 include il tema Hummingbird come predefinito, costruito su Bootstrap 5. PrestaShop 9.1 ha ulteriormente aggiornato a Bootstrap 5.3.3. Per qualsiasi modulo che renderizza template front-end, questo significa:
- I nomi delle classi Bootstrap 4 non funzionano più (es. .no-gutters diventa .g-0, .custom-checkbox diventa .form-check)
- Gli attributi data sono con namespace (data-toggle diventa data-bs-toggle)
- jQuery è ufficialmente deprecato in Hummingbird e verrà rimosso nella prossima major version del tema. I moduli che si affidano a jQuery per le funzionalità front-end necessitano di un percorso di migrazione verso JavaScript vanilla
- I selettori CSS basati su classi specifiche di PrestaShop stanno venendo sostituiti con attributi data data-ps-*
Come verificare i tuoi moduli installati: un processo passo-passo
Ora che sai cosa è cambiato, ecco il processo sistematico che uso per valutare la compatibilità dei moduli. Non devi essere uno sviluppatore per seguire la maggior parte di questi passaggi.
Step 1: Inventaria i tuoi moduli
Vai al back office di PrestaShop, naviga su Moduli > Gestione moduli ed esporta o fai uno screenshot della tua lista completa di moduli installati. Per ogni modulo, annota:
- Nome del modulo e versione attuale
- Nome del vendor/sviluppatore
- Data dell'ultimo aggiornamento
- Se è un modulo gratuito, un modulo a pagamento da PrestaShop Addons o un modulo di terze parti
Categorizza ogni modulo in base a quanto è critico per il tuo business. Un modulo gateway di pagamento è critico. Un widget di condivisione sociale è un "nice to have". Questa prioritizzazione determina la tua tempistica di aggiornamento.
Step 2: Verifica le dichiarazioni di compatibilità dei vendor
Per ogni vendor di moduli, cerca una dichiarazione esplicita di compatibilità con PrestaShop 9. Ecco cosa cercare e quali sono i segnali d'allarme:
Segnali positivi:
- Il vendor ha un blog post o una voce nel changelog che menziona specificamente la compatibilità con PrestaShop 9.0 e 9.1
- La versione del modulo è stata aggiornata dopo la data di rilascio di PrestaShop 9
- Il vendor menziona il testing con Symfony 6.4 e PHP 8.1+
- La retrocompatibilità con PrestaShop 8.x è mantenuta (mostra che capiscono il supporto multi-versione)
Segnali d'allarme:
- Nessuna menzione di PrestaShop 9 da nessuna parte sul sito del vendor
- L'ultimo aggiornamento del modulo è precedente alle release alpha di PrestaShop 9
- Anche gli altri moduli del vendor non sono stati aggiornati (suggerisce una linea di prodotti abbandonata)
- La descrizione del modulo menziona "Compatibile con PrestaShop 1.7" senza alcun riferimento a 8.x o 9.x
Step 3: Ispeziona il codice del modulo per pattern problematici noti
Se hai conoscenze base di PHP, o il tuo sviluppatore le ha, apri i file del modulo e cerca questi pattern specifici che sono garantiti causare problemi su PrestaShop 9:
Cerca $this->get( nei controller admin — Questo è il pattern legacy di Symfony 4.4 per l'accesso ai servizi. Funziona su PrestaShop 9 ma è deprecato. I moduli che lo usano non sono stati modernizzati.
Cerca use GuzzleHttp — Se il modulo importa Guzzle ma non lo include nella propria directory vendor, si romperà su PrestaShop 9 dove Guzzle è stato rimosso dal core.
Cerca Swift_ o SwiftMailer — Stessa situazione. SwiftMailer è stato rimosso dal core.
Cerca Tools::displayPrice — Questo è stato deprecato. I moduli dovrebbero usare il servizio Locale per la formattazione dei prezzi.
Cerca data-toggle= nei file .tpl — Attributi data di Bootstrap 4. Dovrebbero essere data-bs-toggle= per la compatibilità con Hummingbird.
Cerca $.ajax o $(document) nei file .js — Uso di jQuery. Funziona ancora sul tema Classic ma si romperà su Hummingbird quando jQuery verrà rimosso.
Step 4: Configura un ambiente di staging
Non testare mai la compatibilità dei moduli sul tuo negozio live. Ecco la configurazione minima di staging:
- Clona il tuo database di produzione in un database separato (o usa la funzione di staging del tuo hosting)
- Installa PrestaShop 9 da zero o usa il modulo di aggiornamento sulla tua installazione clonata
- Installa i tuoi moduli uno alla volta, controllando il log degli errori dopo ogni installazione. L'ordine conta: installa prima i moduli di pagamento e spedizione, poi i moduli SEO, poi i moduli cosmetici
- Testa le funzionalità core di ogni modulo, non solo "la pagina di configurazione si carica?". Effettua un ordine di test. Esegui un'importazione prodotti. Genera una sitemap. Qualsiasi cosa il modulo faccia effettivamente in produzione
Consiglio pro: Controlla il log degli errori PHP (
/var/log/php_errors.logo il log degli errori del tuo hosting) dopo ogni installazione di modulo. Molti problemi di compatibilità si manifestano come avvisi di deprecazione PHP o warning piuttosto che crash completi. L'avviso di oggi è l'errore fatale di domani.
Step 5: Testa il rendering front-end su entrambi i temi
Se stai usando PrestaShop 9 con il nuovo tema Hummingbird, testa ogni modulo che produce output sul front end. Presta particolare attenzione a:
- Modifiche alla pagina checkout (form dei moduli di pagamento, selezione corriere, validazione indirizzo)
- Widget sulle pagine prodotto (recensioni, wishlist, guide alle taglie, campi personalizzati)
- Hook header e footer (mega menu, barre di ricerca, anteprime carrello)
- Filtri e ordinamento delle pagine categoria
Se stai restando sul tema Classic, il rischio di compatibilità front-end è più basso, ma i cambiamenti di Bootstrap 5 possono comunque influenzare i moduli che iniettano il proprio CSS.
Cosa chiedere ai tuoi vendor di moduli
Quando contatti un vendor di moduli riguardo alla compatibilità con PrestaShop 9, non chiedere solo "è compatibile?". Quella domanda ottiene una risposta sì/no che potrebbe essere sbagliata. Invece, fai queste domande specifiche:
- "Il modulo è stato testato su PrestaShop 9.0 E 9.1?" — La versione 9.1 ha introdotto ulteriori cambiamenti breaking (Bootstrap 5.3.3, deprecazione jQuery, nuovi cambiamenti agli hook). Testare solo sulla 9.0 non è sufficiente.
- "Il modulo supporta ancora PrestaShop 8.x con lo stesso file ZIP?" — Se il vendor richiede una versione separata per PrestaShop 9, quello è un onere di manutenzione per te. Un modulo ben costruito gestisce il rilevamento della versione internamente.
- "Avete migrato via dai pattern deprecati di Symfony 4.4?" — Se il vendor non capisce questa domanda, ti dice qualcosa sulla sua profondità tecnica.
- "Il modulo usa jQuery sul front end?" — Se sì, chiedi della loro timeline di migrazione verso JavaScript vanilla prima che Hummingbird rimuova il supporto jQuery.
- "Qual è la vostra gamma di versioni PHP testate?" — Vuoi sentire da 8.1 a 8.4, non solo "PHP 8".
Il framework decisionale per l'aggiornamento
Basandomi sulla mia esperienza nell'aggiornamento di ambienti di test e nell'aiutare i proprietari di negozi a valutare la loro preparazione, ecco un framework pratico per decidere quando aggiornare:
Aggiorna ora se:
- Tutti i tuoi moduli hanno confermata la compatibilità con PrestaShop 9 dai loro vendor
- Stai già usando PHP 8.1+
- Hai un ambiente di staging dove hai testato l'intero percorso di aggiornamento
- Il tuo tema è Classic, Hummingbird o un child theme di uno dei due
Aspetta 3-6 mesi se:
- Uno o due moduli non critici non hanno conferma di compatibilità
- Il tuo tema è un tema di terze parti pesantemente personalizzato (i vendor di temi spesso restano indietro nel supporto delle major version)
- Fai affidamento sulla Gestione Avanzata dello Stock (devi prima trovare flussi di lavoro sostitutivi)
Non aggiornare ancora se:
- I moduli critici (pagamento, spedizione, integrazione ERP) non hanno dichiarazione di compatibilità con PrestaShop 9
- Stai usando PHP 7.4 o 8.0 (hai bisogno prima di un aggiornamento PHP, che è un progetto a sé)
- Il tuo vendor di moduli è silenzioso da oltre un anno (il modulo potrebbe essere abbandonato)
Come abbiamo preparato i nostri moduli (un caso studio reale)
A mypresta.rocks, ho iniziato a testare contro le build alpha di PrestaShop 9 mesi prima della release stabile. Ecco come si è svolto realmente il processo, perché penso sia istruttivo per capire cosa significhi davvero "compatibile".

Fase 1: Scansione automatizzata della compatibilità
Ho eseguito analisi statica su ogni modulo cercando i pattern che ho descritto sopra: uso di controller legacy, import di librerie rimosse, chiamate a funzioni deprecate, classi Bootstrap 4 nei template e uso di jQuery nei file JavaScript. Questo ha prodotto una lista prioritizzata delle modifiche necessarie.
Fase 2: Migrazione a Symfony 6.4
Ogni controller admin è stato revisionato per i pattern di accesso al service container. Dove i moduli usavano $this->get(), abbiamo migrato alla constructor injection. Dove i moduli estendevano il controller base deprecato, abbiamo aggiornato la classe padre. Questa è stata la fase più dispendiosa in termini di tempo perché tocca l'architettura core di ogni modulo con interfaccia admin.
Fase 3: Audit degli hook
Abbiamo incrociato ogni registrazione di hook in ogni modulo con la lista dei 33 hook rimossi. Dove i moduli usavano hook rimossi, abbiamo migrato a hook sostitutivi o implementato una registrazione di hook condizionale alla versione che usa automaticamente l'hook corretto per la versione di PrestaShop rilevata.
Fase 4: Testing multi-versione
Ogni modulo è stato testato su PrestaShop 1.7.6, 1.7.7, 1.7.8, 8.0, 8.1, 9.0 e 9.1. Su ogni versione, abbiamo testato con PHP 8.1, 8.2, 8.3 e 8.4. Un singolo ZIP del modulo funziona su tutte queste combinazioni perché il modulo rileva la versione di PrestaShop a runtime e adatta il suo comportamento di conseguenza.
Questo è ciò che "retrocompatibile" significa davvero nella pratica. Non sono due build separate. È un singolo codebase che gestisce le differenze di versione internamente.
Fase 5: Testing del tema front-end
Ogni modulo con output front-end è stato testato sul tema Classic e sul tema Hummingbird. I nomi delle classi Bootstrap, gli attributi data e il JavaScript sono stati verificati su entrambi. Dove erano necessarie differenze nei template, abbiamo usato il rilevamento versione integrato di PrestaShop per caricare il template appropriato.
Il risultato: tutti i moduli mypresta.rocks sono completamente compatibili con PrestaShop 9.0 e 9.1, mantenendo la retrocompatibilità con PrestaShop 1.7.6+ e tutte le versioni 8.x. Nessun download separato, nessun passaggio di installazione speciale, nessun prezzo "edizione PrestaShop 9".
Problemi comuni post-aggiornamento e come risolverli
Anche con moduli compatibili, potresti incontrare questi problemi dopo l'aggiornamento a PrestaShop 9:
Schermo bianco / Errore 500 dopo l'installazione del modulo
Di solito causato da una dipendenza Composer mancante. Controlla il log degli errori PHP per errori "Class not found". La soluzione è aggiornare il modulo (se il vendor ha una nuova versione) o aggiungere manualmente la libreria mancante alla directory vendor del modulo.
Le pagine admin si caricano ma mancano funzionalità
Questo è il problema della rimozione silenziosa degli hook. Il modulo si è installato con successo, ma i suoi hook non si attivano più su PrestaShop 9. Verifica le registrazioni degli hook del modulo rispetto alla lista degli hook rimossi. Contatta il vendor per una versione aggiornata che usa gli hook sostitutivi.
Stile front-end rotto su Hummingbird
Cambiamenti dei nomi delle classi da Bootstrap 4 a 5. Il modulo funziona su Classic ma appare rotto su Hummingbird. Questo richiede aggiornamenti dei template dal vendor del modulo. Come workaround temporaneo, puoi passare al tema Classic in attesa dell'aggiornamento del vendor.
Errori JavaScript nella console del browser
Spesso causati dalla dipendenza da jQuery in un ambiente Hummingbird. Controlla la console per sviluppatori del browser (F12) per errori "$ is not defined" o "jQuery is not defined". La soluzione a lungo termine è JavaScript vanilla, ma nel breve termine puoi includere manualmente jQuery negli asset del tuo tema.
Le notifiche email hanno smesso di funzionare
Se un modulo invia email tramite SwiftMailer direttamente invece della funzione mail di PrestaShop, si romperà su PrestaShop 9 dove SwiftMailer è stato sostituito da Symfony Mailer. Contatta il vendor per un aggiornamento.
PrestaShop 9.1: cambiamenti aggiuntivi da tenere d'occhio
PrestaShop 9.1 ha introdotto i propri cambiamenti in aggiunta alla 9.0. Se stai aggiornando direttamente alla 9.1 (raccomandato, essendo l'ultima stabile), tieni presente questi ulteriori fattori di compatibilità:
- Theme::getDefaultTheme() non restituisce più la stringa hardcoded "classic". I moduli che presumevano che il tema predefinito fosse Classic necessitano di aggiornamento.
- L'hook displaySearch è stato rimosso da Hummingbird perché causava conflitti sulle pagine 404. I moduli che si agganciano a displaySearch per la personalizzazione della ricerca front-end devono usare hook alternativi.
- Le librerie di grafici D3 e NVD3 sono state aggiornate a versioni più recenti. I widget della dashboard che usano queste librerie potrebbero renderizzarsi in modo non corretto.
- I selettori JavaScript sono migrati alla convenzione data-ps-*, sostituendo i selettori basati su classi. I moduli che usano querySelector con nomi di classi specifiche di PrestaShop potrebbero non puntare più agli elementi corretti.
La tua checklist pre-aggiornamento
Stampa questa lista, appendila al muro e non aggiornare finché ogni punto non è verificato:
- Inventaria tutti i moduli installati con nomi dei vendor e versioni attuali
- Verifica sul sito di ogni vendor le dichiarazioni di compatibilità con PrestaShop 9
- Aggiorna tutti i moduli alle loro ultime versioni (anche prima di aggiornare PrestaShop)
- Configura un ambiente di staging con una copia del tuo database di produzione
- Installa PrestaShop 9.1 nello staging
- Installa i moduli uno per uno, controllando i log degli errori dopo ciascuno
- Testa le funzionalità core di ogni modulo (non solo "la pagina di configurazione si carica?")
- Testa il rendering front-end sul tuo tema attivo
- Esegui un ordine di test completo attraverso il checkout
- Controlla i log degli errori PHP per avvisi di deprecazione
- Verifica l'invio email da tutti i moduli che inviano notifiche
- Fai backup di tutto: database, file e configurazione
- Programma l'aggiornamento durante le ore di basso traffico
- Mantieni disponibile il tuo backup di PrestaShop 8.x per almeno 30 giorni dopo l'aggiornamento
Considerazioni finali
PrestaShop 9 è un miglioramento significativo. Symfony 6.4 porta migliori performance, pratiche PHP moderne e un'architettura più manutenibile. Il tema Hummingbird è più veloce e accessibile di Classic. La nuova admin API apre possibilità che prima non erano disponibili.
Ma niente di tutto ciò conta se i tuoi moduli si rompono durante l'aggiornamento. Prenditi il tempo per fare l'audit correttamente. Usa un ambiente di staging. Chiedi ai tuoi vendor dichiarazioni esplicite di compatibilità, non risposte vaghe del tipo "dovrebbe funzionare".
Se stai cercando moduli che sono stati rigorosamente testati da PrestaShop 1.7.6 alla 9.1, dai un'occhiata al catalogo moduli di mypresta.rocks. Ogni modulo viene fornito come singolo ZIP che funziona su tutte le versioni supportate, e la compatibilità con PrestaShop 9 è inclusa in ogni licenza, non venduta come aggiornamento separato.
Hai domande sul tuo specifico scenario di aggiornamento? Contattaci e ti aiuterò a valutare il tuo stack di moduli.
Commenti
Nessun commento ancora. Siate i primi!
Lascia un commento