Blog
Aggiornamento di un modulo PrestaShop alla versione PrestaShop 9: cosa non ha funzionato e come l'abbiamo risolto
Block Sliding Cart è uno dei moduli più datati del nostro catalogo. È stato inserito per la prima volta su PrestaShop Addons nel 2013 e per anni ha funzionato senza problemi. Poi è arrivato PrestaShop 8, non siamo riusciti a stare al passo con i tempi e nel 2023 l’inserzione è stata disattivata.
Nel 2026 abbiamo ripristinato la soluzione: un unico codice base per PrestaShop 1.7, 8 e 9, il tema Classic e Hummingbird. Ecco l’elenco dei problemi effettivamente riscontrati lungo il percorso e delle relative soluzioni. Se state pianificando un aggiornamento a PrestaShop 9, la maggior parte di questi problemi riguarderà anche i vostri moduli.
Versione breve: Il lato PHP ha richiesto meno modifiche del previsto. La maggior parte del tempo è stata dedicata al nuovo tema predefinito e al superamento della validazione degli add-on, dove un semplice avviso su una versione di PrestaShop può far fallire l'intera revisione.
1. PHP: cosa è stato rimosso o spostato nella versione PrestaShop 9
Tools::displayPrice() non c'è più
Il modulo ha formattato i prezzi con sette cifre, utilizzando Tools::displayPrice(). Il metodo era ormai obsoleto da tempo e PrestaShop 9 lo ha finalmente rimosso, quindi ognuna di quelle chiamate ha generato un errore irreversibile.
La sostituzione viene effettuata dalla locale corrente, che conosce già il formato della valuta del negozio. Abbiamo raggruppato entrambi i percorsi in un unico helper, in modo che il resto del modulo non debba mai preoccuparsi della versione di PrestaShop su cui viene eseguito:
public function formatPrice($price)
{
if (method_exists('Tools', 'displayPrice')) {
// PrestaShop 1.7 / 8: keep the old behaviour
return Tools::displayPrice((float) $price);
}
$locale = $this->context->getCurrentLocale();
$isoCode = isset($this->context->currency) ? $this->context->currency->iso_code : '';
return $locale->formatPrice((float) $price, $isoCode);
}I template utilizzano lo stesso helper tramite un piccolo modificatore Smarty registrato dal modulo, quindi {$price|scdisplayprice} funziona su tutte le versioni.
Le classi Presenter hanno cambiato namespace
Il modulo visualizza il carrello utilizzando lo stile proprio di PrestaShop CartPresenter, quindi i prezzi, gli sconti e i nomi dei prodotti appaiono esattamente come nel resto del negozio. Tra l'1.7 e l'8 quella classe si è spostata da Adapter\Cart a Adapter\Presenter\Cart. Invece di class_alias trucchi, il modulo risolve il nome della classe una sola volta:
private function getCartPresenterClass()
{
return class_exists('PrestaShop\\PrestaShop\\Adapter\\Presenter\\Cart\\CartPresenter')
? 'PrestaShop\\PrestaShop\\Adapter\\Presenter\\Cart\\CartPresenter'
: 'PrestaShop\\PrestaShop\\Adapter\\Cart\\CartPresenter';
}Lo stesso schema si applica ai presentatori di prodotti utilizzati per il cross-selling. Un altro dettaglio: su PrestaShop 8 e 9 present() restituisce un oggetto array "lazy", non un array semplice, quindi i suggerimenti sul tipo che indicano array è necessario consentire ArrayAccess anche.
Esecuzioni dell'analisi statica su PrestaShop 9
Il validatore degli add-on esegue PHPStan sul codice sorgente di PrestaShop 9. Una chiamata che è perfettamente sicura in fase di esecuzione, poiché si trova dietro un method_exists() Il controllo continua a segnalare un “richiamo a un metodo non definito”. Abbiamo riprodotto il validatore in locale (PHPStan con un bootstrap che carica i sorgenti PrestaShop 8 e 9) in modo da poter verificare ogni correzione in pochi minuti, invece di dover attendere un’altra revisione.
2. Hummingbird: quattro bug comparsi solo nel nuovo tema
Hummingbird è il tema predefinito di PrestaShop 9 (codice sorgente su GitHub). Nessuno degli elementi riportati di seguito è emerso dall'analisi statica né su PrestaShop 8 con il tema Classic. Tutti e quattro sono stati individuati navigando in un vero negozio PrestaShop 9.
I livelli a cascata dei CSS hanno trasformato l'elenco del carrello in una griglia
Hummingbird definisce lo stile del .products classe come griglia a due colonne all'interno @layer ps-components. Il nostro elenco del carrello utilizzava lo stesso nome di classe per motivi di compatibilità, quindi nel pannello laterale i prodotti si sono improvvisamente disposti in due colonne strette. Aumentare la specificità non è d’aiuto contro i livelli nel modo consueto; ciò che funziona è che il CSS non a livelli ha la precedenza su quello a livelli. Una breve regola non a livelli nel foglio di stile del modulo ha risolto il problema:
#sclist .products,
#sclist .product_list_widget {
display: block;
grid-template-columns: none;
}Il modal del carrello del tema richiede un proprio markup
Il modulo apriva il popup “aggiunto al carrello” tramite prestashop.blockcart.showModal. Hummingbird sostituisce tale funzione con una propria versione, che cerca un elemento con data-ps-ref="blockcart-modal" e genera un errore quando gli viene fornito un codice HTML diverso. La soluzione è stata quella di utilizzare sempre il renderer modale del modulo stesso invece di quello del tema.
Un riferimento a un elemento non aggiornato nell'animazione “aggiungi al carrello”
L'animazione memorizzava l'icona del carrello quando si cliccava sul pulsante e ne leggeva la posizione 250 ms dopo. Su Hummingbird l'intestazione del carrello viene ridisegnata nel frattempo, quindi l'elemento memorizzato non era più presente nella pagina e offset() restituito undefined. Il modulo ora cerca nuovamente l'icona nel momento in cui ne ha bisogno e salta l'animazione se il tema non dispone di un'icona del carrello accessibile. Il pannello stesso si apre comunque in entrambi i casi.
Un pulsante fisso che fuoriesce dal pannello sui dispositivi mobili
Sui telefoni, il pulsante di pagamento è position: fixed nella parte inferiore del pannello laterale. Un elemento fisso viene posizionato rispetto all'elemento padre più vicino con un transform — e il pannello ne ha solo uno quando è aperto. Quando il pannello era chiuso, il pulsante si agganciava alla finestra di visualizzazione e rimaneva in sospeso nella parte inferiore di ogni pagina. Limitando l'ambito della regola allo stato aperto (.sc-widget-panel-open) l'ho risolto.
3. Verifica dei componenti aggiuntivi: cosa viene effettivamente controllato durante la revisione
Per far sì che un modulo venisse nuovamente inserito nell'elenco, era necessario seguire la procedura Validatore PrestaShop e poi una verifica di conformità che prevede l'installazione del modulo su diverse versioni di PrestaShop con la modalità di debug attivata. Questi sono stati gli aspetti che hanno richiesto più tempo.
Ogni variabile Smarty deve essere sottoposta a escape
I modelli più vecchi si basavano sull'escape automatico. La revisione ora considera qualsiasi output non sottoposto a escape come un problema che impedisce il rilascio. Abbiamo esaminato tutti e sette i modelli del front-office: |escape:'html':'UTF-8' per il testo, gli URL e gli attributi, |intval per i codici e le quantità, |escape:'javascript':'UTF-8' all'interno degli script inline.
nofilter viene segnalato come un problema di sicurezza, anche quando è giustificato
Il modulo consente al proprietario del negozio di incollare il proprio codice HTML per l'icona (un tag Font Awesome o un file SVG). L'output utilizzato nofilter, con un commento che ne spiegava il motivo. Il revisore l'ha segnalata comunque. La soluzione accettata era un modificatore Smarty personalizzato che pulisce il codice HTML — rimuove <script> e <style> blocchi, gestori di eventi inline e javascript: URL — quindi il modello non ha più bisogno di nofilter per niente.
Nessun codice HTML all'interno del codice PHP
Un piccolo pannello di supporto nella pagina di configurazione era stato realizzato come stringa HTML in PHP. È stato spostato in un proprio template di amministrazione. Un problema: su PrestaShop 8.1 la politica di sicurezza di Smarty per l'amministrazione blocca un raw $this->context->smarty->fetch() di un file nella cartella del modulo. Utilizza invece la risorsa del modulo:
$output .= $this->fetch('module:yourmodule/views/templates/admin/support.tpl');Un avviso in modalità debug può comportare il rifiuto della revisione
Ci sono voluti tre tentativi. Il rapporto di conformità indicava che non era possibile accedere alla pagina di configurazione su PrestaShop 8.1 e 9.0, senza che venisse visualizzato alcun messaggio di errore. La causa si è rivelata essere un unico avviso: Undefined array key "is_default" nel modello HelperForm. Language::getLanguages() Se non restituisce quella chiave, il modello del modulo la legge per ogni lingua e la modalità di debug rigorosa della revisione trasforma quell’avviso in un errore di pagina. In un negozio di prova normale con la modalità di debug attiva, viene visualizzato solo come avviso, motivo per cui era facile non notarlo.
$languages = Language::getLanguages(false);
$idDefaultLang = (int) Configuration::get('PS_LANG_DEFAULT');
foreach ($languages as $k => $lang) {
$languages[$k]['is_default'] = ((int) $lang['id_lang'] === $idDefaultLang) ? 1 : 0;
}La lezione da trarre: prima di inviare i dati, apri la pagina di configurazione su PrestaShop 8 e 9 con la modalità debug attivata e considera ogni avviso come un errore.
Standard di codifica, con un conflitto
Il validatore applica le regole di PHP-CS-Fixer. Due dettagli ci sono costati un nuovo invio ciascuno: in un file privo di namespace, scrivere catch (Throwable $e), non \Throwable; e mantenere il docblock della licenza subito dopo <?php, senza righe vuote. Una configurazione generica di PHP-CS-Fixer tenterà di inserire quella riga vuota, quindi è consigliabile applicare le regole del validatore, anziché un’impostazione predefinita generica.
Una lista di controllo per i propri moduli prima dell'aggiornamento a PrestaShop 9
- Prova la nostra versione gratuita Verifica di compatibilità PrestaShop 9 nel modulo. Elenca le classi, i metodi e i hooks rimossi, di cui si parlerà nei punti seguenti, indicando il file e la riga.
- Cerca nel codice
Tools::displayPricee altri metodi rimossi nella versione 9.0 (il Documentazione per sviluppatori PrestaShop 9 (elenca le modifiche). - Cerca le classi a cui si fa riferimento tramite i loro vecchi spazi dei nomi, in particolare i presenter e gli adattatori.
- Installa il modulo su una copia PrestaShop 9 con la modalità debug attivata e apri la pagina di configurazione. Leggi tutte le note.
- Prova il tema front office sul tema Hummingbird, non solo nella versione Classic: popup, carrello nell’intestazione, elenchi dei prodotti e layout per dispositivi mobili.
- Verifica che nei modelli non siano presenti variabili non precedute dal carattere di escape e
nofilter. - Verifica l'intervallo di compatibilità dichiarato dal modulo. Dovrebbe corrispondere alle versioni che hai effettivamente testato.
Dove si trova ora il modulo
Block Sliding Cart funziona su PrestaShop 1.7, 8 e 9, ha superato la convalida degli add-on ed è nuovamente presente nell'elenco, con la cronologia e le 36 recensioni (4,7★) intatte. È possibile guarda come funziona qui, mentre i motivi alla base dell'utilizzo di un carrello AJAX sono illustrati in Carrello AJAX vs ricaricamento della pagina e Esperienza utente (UX) del carrello mobile per PrestaShop.
Se un modulo del tuo negozio ha smesso di funzionare dopo un aggiornamento, oppure se vuoi sapere cosa potrebbe smettere di funzionare prima di procedere all'aggiornamento, questo è proprio il tipo di lavoro di cui ci occupiamo. Dicci qual è il problema e vi risponderemo con delle domande o un preventivo.
Domande frequenti
È Tools::displayPrice() rimosso nella versione PrestaShop 9?
Sì. Utilizza invece le impostazioni regionali correnti: $this->context->getCurrentLocale()->formatPrice($price, $currencyIsoCode). Se il tuo modulo deve supportare anche PrestaShop 1.7, inserisci entrambi i percorsi all’interno di un unico metodo di supporto.
I moduli PrestaShop 1.7 funzionano su PrestaShop 9?
Alcuni funzionano senza modifiche. I moduli che utilizzano metodi del core rimossi, vecchi spazi dei nomi delle classi o codice JavaScript specifico del tema necessitano di aggiornamenti. L'installazione del modulo su una copia di PrestaShop 9 con la modalità debug attivata mette in evidenza la maggior parte dei problemi nel giro di pochi minuti.
Perché il mio modulo sembra non funzionare correttamente su Hummingbird ma funziona su Classic?
Hummingbird utilizza un codice di marcatura diverso, livelli CSS a cascata e un proprio codice JavaScript per il carrello. I moduli che riutilizzano i nomi delle classi di Classic o che richiamano le funzioni del carrello del tema sono quelli più colpiti.
Perché la verifica di conformità dei componenti aggiuntivi non supera il controllo della pagina di configurazione?
La recensione prevede l'installazione del modulo su diverse versioni di PrestaShop con la modalità di debug impostata su “rigorosa”, in cui avvisi del tipo "chiave dell'array non definita" causano il malfunzionamento della pagina. Apri tu stesso la pagina di configurazione su PrestaShop 8 e 9 con la modalità di debug attivata e risolvi ogni avviso prima di inviare.