Compatibilità con PrestaShop 9: tutti i nostri moduli sono pronti

Ogni modulo che distribuiamo funziona su PrestaShop 9. Ecco cosa è servito per arrivarci.

Ultima revisione: giugno 2026. Stato attuale: la 9.1.0 è la release stabile dal 23 marzo 2026, basata su Symfony 6.4 LTS, PHP 8.1–8.5, con Hummingbird (Bootstrap 5.3) come tema predefinito per le nuove installazioni. Eseguiamo mypresta.rocks sulla 9.1.3 e abbiamo testato i nostri oltre 150 moduli fino alla 9.1.

Abbiamo iniziato a ricostruire il nostro catalogo sulle alpha di PrestaShop 9 all'inizio del 2024. Quando è uscita la versione stabile 9.0, la nostra CI interna eseguiva già ogni ZIP di modulo su sette versioni di PrestaShop e quattro versioni di PHP prima di consentire il merge anche di una sola riga. Oggi ogni modulo del nostro catalogo di oltre 140 moduli si installa e funziona su PS 9.0 e 9.1 dallo stesso ZIP che si installa su 8.x e 1.7.6+. Un'unica base di codice, rilevamento della versione a runtime, nessun prezzo da "edizione PrestaShop 9".

Questo è il punto principale. Il resto di questo articolo è la parte che la maggior parte degli annunci "supportiamo PS 9!" salta: cosa si è davvero rotto durante la migrazione, cosa abbiamo intercettato solo perché testiamo su negozi reali e cosa dovresti chiedere agli altri fornitori prima di fidarti delle loro dichiarazioni di compatibilità.

Cosa ha cambiato davvero PrestaShop 9

Se hai letto solo il riassunto sul blog di PrestaShop, potresti pensare che PS 9 sia un ordinato aggiornamento di Symfony. Non lo è. È la release più dirompente da quando la 1.7 introdusse Symfony per la prima volta, e l'impatto si concentra proprio nelle parti del framework che i moduli toccano più spesso.

Da Symfony 4.4 a 6.4, due major version in un solo salto

È qui che cade la maggior parte dei moduli di terze parti. Nella 4.4 potevi scrivere $this->get('service_name') dentro un controller di amministrazione e prendere qualunque cosa dal container. Nella 6.4 quel pattern funziona ancora (PrestaShop ha mantenuto un livello di compatibilità), ma la classe base su cui si appoggia, FrameworkBundleAdminController, è ufficialmente deprecata e prevista per la rimozione in PrestaShop 10.

Tradotto: se oggi le pagine di amministrazione di un modulo vengono renderizzate su PS 9 ma quel modulo estende ancora FrameworkBundleAdminController, ha già una data di scadenza nota. Abbiamo riscritto tutti i nostri controller di amministrazione perché estendano PrestaShopAdminController con una corretta injection tramite costruttore. È la parte più lenta della migrazione ed è quella che non si può saltare.

Librerie che il core non ti fornisce più

PrestaShop 9 ha rimosso tre librerie che i moduli prima ricevevano gratuitamente dal vendor/ del core:

• Guzzle, sostituito dal client HTTP di Symfony. Qualsiasi modulo che usa use GuzzleHttp\Client e non include una propria copia genera un errore fatale di classe non trovata appena prova a effettuare una chiamata HTTP.
• SwiftMailer, sostituito da Symfony Mailer. I moduli che inviano email direttamente tramite Swift non generano solo una deprecazione: vanno in errore fatale.
• Tactician command bus, sostituito da Symfony Messenger. Se un modulo usava CQRS tramite Tactician, gli handler di comandi e query vanno riscritti.

Il punto che sorprende molti: questi problemi non compaiono all'installazione. Il modulo si carica, la pagina di configurazione si apre correttamente e poi il negozio va in crash la prima volta che parte un cron o che un cliente attiva il percorso di codice che invia l'email. Durante i test sulle alpha di PS 9 abbiamo intercettato così due nostri moduli: si installavano senza errori, sembravano sani nel pannello di amministrazione e saltavano solo alle 3 del mattino, quando partiva un cron di sincronizzazione stock.

33 hook rimossi

