PrestaShop 9.2: le novità per chi gestisce e per chi sviluppa

PrestaShop 9.2 porta un checkout in una sola pagina, un assistente AI dentro il back office e un modo nativo per aggiungere campi personalizzati a qualsiasi entità. Sotto il cofano c’è anche parecchio lavoro per chi sviluppa moduli.

Ho letto con calma gli articoli ufficiali, la documentazione per sviluppatori e il changelog. Mi è sembrato che le novità siano di due famiglie. Alcune le vede subito chi gestisce lo shop, come il checkout e Ask AI. Altre lavorano sotto e cambiano il modo di costruire moduli, come le Extra Properties e i nuovi hook. Qui le trovi tutte, con il modo in cui funzionano e, in fondo, le cose che controllerei prima di aggiornare. Se cerchi la procedura, c’è la guida per aggiornare PrestaShop 9.

Se preferisci guardare, qui sotto trovi il video in cui Amelia, l’avatar di bwlab, racconta le tre novità principali in meno di tre minuti. Il video parte solo quando premi play. Lo trovi anche su YouTube.

In sintesi

• Il One Page Checkout è nativo: contatto, consegna, corriere e pagamento stanno in una pagina, e per comprare come ospite basta l’email.
• Ask AI è un assistente conversazionale nel back office, appoggiato al server MCP di PrestaShop, con il fornitore AI che scegli tu (Gemini, Anthropic, OpenAI o Mistral). Lo stesso server MCP permette anche a un modello esterno di collegarsi allo shop.
• Le Extra Properties permettono di aggiungere campi a prodotti, clienti, ordini e altre entità senza override e senza tabelle scritte a mano.
• La modalità B2B migliorata ha le fondamenta (aziende, profili, indirizzi, ruoli), ma è in fase iniziale e dietro feature flag.
• Altre pagine del back office passano a Symfony: Paesi, Resi, Hook a module, Accesso rapido, Traduzioni email e Regole di tassazione.
• Per gli sviluppatori ci sono 45 hook nuovi, i servizi del modulo in PHP, i dati strutturati gestiti dal core e nuovi comandi da console.

Il checkout in una pagina

Finora PrestaShop offriva di serie solo il checkout in più passaggi, con la pagina che si ricarica a ogni step. Chi voleva una pagina unica doveva comprare un modulo di terze parti. Con la 9.2 arriva ps_onepagecheckout, un modulo nativo già incluso nel pacchetto.

Si attiva dal back office, in Design > Checkout: scegli il layout “One-page checkout” e salvi. Il modulo è installato ma non parte da solo. Dalla stessa schermata puoi tornare al checkout in quattro pagine quando vuoi, quindi il vecchio flusso non sparisce.

Il modulo è compatibile solo dalla 9.2. Se nel tuo shop 9.2 non lo trovi, scarica il file ps_onepagecheckout.zip dalle release su GitHub e caricalo dal pulsante “Carica un modulo” in Moduli, Gestione moduli. Il percorso passo passo, con il video di Amelia, è nell’articolo Checkout rapido di PrestaShop 9.2: come si attiva e come funziona.

La parte che mi interessa di più è l’acquisto come ospite. Nel checkout classico l’ospite attraversava comunque gli stessi passaggi, con indirizzo e dati dell’account chiesti subito. Qui gli basta l’indirizzo email per iniziare e il resto viene raccolto strada facendo. C’era un problema tecnico da risolvere: nel checkout in più pagine ogni step inviava un modulo, e così i dati parziali dei clienti finivano nel sistema per il recupero dei carrelli abbandonati. In una pagina sola non si invia niente fino alla fine, quindi il modulo salva in background le informazioni minime per non perdere quella funzione.

Sulla schermata compaiono insieme contatto, indirizzo di consegna, corriere e pagamento. Le sezioni che dipendono da altre restano disattivate finché non servono: i corrieri si sbloccano quando c’è un indirizzo di consegna, e i metodi di pagamento possono dipendere dall’indirizzo di consegna o da quello di fatturazione, a seconda della configurazione. Tutto avviene in AJAX. Se il cliente cambia indirizzo, l’elenco dei corrieri si aggiorna sul posto, e se sceglie un corriere cambiano i totali e i metodi di pagamento, senza ricaricare la pagina.

Due dettagli che sistemano vecchie incoerenze. Se nel carrello ci sono solo prodotti virtuali o scaricabili, spariscono indirizzo di spedizione e scelta del corriere e si chiede solo l’indirizzo di fatturazione. Login e registrazione, poi, stanno in pagine dedicate fuori dal checkout, che resta concentrato sull’acquisto.

