Ricerca Elasticsearch per PrestaShop: guida al modulo

Opzioni del motore

• Nativo (PrestaShop): nessun motore esterno e nulla da indicizzare. Il modulo cerca e filtra direttamente dal database di PrestaShop. Usalo per andare online subito e collegare un motore in seguito; lo store non resta mai senza una ricerca funzionante.
• Elasticsearch: supporta le versioni major 6, 7, 8 e 9 con rilevamento automatico della versione.
• OpenSearch: rilevato automaticamente e gestito come un cluster moderno senza tipi, a prescindere dalla versione 1.x/2.x/3.x.
• Meilisearch: un’alternativa leggera e facile da ospitare; i tuoi campi ricercabili, faccette, sinonimi, stop-word e tolleranza ai refusi vengono mappati automaticamente su Meilisearch.

Impostazioni di connessione

• Host: l’URL completo del tuo motore (può includere un prefisso di percorso, es. https://cluster.provider.com/my-space).
• Base path: un prefisso di percorso opzionale anteposto a ogni richiesta, per spazi di ricerca noleggiati su istanze condivise.
• Prefisso indice: un namespace che isola i tuoi indici, così più store possono condividere in sicurezza un unico motore. Una nuova installazione riceve un prefisso casuale tutto suo (ps_cll_ seguito da sei caratteri); un’installazione aggiornata da una versione precedente mantiene il suo.
• Autenticazione: per Elasticsearch/OpenSearch: HTTP Basic o API key; per Meilisearch: una chiave Bearer master o con ambito. Una volta salvate, password e chiave API non vengono più mostrate nella pagina: lascia il campo vuoto per mantenerle (per lo stesso server), scrivine una nuova per sostituirle, oppure spunta la casella per rimuoverle.
• Test connessione: verifica che il motore sia raggiungibile e ne riporta la versione rilevata.

Quanto costa restare in modalità “Nativo”, con numeri nostri

La modalità “Nativo” fa partire il negozio subito, ma su un catalogo grande il motore nativo di PrestaShop ha un costo reale che vale la pena conoscere prima di scoprirlo in produzione. La causa più comune non è “il database è lento”: è che lo stesso calcolo (quali prodotti soddisfano la ricerca corrente) viene rifatto da zero per ogni filtro invece di essere calcolato una volta e riusato, per cui il costo smette di essere proporzionale al numero di prodotti e diventa proporzionale al numero di prodotti moltiplicato per il numero di filtri.

Su un catalogo sintetico da 200.000 prodotti, con il solo motore nativo, una pagina di risultati di ricerca impiegava 28 secondi e una pagina di categoria grande 30 secondi prima di un lavoro mirato di ottimizzazione; dopo, la stessa pagina va tra i 2 e i 6 secondi. Restano secondi, non millisecondi: è il motivo pratico per cui, superata una certa dimensione di catalogo, collegare Elasticsearch, OpenSearch o Meilisearch smette di essere un lusso e diventa la scelta che tiene la pagina rispondente.

Presa in carico della ricerca del sito

Attiva Prendi in carico la ricerca del sito affinché ogni ricerca e listato di categoria sia servito dal motore tramite il provider prodotti nativo di PrestaShop, senza modifiche al tema. Se il motore diventa irraggiungibile, o risponde a un listato con un errore, il modulo ricade automaticamente sulla ricerca nativa, così lo store non mostra mai un errore. Un motore che smette di rispondere viene lasciato stare per 30 secondi prima di un solo controllo rapido, così un motore lento o bloccato non rallenta mai le pagine del negozio; le modifiche ai prodotti che nel frattempo non ha ricevuto le invia la chiamata successiva del cron. Se ps_facetedsearch è ancora attivo, la pagina di configurazione del modulo ti avvisa (con il pulsante “Non mostrare più questo avviso” per un negozio che lo tiene attivo di proposito), poiché di norma è meglio tenere attivo un solo modulo a faccette.

Gruppi di clienti, prezzi nascosti e codici esatti

Prodotti e categorie riservati ad alcuni gruppi di clienti restano riservati: il modulo applica la regola di PrestaShop (un prodotto si vede solo se una delle sue categorie attive è aperta a uno dei gruppi del cliente) a risultati di ricerca, filtri e loro conteggi, autocompletamento, scorciatoie per categoria, prodotti in evidenza e pagina senza risultati. Anche i prezzi seguono PrestaShop: un suggerimento mostra il prezzo, e il filtro prezzo compare, solo quando PrestaShop stesso mostrerebbe i prezzi a quel cliente. Una ricerca che è esattamente un riferimento, un EAN-13, un UPC o un MPN elenca solo i prodotti che lo portano.

Rilevanza e tuning

Il pannello delle impostazioni di ricerca ti permette di modellare la rilevanza senza toccare codice:

• Pesi dei campi: quanto contano nome, riferimento, descrizione, ecc. nel punteggio.
• Tipo di match e operatore: la strategia multi_match e se le parole si combinano con AND o OR.
• Fuzziness e minimum-should-match: quanto è tollerante ai refusi e quante parole devono corrispondere.
• Lunghezza minima parola e l’ambito dei campi ricercabili per tipo di documento. Un termine più corto non viene ignorato: i termini di due lettere come “tv” vengono cercati in modo esatto, senza tolleranza ai refusi.
• Analisi linguistica: sinonimi, stop-word, stemmer per lingua (con eccezioni), elisione, minuscolo e match infisso (n-gram) per le parole parziali.

Come funziona davvero la tolleranza ai refusi

Dietro l’interruttore “Fuzziness” ci sono in realtà due meccanismi diversi, con costi diversi. Con Elasticsearch e OpenSearch la corrispondenza fuzzy scatta al momento della ricerca: il motore confronta il termine cercato con i termini già indicizzati usando la distanza di edit (quante sostituzioni, inserimenti o cancellazioni servono per trasformare una parola nell’altra), senza bisogno di sapere in anticipo quali errori di battitura esistano. Con il motore nativo, che non calcola corrispondenze fuzzy in modo nativo, il modulo si appoggia invece a un dizionario a trigrammi costruito dai nomi di prodotto e di marchio del catalogo: i termini vengono indicizzati per frammenti di tre lettere, cosa che restringe l’elenco dei candidati plausibili prima di calcolare la distanza di edit esatta su un insieme molto più piccolo.

Il dettaglio che rende economico il dizionario, invece di rallentare ogni ricerca, è quando scatta: solo dopo che la ricerca esatta è già tornata a zero risultati. Una query scritta correttamente non lo tocca mai. Misurato su un catalogo reale, una query corretta e una scritta male che fa scattare il dizionario impiegavano lo stesso tempo, piccolo, in entrambi i casi (tra 0,16 e 0,19 secondi su quell’allestimento). Il dizionario viene anche ricostruito con una periodicità (per esempio ogni settimana, più un aggiornamento leggero quando una ricerca a zero risultati incontra una parola nuova), così resta allineato al catalogo mentre cambia.

Il pannello filtri modale moderno

• Sopra la griglia prodotti si trovano un pulsante “Filtri”, il conteggio risultati in tempo reale e i chip rimovibili per ogni valore applicato (“Cancella tutto” li rimuove tutti).
• Cliccando Filtri si apre un modal a due riquadri: i nomi dei filtri a sinistra (con un badge quando un filtro è in uso), i valori del filtro selezionato a destra e un pulsante “Mostra N risultati” in tempo reale nel footer.
• I filtri con molti valori sono raggruppati A→Z con una casella “cerca in questo filtro”; i colori sono resi come swatch; il prezzo mostra campi min/max più uno slider a doppio cursore.
• Su mobile il modal è a tutto schermo: tocca un nome di filtro per accedere ai suoi valori, usa la freccia indietro per tornare e conferma con la barra fissa in basso “Mostra N risultati”.
• Tutto si aggiorna via AJAX con URL condivisibili (avanti/indietro funzionano) ed è presente un fallback senza JavaScript, perché ogni controllo è un vero controllo di form.

Configurazione di ogni faccetta

Per ogni faccetta puoi controllare: on/off, ordine, etichetta per lingua, tipo di visualizzazione (checkbox, radio, dropdown, swatch colore per i gruppi colore, oppure uno slider per il prezzo, le misure e le caratteristiche numeriche), modalità AND/OR, se mostrare i conteggi, lo stato collassato, un limite di valori con “mostra altri” e nascondi se vuota. Sorgenti disponibili: categorie, brand, caratteristiche, attributi, prezzo, disponibilità, novità, offerta e condizione. Le faccette possono essere mostrate anche nella pagina dei risultati di ricerca e, con un interruttore, nelle pagine marca, fornitore, nuovi prodotti, offerte e più venduti, non solo nelle categorie. Su Elasticsearch e OpenSearch ogni gruppo di caratteristiche o attributi viene contato con le selezioni degli altri gruppi applicate, così scegliere un colore aggiorna anche i numeri accanto alle taglie (sul motore nativo e su Meilisearch ogni gruppo è ancora contato per conto suo).

Faccette: abilita, ordina, etichetta e imposta lo stile di ogni filtro (checkbox, radio, dropdown, swatch, slider) con AND/OR, conteggi e limiti

Template di filtri per categoria Filtri Pro

Un template di filtri è una configurazione di faccette riutilizzabile e con nome, che puoi assegnare a una o più categorie, così categorie diverse possono esporre un insieme di filtri diverso e riordinato. Nella scheda Template di filtri crei un template con lo stesso editor di faccette della configurazione globale, più un albero di categorie e un’opzione “applica anche alle sottocategorie”. La configurazione Faccette globale è il Template predefinito: il fallback per ogni categoria senza un template proprio, e per la pagina di ricerca.

Template di filtri: assegna un insieme di filtri diverso e riordinato a categorie specifiche; la riga Default è il fallback globale

Perché disattivare i conteggi conviene su cataloghi grandi

L’opzione “mostra i conteggi” di ogni faccetta (sopra) ha un costo che dipende dal motore. Con un motore esterno il conteggio arriva gratis, come sottoprodotto della stessa interrogazione che calcola i risultati: è il meccanismo di aggregazione del motore, non una query in più per ogni valore. Con il motore nativo, ogni valore di ogni filtro può richiedere una interrogazione di conteggio a sé. Su un catalogo da 200.000 prodotti con circa 2.000 gruppi di faccette attivi, disattivare i conteggi esatti ha portato una pagina di categoria da 43 secondi a 12 secondi; sulle sole faccette di caratteristiche e attributi, da 6,8 e 5,4 secondi a 15 e 19 millisecondi. Su un catalogo di poche migliaia di prodotti i conteggi valgono quasi sempre il loro costo; su un catalogo di centinaia di migliaia con molte caratteristiche, possono essere la voce più pesante della pagina, ed è spesso una casella di configurazione da spegnere, non una riscrittura.

Conteggi corretti anche con filtri multi-selezione

Un conteggio che promette “Rosso (12)” e poi il listato ne mostra 8 o 15 non è un dettaglio estetico: è il segnale che il conteggio e il click stanno rispondendo a due domande diverse. Il caso tipico è un filtro con più valori raggruppati sotto un’unica etichetta (per esempio “Rosso” che comprende le varianti Cremisi, Scarlatto e Bordeaux): se il conteggio somma quante volte compare ciascuna variante mentre il click applica “deve avere tutte insieme” invece di “deve averne almeno una”, il numero mostrato e il numero ottenuto non coincidono mai. La correzione, verificata sia sul driver nativo sia su Elasticsearch, è trattare il gruppo come un unico insieme fin dall’inizio (un solo conteggio di prodotti distinti che hanno almeno uno dei valori, non una somma), così il conteggio e il click condividono esattamente la stessa logica. Con Meilisearch, quando un conteggio del genere non può essere garantito esatto, il modulo preferisce non mostrare affatto il numero piuttosto che mostrarne uno sbagliato: un filtro senza conteggio è sempre meglio di un filtro che mente.

Il costo nascosto: calcolare in memoria invece che nel motore

Un errore diverso, trovato durante una revisione interna del codice, riguardava il range della faccetta prezzo: calcolare il minimo e il massimo caricando ogni valore corrispondente nella memoria dell’applicazione, invece di chiederlo al database o al motore di ricerca. Su un catalogo in cui questo significava circa due milioni di righe, quel solo passaggio costava 11 secondi e 965 MB di memoria per richiesta, abbastanza da esaurire il limite di memoria di un hosting condiviso e restituire una pagina di errore al posto dello slider. Spostare lo stesso calcolo in una aggregazione del database o del motore di ricerca lo ha riportato a una query normale e veloce: è esattamente il tipo di calcolo che questi sistemi sono fatti per svolgere in un solo passaggio sui dati già indicizzati, non nel codice applicativo dopo il fatto. Il difetto è stato chiuso ed è il motivo per cui, nel modulo, ogni calcolo di minimo/massimo e ogni conteggio passa sempre dal motore o dal database, mai da un ciclo PHP sulle righe.

Prezzi corretti per gruppo e valuta

Il prezzo che il cliente vede è sempre il prezzo nativo di PrestaShop. I prezzi sono indicizzati per gruppo cliente × valuta, tengono conto degli specific_price e dell’IVA per paese, e il valore giusto è scelto al momento della query. Questo significa che la faccetta prezzo e l’ordinamento per prezzo opzionali sono accurati per ogni cliente, un gruppo all’ingrosso e uno al dettaglio vedono e ordinano ciascuno secondo i propri prezzi.

Prezzi personali per il B2B Avanzate

Nella scheda Opzioni avanzate puoi abilitare i prezzi personali. Per i clienti B2B che hanno un listino individuale (uno specific_price assegnato al cliente), l’ordinamento e il filtro per prezzo possono usare il loro prezzo personale esatto anziché quello di gruppo. Un tetto configurabile (fisso, oppure automatico in base allo spazio libero su disco del motore) limita per quanti clienti questo viene precalcolato, e a quei clienti si può mostrare un messaggio opzionale per lingua.

Opzioni avanzate: abilita i prezzi personali (per cliente) per l’ordinamento e il filtro B2B, con un tetto configurabile

Aggiornare lo stock senza rallentare il checkout

Con un motore esterno ogni prodotto vive due volte: una riga nel database di PrestaShop e un documento nell’indice del motore. Quando un cliente cambia una quantità nel carrello o un ordine viene confermato, la disponibilità di quel prodotto deve aggiornarsi anche nell’indice. Il modo più costoso di farlo è ricostruire il documento intero da zero a ogni cambiamento, anche quando cambiano solo tre numeri (quantità, disponibilità, ordine di visualizzazione per disponibilità). Misurato su PrestaShop 9.0.0 con due negozi collegati a Elasticsearch, un ordine di cinque righe che ricostruiva il documento completo per ogni riga costava 243 interrogazioni al database e 229 millisecondi, solo per spostare tre numeri nell’indice. Con un percorso dedicato che aggiorna solo i campi realmente cambiati, invece di ricostruire tutto il documento, lo stesso ordine è sceso a 9 interrogazioni e 16-47 millisecondi. È per questo che il modulo tiene separati gli aggiornamenti di stock (in tempo reale, mirati) dalla reindicizzazione strutturale (quando cambia davvero nome, prezzo o categorie): un carrello che cambia quantità non deve mai pagare il costo di una reindicizzazione completa.

Multistore

Le impostazioni di connessione e motore sono per shop. In un contesto “tutti gli shop” vengono salvate globalmente; in un contesto single-shop vengono salvate per quello shop, con un fallback globale. Questo significa che shop diversi possono puntare a motori o cluster diversi, mentre un’installazione single-shop si comporta esattamente come prima.

Hosting condiviso / spazio di ricerca noleggiato

Non serve un cluster dedicato tutto tuo. Punta l’Host a un endpoint condiviso con un prefisso di percorso, imposta il Base path e un Prefisso indice (namespace), e aggiungi l’API key del provider. Ogni richiesta è circoscritta al tuo prefisso, così i tuoi dati restano isolati su un’istanza condivisa, e funziona allo stesso modo su Elasticsearch, OpenSearch e Meilisearch.