Non è un refuso e non è un avviso di deprecazione: sono spariti. Le rimozioni si concentrano in tre gruppi:

• Hook prodotto legacy dell'amministrazione. Il vecchio editor prodotto è stato eliminato del tutto e ha portato via con sé i suoi hook (actionAdminProductsControllerXxx, actionAdminActivateAfter/Before, actionAdminDeactivateAfter/Before, actionAdminDeleteAfter/Before, actionAdminSortAfter/Before)
• Hook di accesso all'amministrazione, ora gestiti dalla sicurezza di Symfony (actionAdminLoginControllerBefore, actionAdminLoginControllerLogin/Forgot/Reset Before/After)
• Hook del ciclo di vita di AdminController, initHeader, initContent, initFooter, display scattano ancora sui controller legacy incapsulati da LegacyController, ma le nuove pagine di amministrazione Symfony li saltano completamente. Se il tuo modulo dipende da questi hook, testalo su ogni pagina di amministrazione in cui compare.

Nella pratica è peggio di un crash: un modulo si registra su un hook rimosso, l'installazione va a buon fine, l'hook semplicemente non viene mai eseguito e la funzionalità smette di funzionare in silenzio. Uno dei nostri moduli è rimasto in questo stato su un negozio di staging per due settimane prima che ci accorgessimo che un badge di notifica lato amministrazione era sparito senza fare rumore.

PHP 8.1 minimo, e testiamo fino alla 8.4

PS 9 abbandona PHP 8.0 e precedenti. Testiamo ogni modulo su 8.1, 8.2, 8.3 e 8.4 perché ogni versione minor ha il proprio insieme di deprecazioni, e una deprecazione in 8.3 che si limita a riempire i log spesso diventa un errore bloccante in 8.4. Intercettarle in CI su 8.4 costa meno che scoprirle quando un provider di hosting porta il negozio di un cliente alla 8.4 durante la notte.

Advanced Stock Management è sparito

L'intero sottosistema (ordini di fornitura, magazzini, interfaccia di amministrazione ASM) è stato rimosso in PS 9. Sono sparite anche le tabelle del database, quindi i moduli che interrogavano direttamente ps_supply_order* o ps_warehouse* genereranno errori SQL, non solo avvisi PHP. Due dei nostri moduli (mprwarehouserevolution e mprstockorder) gestiscono i dati di magazzino indipendentemente da ASM proprio perché non ci siamo mai fidati della sopravvivenza di ASM: quella scelta ha pagato.

Il singleton Context va verso il pensionamento

PS 9 introduce servizi di contesto dedicati: EmployeeContext, ShopContext, CurrencyContext, CountryContext, LanguageContext. Context::getContext() funziona ancora e continuerà a farlo per un po', ma ormai è un code smell. Lo migriamo in modo opportunistico: quando siamo già in un file per correggere qualcos'altro, passiamo al servizio dedicato.

trans() non esegue più l'escape dell'HTML

Questo cambiamento è pericoloso perché è invisibile. In PS 8 e precedenti, la funzione trans() eseguiva l'escape delle entità HTML come effetto collaterale. Molto codice dei moduli si affidava involontariamente a quel comportamento per la protezione XSS senza rendersene conto. In PS 9 devi applicare esplicitamente htmlspecialchars() a qualsiasi contenuto dinamico prima di passarlo a trans(). I moduli che non lo fanno ora si trovano con potenziali falle XSS che per anni erano sembrate innocue.

Hummingbird, Bootstrap 5 e il conto alla rovescia per jQuery

PS 9.1 include Hummingbird come tema predefinito per le nuove installazioni, su Bootstrap 5.3.3 (PS 9.0 usava Bootstrap 5, i negozi aggiornati mantengono il tema esistente). Per i moduli che toccano il front end questo significa:

• Le classi utility di Bootstrap 4 sono sparite (.no-gutters diventa .g-0, .custom-checkbox diventa .form-check)
• Gli attributi data hanno un namespace (data-toggle diventa data-bs-toggle)
• jQuery è ufficialmente deprecato in Hummingbird ed è già avviato verso la rimozione. Abbiamo già riscritto in vanilla JS il JavaScript front end dei nostri moduli per pagamento, performance e schede prodotto: in parte per anticipare la scadenza, in parte perché il layout di pagamento di Hummingbird penalizza i pattern di manipolazione DOM tipici di jQuery
• I selettori di classi specifici di PrestaShop vengono sostituiti da attributi data-ps-*: se il tuo CSS o JS punta a .cart-block, preparati a cambiare target