Per il tema, il modulo porta i suoi template e prende il controllo del rendering tramite l’hook displayOverrideTemplate. Su un tema derivato da Hummingbird funziona subito. I temi Classic non sono supportati di default e potrebbero richiedere l’override di alcuni template. Nei negozi multistore la scelta è per singolo negozio, quindi puoi tenere il checkout in una pagina su una vetrina e quello classico su un’altra.

Chi sviluppa moduli di pagamento o di spedizione deve tenere a mente che il checkout ora si aggiorna in AJAX. I moduli che inseriscono contenuto nelle sezioni di corriere o pagamento devono rigenerarlo dopo ogni aggiornamento. Il modulo mantiene gli hook già esistenti del checkout classico e aggiunge eventi JavaScript sul bus prestashop.emit(), tra cui opcCarriersUpdated, opcPaymentMethodSelected e opcDeliveryAddressSelected. I moduli di pagamento che gestiscono da soli l’invio (pulsanti smart, campi ospitati, redirect) devono chiamare window.ps_onepagecheckout.submitBeforePayment() prima di partire, così i dati del checkout sono già salvati.

Le guide ufficiali sono due: una per gli sviluppatori di moduli e una per gli sviluppatori di temi. L’articolo di presentazione racconta le scelte di progetto.

L’hook che apre il checkout ai moduli

Per far vivere il checkout in una pagina come modulo, il core ha ricevuto un hook nuovo, actionCheckoutBuildProcess. Un modulo può restituire un proprio checkout process provider. Il core lo usa al posto del flusso standard solo se, tra tutti i moduli, esiste esattamente un provider attivo e valido. Se ce ne sono zero o due, ricade sul checkout nativo.

Per chi personalizza il tunnel d’ordine è una buona notizia: si può farlo senza override e con una regola chiara quando due moduli si contendono lo stesso posto.

Ask AI nel back office

Ask AI è un assistente conversazionale integrato nel back office. Invece di girare tra i menu, fai domande sui dati del negozio e chiedi azioni in linguaggio naturale. Si apre un pannello dentro il back office, oppure una conversazione a schermo intero, e risponde partendo dai dati reali dello shop.

Funziona tramite il server MCP di PrestaShop (Model Context Protocol), quindi non sei legato a un solo fornitore: collegi il tuo con la tua chiave API. Prima di agire sul negozio chiede l’approvazione. È incluso nell’edizione Classic, il pacchetto completo che scarichi dal sito ufficiale.

La scelta di non legarsi a un fornitore mi sembra la parte più sensata: chi ha già un contratto con un provider AI lo può riusare.

Come è fatto dentro

Nel pacchetto Classic i moduli sono tre, e conviene distinguerli:

• ps_ask_ai è l’assistente che vedi nel back office. Nel codice i fornitori previsti sono quattro: Gemini, Anthropic (Claude), OpenAI e Mistral. Ne è attivo uno solo alla volta, e la chiave si salva dal back office o si passa con una variabile d’ambiente.
• ps_mcp_server pubblica sul negozio un endpoint MCP, cioè il punto a cui si collega un modello per parlare con lo shop. Il modulo limita le richieste a 100 al minuto per indirizzo IP.
• ps_mcp_tools contiene gli strumenti che il modello può usare: 38 in totale, su prodotti (comprese le immagini), clienti, ordini, stock e lingue. Si possono leggere gli ordini per stato, per cliente o per metodo di pagamento, ma anche creare un prodotto, aggiornare un cliente o cambiare lo stato di un ordine.

Ask AI aggiunge strumenti suoi, che si intuiscono dai nomi dei file del modulo: categorie, pagine CMS, promozioni e prezzi specifici, regole carrello, magazzino, analisi dei ricavi, diagnostica SEO, configurazione del negozio, gestione dei moduli e generazione di immagini.

Un dettaglio pratico da non trascurare: Ask AI chiede l’accesso al negozio tramite il webservice di PrestaShop e dal suo pannello propone di attivarlo. Che un assistente possa modificare ordini e prodotti è utile, ma è anche una decisione di sicurezza, quindi vale la pena capire con chiarezza cosa si concede e a quale utente, prima di accenderlo su uno shop in produzione.

Insieme ad Ask AI, la distribuzione Classic torna a includere il modulo PrestaShop Automation with Klaviyo, per l’automazione di email e SMS marketing basata sui dati del negozio.

Extra Properties: campi personalizzati nativi

Aggiungere un dato a un prodotto, a un cliente o a un ordine (un riferimento ERP, una nota interna, un link a un video) ha sempre voluto dire tabelle proprie, relazioni scritte a mano e la stessa logica di salvataggio ripetuta in ogni modulo, oppure un override. Le Extra Properties sostituiscono tutto questo con un punto di estensione unico.

Un modulo registra una proprietà su un’entità: Product, Combination, Customer, Order, Category e altre. Ogni proprietà ha un tipo, regole di validazione, un valore predefinito, etichette traducibili e una visibilità. Una volta registrata compare da sola nei form e nelle griglie del back office, nel front office e nell’Admin API. I tipi sono intero, booleano, stringa, decimale, data, HTML, JSON e lista di scelte, e ognuno corrisponde a una vera colonna SQL, non a una tabella chiave-valore generica. Per questo si può indicizzare, filtrare e ordinare.

Il valore può avere tre ambiti, pensati per multilingua e multinegozio: common è un valore unico per tutti, lang ne ha uno per ogni lingua e shop ne ha uno per ogni negozio.

Nel back office i campi compaiono nei form (in una scheda “Extra fields” o in una posizione precisa) e nelle griglie come colonne filtrabili. Nel front office si leggono da PHP e da Smarty, senza query se il dato non viene richiesto (caricamento lazy), e un campo si può nascondere alla vetrina. Nell’Admin API finiscono nel nodo extraProperties, raggruppato per modulo e con gli stessi permessi dell’entità.

$product = new Product($productId);
$isDangerous = $product->extra_properties['mio_modulo']['is_dangerous'];

{$product.extra_properties.mio_modulo.video_link|escape:'htmlall':'UTF-8'}

I dati stanno in tabelle dedicate, per esempio product_extra, product_extra_lang e product_extra_shop, create solo quando servono. Le tabelle del core non vengono toccate. Le definizioni sono in un registro, extra_property_definition.

Si può anche fare senza scrivere codice. In Advanced Parameters > Extra Properties un commerciante o un integratore crea una proprietà dal back office. Queste proprietà appartengono al core, e in cancellazione si sceglie se eliminare solo la definizione o anche la colonna con i valori. Come si crea una proprietà, come si compila sul prodotto e cosa serve nel tema per mostrarla lo vedi passo per passo, con il video, nell’articolo sulle proprietà aggiuntive.

La validazione usa i vincoli di Symfony (per esempio NotBlank, Length, Email, Url, Iban) scritti in un piccolo linguaggio testuale, ed è applicata su ogni via di scrittura: salvataggio da codice, form del back office e API.

C’è un limite da conoscere. Nella 9.2 questo codice è segnato @experimental, quindi c’è margine per un cambio non retrocompatibile, ma solo se davvero inevitabile. Le Extra Properties sono nate da una collaborazione tra i team di PrestaShop e l’agenzia Kiwik. Un esempio completo è nel modulo demoextraproperty, e c’è l’articolo ufficiale.

Modalità B2B migliorata

La 9.2 mette le fondamenta di una modalità B2B nativa: entità aziendali, profili cliente B2B, identificativi aziendali, indirizzi B2B e accesso basato sui ruoli. Si attiva con il feature flag improved_b2b e poi con l’impostazione “modalità B2B” nelle impostazioni generali (esiste anche la modalità B2C).

Per ora la vedrei come un segnale di direzione. La documentazione ufficiale la descrive in pieno sviluppo, con schema del database e API che possono cambiare, e sconsiglia di costruirci sopra. La sviluppa Soledis insieme ai team di PrestaShop.

Altre pagine del back office passano a Symfony

Continua la migrazione delle ultime pagine legacy a Symfony. Non è la novità che fa più rumore, ma le pagine migrate usano routing, form e sicurezza di Symfony e sono più semplici da estendere. Ognuna ha il suo feature flag, che trovi in Advanced Parameters > New & Experimental Features. In un’installazione pulita della 9.2 risultano tutti già attivi, quindi la versione migrata è quella che vedi da subito.

Il feature flag tag, per la pagina dei tag, è passato a stabile. Se un tuo modulo modifica una di queste pagine con gli hook di griglia o di form, va provato sulla versione migrata. Nel corso della migrazione è arrivato anche un nuovo costruttore visivo (Vue 3) per il formato indirizzo dei paesi.

Ordini e spedizioni

Nel changelog c’è molto lavoro sulle spedizioni multiple di un ordine. Si può creare una spedizione su un ordine esistente, dividere e unire spedizioni, modificare le quantità per spedizione e cancellarle in modo logico. Le informazioni sulle spedizioni finiscono in fattura, la bolla di consegna compare nella scheda Documenti e le email supportano più spedizioni. Il costo di spedizione è stato rivisto come servizio, e ci sono nuovi endpoint dell’Admin API per i corrieri. Le spedizioni migliorate hanno un loro feature flag, improved_shipment, che in una installazione pulita risulta disattivato: va acceso a mano. Se nei tuoi ordini usi più corrieri, questa è l’area da guardare per prima.