Come verificare lo stack di moduli esistente

La maggior parte dei negozi che migriamo non usa solo i nostri moduli: ha uno stack di quindici-quaranta moduli di una dozzina di fornitori, e i nostri sono magari cinque. Questo è il processo che applichiamo a ogni migrazione cliente.

Passo 1: fare un inventario onesto

Moduli → Gestione moduli. Esporta l'elenco. Per ogni modulo annota: nome, versione attuale, fornitore, data dell'ultimo aggiornamento e quanto è critico. Un gateway di pagamento è critico; un widget di condivisione social è decorativo. È la criticità a guidare la timeline, non l'ordine alfabetico.

Passo 2: leggere il changelog del fornitore, non il titolo promozionale

"Compatibile con PrestaShop 9" in homepage non significa nulla. Quello che ti serve è una voce di changelog successiva alla release pubblica di PS 9 che menzioni esplicitamente lavoro su Symfony 6.4, test su PHP 8.1+ o sostituzione degli hook rimossi. Se l'aggiornamento più recente del fornitore è del 2023 e il testo marketing punta ancora su "compatibile con PrestaShop 1.7", il modulo probabilmente è abbandonato e il sito non se n'è ancora accorto.

Passo 3: fare grep nel codice del modulo

Se hai uno sviluppatore (o una tua riga di comando), decomprimi il modulo e cerca con grep i pattern che sono problemi garantiti:

# Legacy Symfony 4.4 service access
grep -rn '\$this->get(' modules/yourmodule/

# Removed core libraries
grep -rn 'use GuzzleHttp' modules/yourmodule/
grep -rn 'Swift_\|SwiftMailer' modules/yourmodule/
grep -rn 'League\\Tactician' modules/yourmodule/

# Deprecated price formatting (removed in PS 9.0)
grep -rn 'Tools::displayPrice' modules/yourmodule/

# Bootstrap 4 data attributes
grep -rn 'data-toggle=' modules/yourmodule/views/templates/

# jQuery usage in front-end JS
grep -rn '\$.ajax\|\$(document)' modules/yourmodule/views/js/

Un risultato su use GuzzleHttp senza un composer.json che includa Guzzle nella cartella vendor del modulo è un crash confermato su PS 9. Un risultato su Tools::displayPrice è un errore fatale certo: quel metodo è stato rimosso, non solo deprecato. Manteniamo internamente un piccolo package prestashop-compat che incapsula questi casi per i nostri moduli; nei moduli di terze parti senza quella protezione, la chiamata muore.

Passo 4: uno staging che rispecchi davvero la produzione

Non testare mai la compatibilità sul negozio live. La nostra ricetta minima per lo staging:

1. Clona il database di produzione in un DB separato (la maggior parte dei buoni provider di hosting ha una funzione in un clic per farlo)
2. Installa PS 9.1 su quel database: vai direttamente alla 9.1, non passando dalla 9.0, perché tanto è lì che dovrai arrivare
3. Installa i moduli in ordine di dipendenza: prima pagamenti e spedizioni, poi SEO/marketing, poi estetica. Così un crash causato da un modulo pesante non blocca la possibilità di testare quelli più leggeri
4. Dopo ogni installazione, tieni d'occhio il log errori PHP e il log PrestaShop in var/logs/. La maggior parte dei problemi di compatibilità nasce come avviso di deprecazione e diventa fatale alla minor successiva: non ignorare gli avvisi
5. Testa il lavoro reale del modulo, non solo "si apre la pagina di configurazione". Inserisci un vero ordine di test. Esegui un'importazione. Genera una sitemap reale. Il rendering della pagina di configurazione dimostra quasi nulla

L'abitudine con il rendimento più alto che abbiamo adottato: tail -f var/logs/* in un terminale mentre si naviga nel pannello di amministrazione in un altro. Il rumore delle deprecazioni è il principale indicatore di rotture nella versione successiva. Se un modulo riempie quel log su PS 9.1, sarà quel modulo ad andare in errore fatale sulla 9.2.

Passo 5: test rapido del front end sul tema che userai davvero

Se passi a Hummingbird, ogni modulo con output front end va controllato visivamente sul tema reale, non su Classic in un amministratore di test. I punti in cui troviamo sempre rotture:

• Procedura di pagamento, moduli di pagamento, blocchi corriere, validazione indirizzi, qualsiasi elemento inserito nel riepilogo ordine
• Pagine prodotto, recensioni, liste desideri, guide alle taglie, blocchi di campi personalizzati
• Header/footer. Mega menu e menu a discesa di ricerca sono particolarmente fragili nella migrazione a Bootstrap 5
• Filtri e controlli di ordinamento delle pagine categoria

Se resti su Classic, il rischio è più basso, ma non è nullo: Bootstrap 5 arriva comunque nell'amministrazione e qualsiasi modulo che condivide CSS tra front office e back office può ancora comportarsi male.

Le domande che vale la pena fare a un fornitore

"Il vostro modulo è compatibile con PrestaShop 9?" è una domanda sì/no che riceve "sì" nel 100% dei casi, spesso a torto. Queste sono le domande che poniamo ai fornitori quando valutiamo i loro moduli per lo stack di un cliente:

1. Il modulo è testato su 9.0 e 9.1? La 9.1 ha aggiunto Bootstrap 5.3.3, eliminato displaySearch e rielaborato la convenzione dei selettori data-ps-*. Testare solo su 9.0 è metà lavoro.
2. È lo stesso ZIP per 8.x e 9.x? Se serve un download separato per PS 9, è una trappola di manutenzione pronta a scattare in ogni negozio che gestisce più versioni. I moduli a ZIP unico con rilevamento della versione a runtime sono il modo corretto di farlo.
3. Avete migrato da FrameworkBundleAdminController? Se lo sviluppatore non riconosce la domanda, hai appena imparato qualcosa di importante.
4. Il JavaScript front end richiede ancora jQuery? Per ora va bene, ma chiedi la timeline di migrazione. Hummingbird rimuoverà jQuery e non vuoi essere l'ultima priorità del fornitore quando succederà.
5. Qual è la matrice di test PHP? La risposta che vuoi sentire è "dalla 8.1 alla 8.4", non "PHP 8".

Quando aggiornare, quando aspettare

Procedi subito se i moduli critici hanno compatibilità esplicita con PS 9.1, sei già su PHP 8.1+, hai una copia di staging funzionante e il tuo tema è Classic, Hummingbird o un child theme di uno dei due.

Aspetta da tre a sei mesi se uno o due moduli utili ma non essenziali non hanno ancora conferma di compatibilità, il tuo tema è un tema a pagamento molto personalizzato (i fornitori di temi arrivano tardi: abbiamo visto ritardi di 18 mesi), oppure dipendi da Advanced Stock Management e non hai ancora scelto un sostituto.

Non aggiornare se un modulo critico (pagamento, spedizione, sincronizzazione ERP) non ha alcuna dichiarazione per PS 9 e il fornitore non rilascia nulla da un anno, sei ancora su PHP 7.4 o 8.0 (quello è un progetto separato: fallo prima), oppure il tuo negozio ha personalizzazioni pesanti fatte da un'agenzia che non ha testato PS 9.

Come abbiamo portato davvero i nostri oltre 140 moduli su PS 9

Vale la pena descriverlo nel dettaglio perché "supportiamo PrestaShop 9" significa cose diverse per fornitori diversi, e la differenza conta quando affidi il tuo negozio live al modulo di qualcuno.

Fase 1: analisi statica su tutto il catalogo

Abbiamo eseguito uno scanner personalizzato sul sorgente di ogni modulo cercando i pattern sopra: uso di controller legacy, import Guzzle/Swift/Tactician, Tools::displayPrice, markup Bootstrap 4, dipendenze jQuery. Il risultato era una lista di lavoro per modulo ordinata per rischio. Non ci siamo fidati della nostra memoria per "ricordare" quali moduli richiedessero quale correzione.

Fase 2: migrazione dei controller a Symfony 6.4