Altre novità utili

Le condizioni del prodotto, oltre a nuovo, usato e ricondizionato, ora includono open_box, damaged e new_with_defects. I moduli che leggono o elencano la condizione vanno controllati.

I dati strutturati JSON-LD non si costruiscono più nei template: li fornisce il core e i moduli li aggiungono, sovrascrivono o rimuovono via hook (per esempio AggregateRating, MerchantReturnPolicy, ContactPoint). Un esempio è il modulo demoseo. Sono migliorati anche i dati con le caratteristiche del prodotto e i contatti del negozio.

Sul fronte SEO ci sono le rotte multilingua per le entità e l’indicizzazione predefinita delle nuove pagine CMS. Dopo un’installazione riuscita la cartella install viene rimossa da sola. Il supporto PHP va dalla 8.1 alla 8.5. La griglia ordini pagina prima per ID, per evitare l’ordinamento dell’intera tabella, e il trasporto SMTP sceglie TLS implicito in base alla porta, così funziona anche con la 587.

Per chi sviluppa

45 hook nuovi

Confrontando gli hook registrati nella 9.1.5 e nella 9.2 ne ho contati 45 in più. Quelli che mi sembrano più utili:

• actionCheckoutBuildProcess permette a un modulo di fornire il proprio checkout process provider, come descritto sopra.
• displayCartBelowSummary è uno spazio sotto i totali del carrello, buono per rassicurazioni, soglia di spedizione gratuita o upsell.
• displaySubcategories arricchisce l’elenco delle sottocategorie con articoli del blog, landing page o link trasversali.
• actionNotFound permette di reagire ai 404, per registrarli, reindirizzare o alimentare un modulo SEO. Non rientra nel conteggio perché era già disponibile dalla 9.1.5.

Gli altri sono quasi tutti hook di estensione del back office. Per le pagine Tax rules, Quick Access, Fulfill Shipment ed Extra Property Definition ci sono gli hook di form: builder, data provider, dati di default, prima e dopo la creazione e l’aggiornamento. Per le griglie Email body template ed Extra property definition ci sono quelli di definition, query builder, dati, filtri e presenter. Aggiungono poi le opzioni delle pagine Paesi (actionCountriesPageOptionsForm e actionCountriesPageOptionsSave) e Resi (actionOrderReturnForm e actionOrderReturnSave).

Nel complesso servono meno override, e i moduli dovrebbero reggere meglio gli aggiornamenti di versione.

Servizi del modulo in PHP

Un modulo può dichiarare i servizi Symfony in un file PHP e in file YAML specifici per versione, oltre a services.yml. L’ordine di caricamento è config/services.php, poi config/services-9.2.yml, poi config/services-9.yml, infine config/services.yml. I moduli che usano solo services.yml continuano a funzionare.

Nuovi comandi da console

prestashop:module:list elenca i moduli con nome, versione e stato, con filtri e un formato semplice per le pipeline. prestashop:employee:create-admin e prestashop:employee:change-password creano un SuperAdmin o reimpostano una password da terminale, utili per i recuperi e per la CI. prestashop:htaccess:generate rigenera il file .htaccess senza passare dal back office.

Una cosa rassicurante: la 9.2 è una versione minore e la politica ufficiale è mantenere la retrocompatibilità con la 9.1. Le rotture sono ammesse solo se inevitabili.

Cosa controllerei prima di aggiornare

Se attivi il checkout in una pagina, prova moduli di pagamento, corrieri e ogni personalizzazione del tunnel d’ordine. Se il tema non deriva da Hummingbird, metti in conto l’override dei template.

Controlla i moduli che agganciano griglie e form di Paesi, Resi, Accesso rapido, Regole di tassazione e Traduzioni email, perché ora lavorano sulle pagine migrate. Controlla anche moduli e feed che si aspettano solo tre valori per la condizione del prodotto.

La 9.2 modifica lo schema del database (Extra Properties, B2B, condizioni del prodotto): trovi tutto nel file 9.2.0.sql dell’autoupgrade. Verifica infine la versione di PHP sul server, visto che il supporto va da 8.1 a 8.5.

Per il quadro delle versioni e del loro supporto c’è la guida alle versioni di PrestaShop.

Se hai uno shop PrestaShop e vuoi capire se la 9.2 fa per te, con quali moduli e con quale tema, scrivi a bwlab: guardiamo insieme il tuo caso prima di toccare la produzione.