Ogni controller di amministrazione che toccava il service container è passato da $this->get() all'injection tramite costruttore. Ogni controller che estendeva la classe base deprecata è stato migrato a PrestaShopAdminController. Questa è la fase lenta: tocca la colonna portante di ogni modulo rivolto all'amministrazione e non ci sono scorciatoie.

Fase 3: audit e sostituzione degli hook

Abbiamo incrociato ogni chiamata registerHook() del catalogo con l'elenco degli hook rimossi in PS 9. Quando un hook non esisteva più, abbiamo migrato al sostituto oppure aggiunto una registrazione condizionata alla versione negli script di installazione: così un modulo installato su PS 8.x usa ancora il vecchio hook, mentre lo stesso ZIP su PS 9 usa quello nuovo.

Fase 4: livello condiviso di compatibilità

I metodi con maggiori probabilità di essere rimossi nelle minor future vivono dietro wrapper in un package condiviso (prestashop-compat). Tools::displayPrice è il caso più evidente: ora è \MyPrestaRocks\Compat\PriceFormatter::format() in tutti gli oltre 140 moduli, e il wrapper rileva la versione di PS e chiama l'API corretta. Quando PS 9.2 rimuoverà qualcos'altro, aggiorneremo il wrapper una volta, sincronizzeremo, e ogni modulo sarà coperto.

Fase 5: test a matrice in CI

Ogni ZIP di modulo viene testato su PrestaShop 1.7.6, 1.7.7, 1.7.8, 8.0, 8.1, 9.0 e 9.1, e su ciascuna versione contro PHP 8.1, 8.2, 8.3 e 8.4. Lo facciamo su container Docker dedicati (ps176-dev, ps178-dev, ps8-dev, ps9-dev) sulla nostra infrastruttura, avviando container temporanei per specifiche versioni minor quando serve. Un singolo ZIP di modulo funziona su ogni combinazione perché il modulo ramifica su _PS_VERSION_ a runtime, non perché distribuiamo build multiple.

Fase 6: verifica sui temi Hummingbird e Classic

Ogni modulo con output front end viene renderizzato su entrambi i temi prima del rilascio. Quando i template dovevano differire (ed è successo in alcuni casi, soprattutto intorno agli attributi data-bs-* e ai componenti form) usiamo l'helper di versione di PrestaShop per scegliere il template corretto. Il commerciante non vede nulla di tutto questo: i suoi views/templates/hook/*.tpl funzionano semplicemente sul tema che ha.

Dove siamo rimasti rigorosi

Una manciata dei nostri moduli tocca aree che PS 9 ha riprogettato a livello di framework: schede prodotto nel back office, contesto multi-negozio, bridge AdminAPI. Per quelli abbiamo testato manualmente ogni singolo percorso funzionale su PS 9.0 e 9.1 prima di attivare il flag di compatibilità. Non dichiariamo compatibilità perché la categoria sembra sicura; la dichiariamo perché il modulo ha funzionato end-to-end sulla versione indicata.

Il risultato: ogni modulo del catalogo mypresta.rocks si installa e funziona su PS 9.0 e 9.1 dallo stesso ZIP che funziona su 8.x e 1.7.6+. Nessuna edizione separata, nessun costo di migrazione.

Cosa può andare storto dopo un aggiornamento riuscito

Anche con moduli confermati dal fornitore, questo è il pattern dei problemi post-aggiornamento che vediamo, più o meno nell'ordine in cui compaiono.

Errore 500 dopo l'installazione di un singolo modulo

Quasi sempre una dipendenza Composer mancante nella cartella vendor del modulo. Il log errori PHP dirà "Class not found" con un nome riconoscibile: di solito GuzzleHttp\Client, Swift_Mailer o una classe Symfony Messenger. Aggiorna il modulo oppure, se il fornitore è lento, inserisci manualmente la libreria mancante nel vendor/ del modulo (lo abbiamo fatto su negozi cliente per mantenerli operativi mentre aspettavamo una correzione vera).

La pagina di amministrazione si carica, ma la funzione è morta in silenzio

È il problema degli hook rimossi. Il modulo si è installato, la pagina di configurazione viene renderizzata, ma l'hook da cui dipendeva la funzionalità non viene mai eseguito. Controlla l'install() del modulo rispetto all'elenco degli hook rimossi in PS 9. La correzione è un aggiornamento del fornitore: nessun workaround lato cliente può far tornare un hook rimosso.

Il front end è rotto su Hummingbird, ma corretto su Classic

Deriva delle classi da Bootstrap 4 a 5. I template del modulo usano .no-gutters, .custom-checkbox, data-toggle o altro markup BS4. Workaround temporaneo: passa il negozio al tema Classic mentre aspetti. Correzione reale: aggiornamento dei template da parte del fornitore.

Errori JavaScript nella console

O il modulo si aspetta jQuery e jQuery non è caricato, oppure i selettori puntano a vecchi nomi di classe ora spostati su data-ps-*. $ is not defined in console è l'indizio classico. Nel breve periodo puoi caricare jQuery manualmente nel tema; nel lungo periodo il modulo deve passare a vanilla JS.

Le email smettono semplicemente di partire

Il modulo invoca SwiftMailer direttamente invece di passare da Mail::Send() di PrestaShop. PS 9 non ha SwiftMailer da istanziare. Non esiste una correzione lato cliente: serve che il modulo venga aggiornato a Symfony Mailer.

PrestaShop 9.1, le novità extra da conoscere

Se salti la 9.0 e vai direttamente alla 9.1 (sensato: è lì che finirai comunque), la 9.1 ha aggiunto le proprie breaking change sopra la 9.0:

• Theme::getDefaultTheme() non restituisce più "classic" in modo hard-coded. I moduli che davano per scontato Classic come tema predefinito nella logica di fallback possono comportarsi male.
• L'hook displaySearch è sparito da Hummingbird: causava conflitti di rendering sulle pagine 404. I moduli che usano displaySearch per personalizzare la ricerca front end devono usare un hook diverso.
• Le versioni di D3 e NVD3 sono state aggiornate. Se un widget dashboard era legato a una specifica API D3, può renderizzare in modo errato sulla 9.1.
• I selettori JavaScript sono passati da basati su classi a data-ps-*. Qualsiasi querySelector('.something') sul DOM interno di PrestaShop potrebbe smettere di trovare corrispondenze.

La checklist pre-aggiornamento che usiamo sui negozi cliente

1. Fai l'inventario di ogni modulo installato con fornitore e versione
2. Controlla il changelog di ogni fornitore per una voce esplicita 9.0/9.1 datata dopo il rilascio di PS 9
3. Aggiorna ogni modulo alla versione più recente prima di aggiornare PrestaShop stesso
4. Prepara un ambiente di staging con una copia fresca del database di produzione
5. Installa PS 9.1 in staging, direttamente alla 9.1, non passando dalla 9.0
6. Installa i moduli in ordine di dipendenza, seguendo i log dopo ciascuno
7. Esegui la funzionalità reale di ogni modulo: ordini, importazioni, esportazioni, sitemap, email
8. Renderizza il front end sul tema che userai in produzione
9. Inserisci un ordine di test completo e reale attraverso la procedura di pagamento, inclusa la conferma del pagamento
10. Leggi il log errori PHP alla ricerca di avvisi di deprecazione: sono futuri errori fatali
11. Verifica che ogni modulo che invia email abbia effettivamente inviato la propria email
12. Esegui un backup completo (database, file, configurazione) e conservalo per oltre 30 giorni dopo l'aggiornamento
13. Pianifica l'aggiornamento live nella finestra con meno traffico disponibile per il tuo negozio
14. Tieni a portata di mano il backup 8.x per almeno un mese. Il rollback deve restare possibile finché non sei certo

Conclusione

PS 9 è un vero miglioramento una volta adottato: Symfony 6.4 è davvero più veloce, Hummingbird è davvero più leggero di Classic e l'AdminAPI apre pattern di integrazione che il Webservice legacy non può raggiungere. Nulla di tutto questo ti aiuta se l'aggiornamento rompe i moduli su cui gira il tuo negozio.

La migrazione è fattibile. Non è un lavoro da weekend, e "compatibile" è una parola che dovresti chiedere ai fornitori di dimostrare con dettagli concreti. Noi abbiamo fatto il lavoro su tutto il catalogo, sulla nostra infrastruttura, contro le versioni reali di PrestaShop che dichiariamo, perché ogni negozio che usa i nostri moduli prima o poi aggiorna, e preferiamo fare il lavoro una volta piuttosto che rispondere per sempre a ticket di supporto.

Se vuoi moduli in cui il lavoro per PS 9 è già stato fatto (stesso ZIP, tutte le versioni PS, nessun costo di aggiornamento), parti dal catalogo mypresta.rocks. Se vuoi una mano a valutare lo stack esistente, scrivici.

Domande frequenti

Qual è la differenza tra "si installa su PS 9" e "compatibile con PS 9"?
L'installazione non dimostra quasi nulla. Su PS 9 un modulo può installarsi senza errori, renderizzare la pagina di configurazione e restare comunque rotto in silenzio: perché la libreria di cui ha bisogno (Guzzle, SwiftMailer, Tactician) non è più nel core e va in errore fatale solo quando viene eseguito il percorso di codice interessato, oppure perché si è registrato su uno degli hook rimossi da PS 9 e la funzione semplicemente non scatta mai. "Compatibile" dovrebbe voler dire che il modulo ha svolto il suo lavoro reale end-to-end, un ordine inserito, un'email inviata, una sitemap generata, sulla versione dichiarata, non che l'installer non ha dato errore.

Posso fidarmi di un badge "compatibile con PrestaShop 9" sulla homepage di un fornitore?
Non da solo. Cerca una voce di changelog datata dopo il rilascio di PrestaShop 9 che menzioni lavoro reale su 9.x: controller Symfony 6.4, test PHP 8.1+, sostituzione degli hook rimossi. Se l'aggiornamento più recente è del 2023 e il testo marketing punta ancora su "compatibile con 1.7", il modulo probabilmente è abbandonato e il sito non si è ancora aggiornato. La domanda migliore da fare a uno sviluppatore è se ha migrato da FrameworkBundleAdminController; se non lo riconosce, hai imparato qualcosa.

Perché testare specificamente su 9.1 e non solo su 9.0?
Perché la 9.1 ha aggiunto le proprie breaking change sopra la 9.0: Bootstrap 5.3.3, l'hook displaySearch rimosso da Hummingbird, Theme::getDefaultTheme() che non restituisce più "classic" in modo hard-coded, e il passaggio verso i selettori data-ps-*. Un modulo verificato solo su 9.0 è testato a metà per la versione che i commercianti stanno installando davvero. Vai direttamente alla 9.1 in staging invece di passare dalla 9.0.

Uno dei miei moduli invia email e ha smesso di funzionare dopo l'aggiornamento. Perché?
Quasi certamente perché chiamava SwiftMailer direttamente, e PS 9 non lo include più. La correzione è un aggiornamento del fornitore a Symfony Mailer: non esiste un workaround lato cliente affidabile. Due trappole correlate: la crittografia SMTP solo SSL è sparita in PS 9 (restano solo TLS o nessuna), quindi un relay configurato per SSL smette di funzionare in silenzio; e il modulo che passa dal Mail::Send() di PrestaShop invece di istanziare Swift da solo è quello che continua a funzionare.

Mi serve un'edizione separata "PrestaShop 9" di un modulo?
Non dovrebbe. Un modulo ben costruito distribuisce un singolo ZIP che ramifica su _PS_VERSION_ a runtime, così lo stesso download si installa su 1.7.6+, 8.x e 9.x. Se un fornitore ti consegna una build separata per PS 9, è una trappola di manutenzione per qualsiasi negozio che gestisce più versioni di PrestaShop, e di solito segnala che la compatibilità è stata aggiunta a posteriori invece di essere progettata.

Articoli correlati

• PrestaShop 1.7 vs 8 vs 9: quale versione dovresti usare?
• PrestaShop 9: cosa è cambiato sotto il cofano e come preparare i tuoi moduli
• Cosa ha cambiato PrestaShop 9 e perché la compatibilità dei moduli conta
• PrestaShop 9.1: Hummingbird 2.0, spedizione multi-corriere e perché adesso è il momento di aggiornare