Il modulo viene renderizzato solo quando il negozio non è in modalità catalogo e quando PrestaShop restituisce più di una valuta attiva. Se c'è una sola valuta attiva, l'hook non restituisce nulla e non viene mostrato alcun selettore. Il posizionamento dipende anche dal tema che renderizza l'hook displayNav2 nell'area header o navigazione.

Ogni messaggio personale nasce da un esemplare: una vera email esportata dal tuo client di posta. Il modulo ne conserva struttura, firma e parte plain-text e sostituisce solo il corpo per ogni destinatario. Non ci sono pixel di tracciamento, link riscritti o markup da campagna, quindi il messaggio consegnato ha la stessa struttura della posta che il tuo team invia a mano.

Dalla consegna, non dalla data dell'ordine. L'articolo 9, paragrafo 2, lettera b) della direttiva 2011/83/UE fa decorrere il termine dal giorno in cui il consumatore acquisisce il possesso fisico dei beni, che nella maggior parte dei negozi cade diversi giorni dopo l'ordine.

Il modulo ricava quel momento dalla fonte più affidabile disponibile, in quest'ordine: una data di consegna inserita a mano, una data per singola spedizione da MPR Warehouse Revolution, il primo passaggio dell'ordine in uno stato contrassegnato come consegna, la data di consegna registrata sull'ordine e infine il record del vettore.

Se nessuna di queste è nota, non viene fissata alcuna scadenza e il termine non è ancora iniziato. È voluto: una data di partenza indovinata potrebbe chiudere un diritto che il cliente ha ancora.

Sì. Il modulo è pensato per PrestaShop 1.7.7 e versioni successive e funziona su 1.7.x, 8.x e 9.x con PHP 7.1 o superiore. Si registra sugli hook della home page (displayHome / displayHomeIntro) e può anche essere inserito come widget, quindi funziona nei temi supportati senza modifiche al core.

Una licenza a vita per un dominio con 3 mesi di supporto e aggiornamenti inclusi. Le nuove versioni si installano tramite il canale di aggiornamento standard dal tuo portale clienti, e le estensioni del supporto sono disponibili dalla pagina del prodotto.

No. Storico delle campagne, liste di soppressione, prove di consenso e traccia di audit vengono deliberatamente conservati nel database alla disinstallazione, perché soppressione e registri dei consensi sono impegni verso i tuoi clienti. Rimuoverli è un'operazione sul database separata e deliberata.

Mail Revolution supporta PrestaShop da 1.6 a 9.x su PHP 7.1 o superiore, in linea con il resto del catalogo mypresta.rocks. È compatibile con il multistore: campagne, code e liste di soppressione sono separate per negozio.

No. Le lettere personali partono dalla normale via di posta del negozio e nulla nel modulo richiede un account esterno. Per le newsletter broadcast puoi collegare opzionalmente un provider SMTP come identità dedicata della newsletter, ma non è necessario per usare il modulo.

Le campagne personali in modalità manuale trattengono ogni messaggio renderizzato. La coda elenca i destinatari a partire dal punteggio migliore e mostra l'email esatta che ogni cliente riceverebbe, con il paragrafo personalizzato evidenziato. Un collega designato approva o rifiuta ogni messaggio; le decisioni vengono salvate con l'account del dipendente e il timestamp, e la modifica di un messaggio invalida le approvazioni precedenti.

Per uscire dalle campagne personali basta una risposta del cliente, e le newsletter portano sempre header di disiscrizione in un clic. Disiscrizioni, bounce e reclami alimentano una lista di soppressione controllata immediatamente prima di ogni invio, e un blocco di un messaggio per campagna evita contatti ripetuti.

L'ordine ha una sola scadenza e decorre dall'ultimo pacco. L'articolo 9, paragrafo 2, lettera b), punto i) è esplicito: quando più beni ordinati insieme vengono consegnati separatamente, il termine parte dalla ricezione dell'ultimo.

È proprio qui che le procedure di reso gestite a mano si rompono. Se metà arriva lunedì e il resto venerdì, far scadere prima la metà di lunedì significa rifiutare un reso che il negozio è ancora tenuto ad accettare.

Il modulo registra la consegna riga per riga, così vedi quando è arrivato ogni articolo, e applica comunque una sola scadenza all'ordine. Le date per riga servono al tuo archivio e non possono mai scadere prima della scadenza dell'ordine.

No. Le fatture e le note di credito già emesse non vengono mai riscritte, e nemmeno pagamenti, totali, righe d'ordine, corrieri, cronologia, movimenti di magazzino o spedizioni. Una fusione cambia a chi appartiene un ordine, non l'ordine in sé. Un indirizzo a cui un ordine fa riferimento mantiene il proprio ID e ogni campo che compare sui tuoi documenti, quindi una vecchia fattura descrive ancora la consegna realmente avvenuta.

Aggiunge il Messenger ufficiale di Intercom al tuo negozio PrestaShop. Il modulo inserisce il loader di Intercom appena prima del tag body di chiusura su ogni pagina, così incolli il tuo App ID Intercom una sola volta invece di modificare i template del tema. Il widget si carica esattamente come lo snippet di installazione di Intercom, mantenendo pienamente funzionanti casella di posta, tour dei prodotti e messaggi automatici.

No, ed è una scelta precisa. Questo modulo non contiene telefonia: nessuna chiamata automatica, nessun SIP, nessun Twilio, nessuna registrazione. Raccoglie la richiesta, ti avvisa e continua a sollecitarti finché non la chiudi. La telefonata la fai tu, dal link nella coda.

Se ti servono composizione automatica, registrazioni o statistiche sugli operatori, ti serve una piattaforma telefonica in abbonamento. Questa è l'alternativa di proprietà per i negozi a cui basta che il contatto arrivi e non venga dimenticato.

Il modulo crea eventi GA4 a partire da azioni reali di PrestaShop anziché da un semplice tag di visualizzazione pagina. Tiene traccia di visualizzazioni prodotto, aggiunta al carrello e variazioni di quantità, avvio del checkout, acquisti completati, ricerche nel sito, accessi cliente e creazione di nuovi account, ciascuno inviato con i parametri e-commerce GA4 corrispondenti. Un generatore di eventi integrato consente inoltre di definire eventi personalizzati.

Sì. Il modulo registra il proprio selettore nell'hook displayNav2 e carica uno stylesheet che nasconde il selettore valuta desktop nativo di PrestaShop con #_desktop_ps_currencyselector { display: none !important; }. Il cliente vede il dropdown simbolo compatto del modulo invece del blocco valuta predefinito.

Non disinstalla né modifica il modulo valuta nativo di PrestaShop. Renderizza semplicemente un dropdown sostitutivo nell'hook header/navigation e nasconde il blocco desktop standard con CSS. Questo rende il cambio reversibile: disabilita o disinstalla il modulo e il selettore nativo può riapparire, assumendo che il tema lo renderizzi ancora.

Il sostituto usa il simbolo della valuta corrente nel toggle, opzionalmente mostra la label ISO accanto e lista le valute attive nel dropdown. I default sono SHOW_LABEL=0 e SHOW_NAMES=1, quindi il toggle resta compatto mentre il dropdown mostra comunque i nomi valuta completi. Ogni opzione è un link nofollow costruito con i normali parametri di switch valuta di PrestaShop.

Il posizionamento dipende comunque dal tema. Se il tema non chiama displayNav2 nell'area header o navigation, il modulo non ha un punto in cui renderizzare il selettore anche se gli asset sono caricati.

Il modulo renderizza solo quando lo shop non è in catalog mode e quando PrestaShop restituisce più di una valuta attiva. Se c'è una sola valuta attiva, l'hook restituisce nulla, quindi non viene mostrato alcun selettore. Anche il posizionamento dipende dal tema che renderizza l'hook displayNav2 nell'area header o navigation.

Controlla prima questi punti:

• Catalog mode: se catalog mode è abilitato, il selettore restituisce intenzionalmente una stringa vuota.
• Currency count: il modulo chiama la lista valute attive di PrestaShop e si nasconde quando quella lista contiene una valuta o nessuna.
• Theme hook: il selettore è renderizzato solo tramite displayNav2. Alcuni temi custom rimuovono o spostano quell'hook.
• Native block CSS: il modulo nasconde #_desktop_ps_currencyselector. Se stai cercando solo il vecchio blocco, è intenzionalmente nascosto mentre questo modulo è attivo.

Se il selettore non appare ancora dopo aver abilitato più valute, ispeziona il sorgente pagina per mprcurrency-dropdown. Se quel markup manca, l'hook non viene renderizzato o il modulo è uscito prima. Se il markup esiste ma non lo vedi, il problema è CSS del tema o layout header, non disponibilità valuta.

Il modulo carica il proprio CSS e JavaScript sul front office. JavaScript apre e chiude soltanto il dropdown; non crea il markup del selettore. Quindi un selettore mancante è quasi sempre catalog mode, configurazione mono-valuta, hook displayNav2 mancante o styling tema che nasconde il blocco renderizzato.

Sì, se lo abiliti. Configurando un API Secret di GA4, il modulo può inviare gli acquisti lato server tramite il Measurement Protocol come ripiego, così un ordine viene comunque registrato in GA4 anche quando il tag gtag.js del browser è bloccato da un ad blocker o perso su una pagina non riuscita. Il ripiego funziona solo se lo abiliti e fornisci l'API Secret.

In un recesso legale sull'intero ordine, sì. L'articolo 13, paragrafo 1 impone il rimborso di tutti i pagamenti ricevuti dal consumatore e nomina espressamente le spese di consegna.

L'articolo 13, paragrafo 2 pone un limite. Se il cliente ha scelto una consegna più costosa della tua opzione standard più economica, devi solo quest'ultima: il passaggio all'espresso non è rimborsabile. Indica la tua consegna standard più economica nelle impostazioni e il limite viene applicato automaticamente.

Due casi fanno eccezione. Quando torna solo una parte dell'ordine, il servizio di consegna è stato usato per ciò che il cliente tiene, quindi la spedizione non viene rimborsata per impostazione predefinita. Quando la merce era difettosa, errata o mancante, la spedizione viene rimborsata per intero: è un rimedio, non un recesso.

Ogni importo è mostrato con la ragione per cui è incluso o escluso, prima che tu confermi.

Perché un conto alla rovescia è una promessa che deve mantenere una persona, e alle 22:40 di sabato non la mantiene nessuno. Una promessa non mantenuta costa più fiducia di una promessa mai fatta.

Il modulo legge i tuoi orari e propone solo ciò che puoi davvero fare: il prima possibile finché sei realmente aperto, stamattina, più tardi oggi o il prossimo giorno di apertura. Fuori orario annuncia un richiamo durante l'apertura. La frase "di solito entro N minuti" compare solo a negozio aperto.

Sì. Ogni fusione scrive uno snapshot cifrato di ogni riga modificata, e History & Undo ti offre un pulsante finché quello snapshot esiste, 30 giorni per impostazione predefinita. L'annullamento si rifiuta se sovrascriverebbe qualcosa cambiato dopo la fusione, se l'ID di un cliente assorbito è stato riassegnato, o se una richiesta di cancellazione GDPR ha rimosso lo snapshot. Le sessioni cliente sono l'eccezione voluta: la fusione le revoca e non vengono mai ripristinate, perché restituire un accesso attivo aprirebbe la strada al furto dell'account.

Accedi al tuo account Intercom su app.intercom.com, apri Impostazioni > Installazione > Web e copia l'App ID dal codice di installazione. Incollalo nel campo App ID del modulo e salva. Finché non inserisci un App ID il widget resta inattivo, così il modulo non genera mai uno script rotto o vuoto sul tuo negozio.

Il modulo analizza il database alla ricerca di ogni tabella che porti un riferimento al cliente, comprese quelle che non ha mai visto, e le elenca nella schermata Data Sources con il numero di righe e il rischio di ricollegarle. Scegli una strategia per ogni tabella. In una tabella senza strategia non viene scritto nulla. Una tabella non annullabile, una con trigger, una vista o una tabella senza chiave primaria blocca la fusione invece di essere trattata alla meglio.

Il modulo supporta un caricamento rispettoso del consenso, così il tracciamento tiene conto dello stato di consenso del visitatore, e offre uno User ID con hash attento alla privacy invece di memorizzare identificatori grezzi. Il comportamento del consenso dipende dalle opzioni abilitate e dalla soluzione di consenso esterna (ad esempio una CMP) che colleghi. Resti responsabile della tua configurazione di privacy e consenso.

PrestaShop dalla 1.6.x alla 9.x, su PHP 7.1 e successivi. La versione 1.0.0 è stata installata e testata su PrestaShop 1.6.1.24 con PHP 7.1, 1.7.8.11, 8.2.1 e 9.2.0.

Il modulo sceglie gli hook adatti alla versione che trova: i nomi 1.6 su 1.6 e quelli moderni dalla 1.7, e non registra mai due hook che mostrerebbero il pulsante due volte nella stessa pagina.

Sì. Quando "Passa i dati utente" è attivo, il modulo invia email e nome del cliente connesso a intercomSettings, così le conversazioni arrivano già identificate nella tua casella Intercom. Gli ospiti vedono comunque il Messenger, ma in modo anonimo: nessun dato personale viene inviato per i visitatori non connessi.

Sì. Il modulo tiene i propri record di reso e non legge né scrive mai le tabelle dei resi di PrestaShop, quindi funziona sia che quella funzione nativa sia attiva sia che non lo sia.

Se lasci i resi nativi attivi, nulla va in conflitto: i due convivono e il modulo non interferisce con il flusso nativo. La maggior parte dei negozi disattiva i resi nativi, perché il pannello cliente del modulo sostituisce il modulo nativo essenziale e aggiunge la scadenza di cui quel form non ha alcuna nozione.

No. Usa le valute già configurate in PrestaShop e costruisce link switch con SubmitCurrency=1&id_currency=.... Non crea valute, non modifica tassi di cambio e non calcola conversioni. Disponibilità valuta, tassi e comportamento prezzi restano gestiti dalla configurazione valuta di PrestaShop.

Il modulo legge le valute attive di PrestaShop, trova la valuta corrente dal contesto cliente e renderizza un link per ogni valuta disponibile. Facendo clic su un link, chiedi a PrestaShop di cambiare la valuta selezionata del visitatore; dopo questo, PrestaShop gestisce conversione prezzo, arrotondamento, display tasse e formattazione esattamente come farebbe normalmente.

Usa le impostazioni valuta proprie di PrestaShop per cambi operativi: aggiungere o disabilitare valute, aggiornare tassi di cambio, configurare localizzazione e decidere come mostrare i prezzi. Usa questo modulo per la presentazione front-office del selettore: toggle solo simbolo, codice ISO opzionale nel toggle, nomi opzionali nel dropdown, styling theme-aware e ingombro header compatto.

Un modo utile per pensarci è: PrestaShop possiede la logica del denaro; il modulo possiede la UI dropdown. Se una valuta manca dal selettore, sistema prima il suo stato active/available in PrestaShop. Se i valori conversione sono sbagliati, aggiorna i tassi cambio in PrestaShop invece che in questo modulo.

Il testo esatto del consenso mostrato al visitatore viene salvato con ogni richiesta, insieme a un digest con chiave e a una data, così puoi dimostrare cosa è stato accettato e non cosa dice la pagina oggi.

Il modulo GDPR ufficiale esporta e cancella le richieste di un cliente registrato. Un ospite lascia solo un numero, che quel modulo non può collegare: per questo la pagina impostazioni offre una ricerca che esporta o cancella per numero, con la stessa validazione del modulo. Le richieste vengono inoltre eliminate dopo 30 o 90 giorni e gli indirizzi IP non sono mai salvati, solo un hash con chiave usato per i limiti.

Sì. Puoi scegliere se il Messenger appare su tutte le pagine o solo su alcune, attivare o meno la visualizzazione su dispositivi mobili e impostare un ritardo in secondi affinché il widget si carichi poco dopo la pagina. Così il negozio resta veloce e la chat compare solo dove aiuta davvero i clienti.

Assegna a ogni coppia un punteggio su indizi indipendenti: stessa email, alias in cui i punti di Gmail o un suffisso con il più nascondono la stessa casella, stesso numero di telefono normalizzato in formato internazionale, corrispondenza approssimata di nome e indirizzo postale nello stesso CAP, stessa azienda o partita IVA, e un checkout ospite che combacia con un account registrato. Gli indizi dello stesso tipo non si sommano, e le prove contrarie come partite IVA o paesi diversi sottraggono. Ogni peso lo puoi modificare.

No, e darlo per scontato è un errore comune e costoso. L'articolo 16, lettera m) esclude i contenuti digitali senza supporto materiale solo se sussistono tre condizioni insieme: l'esecuzione è iniziata, il consumatore ha dato il proprio consenso espresso preventivo e ha riconosciuto di perdere così il diritto di recesso.

PrestaShop non registra nessuna delle tre. Il modulo considera quindi un prodotto virtuale ancora coperto dal diritto di recesso, finché non confermi nelle impostazioni che il tuo checkout raccoglie davvero quel consenso e quel riconoscimento.

Sbaglia deliberatamente nella direzione sicura. Concedere un reso a torto costa un rimborso; rifiutarlo a torto viola la direttiva.

I beni confezionati su specifiche del cliente sono un caso diverso. L'articolo 16, lettera c) dipende dal bene stesso e non da un consenso, quindi un prodotto personalizzabile è escluso di per sé.

Sì. Il modulo include l'esclusione del traffico per dipendente e per indirizzo IP, così le visite dallo staff connesso o dagli indirizzi IP che elenchi non vengono inviate a GA4. In questo modo i test interni e l'attività di back-office restano fuori dai tuoi report analitici.

Sì. Il testo della slide, titolo, sottotitolo ed etichetta del pulsante, è memorizzato per lingua, così ogni lingua attiva del negozio può mostrare la propria formulazione pur condividendo lo stesso layout e le stesse immagini. Le traduzioni si gestiscono direttamente nel back office del modulo.

Quattro meccanismi, tutti lato server. Un honeypot che una persona non vede mai. Un controllo dei tempi che rifiuta un invio impossibilmente rapido dopo il caricamento. Un limite per visitatore. E l'unione dei duplicati: cliccare cinque volte produce un contatto con un contatore, non cinque righe.

I numeri sono validati secondo le regole internazionali prima del salvataggio, quindi le sciocchezze evidenti non arrivano in coda. Il modulo non sostiene di verificare che un numero sia raggiungibile: nulla può farlo senza chiamare.

No. Banner Revolution mostra soltanto i banner, i testi e i link di call-to-action che configuri. Non raccoglie dati personali dei visitatori e non imposta cookie di tracciamento, quindi non ha un impatto GDPR proprio oltre alle pagine a cui rimandi.

Un pannello di diagnostica nel back-office convalida il Measurement ID di GA4 prima dell'avvio del tracciamento e verifica la consegna degli eventi, con gestione dei tentativi per il Measurement Protocol. Un registro eventi annota gli eventi creati e inviati dal modulo, così puoi confermare l'arrivo dei dati in GA4 prima di affidarti ai report.

Solo se lo attivi tu, e viene consegnato disattivato. Una volta attivo agisce soltanto sui gruppi sopra la tua soglia di certezza con almeno il numero configurato di indizi indipendenti, e rifiuta qualsiasi gruppo che tocchi una tabella sconosciuta, un trigger, una tabella non transazionale, o che presenti un conflitto irrisolto. Il preset più prudente lo limita a far confluire un checkout ospite nell'account registrato che possiede già quell'identità.

Puoi attivarlo, ma in un negozio dell'Unione europea non dovresti. L'articolo 9, paragrafo 1 dà al consumatore il diritto di recedere senza dover fornire alcuna motivazione, quindi un campo obbligatorio non è conforme.

L'impostazione è perciò disattivata per impostazione predefinita, l'elenco dei motivi è proposto come facoltativo e il modulo dice al cliente in parole chiare che non serve alcun motivo. I motivi che i clienti indicano spontaneamente vengono comunque registrati e mostrati nel back office, ed è lì che di solito sta l'informazione utile.

Il modulo supporta PrestaShop dalla 1.6 alla 9.x, inclusa la 8.x, e funziona con PHP 7.2 e versioni successive. Tutta la configurazione avviene nel back-office, quindi non richiede modifiche ai template del tema.

Sì. Gli interruttori di posizionamento coprono il pulsante flottante, la scheda prodotto, l'intestazione e un hook personalizzato del tema. Inoltre puoi mostrare il widget solo su prodotti, categorie e pagine scelti, oppure ovunque tranne lì, con lo stesso selettore usato dagli altri nostri moduli.

Se il tema è particolare, attiva l'hook personalizzato e inserisci {hook h='displayMprCallback'} esattamente dove vuoi. Il modulo non si inserisce mai cercando selettori CSS.

Sì. Gli account vengono uniti solo all'interno di un unico dominio di isolamento cliente: lo stesso negozio, o lo stesso gruppo di negozi quando la condivisione dei clienti è attiva. Due negozi che non condividono i clienti detengono due persone distinte dal punto di vista del consenso e della legge, quindi quelle corrispondenze sono mostrate a titolo informativo e non possono essere unite.

L'e-mail per una nuova richiesta parte subito e non dipende dal cron. Il promemoria di ritardo e la pulizia dei dati sono attività pianificate.

Se l'hosting non ha un cron, girano in occasione delle normali richieste: funziona, ma in modo approssimativo, e un negozio senza traffico non le eseguirà. Per tempi affidabili punta il cron dell'hosting all'URL indicato nella schermata delle attività pianificate. Il modulo segnala nel back office quando non gira da un po'.

Ogni fusione, annullamento ed errore viene aggiunto a un registro di audit concatenato con hash: ogni voce porta l'hash di quella precedente, quindi una voce rimossa o modificata spezza la catena in modo visibile. Il registro annota cosa è successo, quando e quale dipendente lo ha fatto, insieme al conteggio delle righe per tabella. Non contiene dati dei clienti e si esporta in CSV.

No. Il pulsante LINE fluttuante viene aggiunto tramite gli hook di PrestaShop displayBeforeBodyClosingTag e displayHeader, quindi i file del tema e dei template non vengono mai modificati o sovrascritti. La disinstallazione rimuove il pulsante in modo pulito, senza lasciare tracce nel tema.

No. Non modifica i template né sovrascrive i file del tema. Agisce tramite gli hook presenter di PrestaShop, actionPresentProduct e actionPresentProductListing aggiungono i dati loading e decoding agli array di immagini che il tuo tema già genera, e tramite l'hook filterHtmlContent per i testi WYSIWYG. Il tema mantiene il pieno controllo del markup; il modulo fornisce solo gli attributi. Alla disinstallazione gli attributi smettono semplicemente di essere aggiunti e nel tema non resta nulla di modificato.

Il widget apre il tuo link di contatto LINE (https://line.me/ti/p/il-tuo-LINE-ID) in una nuova scheda, così il visitatore può avviare una conversazione nell'app LINE. Non allega alcun messaggio precompilato o salvato al link: passa semplicemente il cliente a LINE.

Sì. Il modulo non analizza né riscrive l'HTML finale generato di una pagina. Arricchisce i dati delle immagini a livello di presenter prima che il template venga eseguito e processa solo determinati campi di contenuto WYSIWYG. Poiché non tocca mai l'output della pagina, può funzionare in sicurezza insieme a cache a pagina intera, CCC e CDN, non c'è alcun buffer di output da invalidare, quindi le pagine in cache restano valide.

Sì. Per le immagini nel contenuto WYSIWYG, aggiungi al tag img la classe CSS di esclusione (predefinita no-autolazy) e il modulo la salta. È il modo consigliato per far caricare subito l'immagine principale above-the-fold, perché applicare il lazy loading all'immagine visibile più grande può peggiorare il Largest Contentful Paint. Anche le immagini data-URI inline e quelle che hanno già un attributo loading vengono saltate automaticamente.

Sì. Il targeting delle pagine consente di mostrare il pulsante su ogni pagina o di limitarlo ad alcune, e un interruttore mobile separato permette di nasconderlo sui telefoni. Un'opzione di ritardo di caricamento può inoltre trattenere il pulsante per un istante, così non compete con la pagina mentre si carica.

È un suggerimento per il browser che consente di decodificare un'immagine fuori dal thread principale, così la decodifica di un'immagine grande ha meno probabilità di bloccare lo scorrimento o l'interazione. Completa loading="lazy". Il modulo lo aggiunge per impostazione predefinita ma offre un singolo interruttore per disattivarlo, se preferisci, lasciando solo loading="lazy". Gli attributi decoding esistenti non vengono mai sovrascritti.

Le immagini di prodotto sulla pagina prodotto, le immagini di prodotto negli elenchi di categoria e ricerca e le immagini incorporate nel contenuto WYSIWYG come le descrizioni di prodotto, categoria, pagine CMS e produttore. Le prime due sono gestite dagli hook presenter di prodotto; l'ultima dall'hook del filtro dei contenuti. È un aiuto mirato alla velocità, non comprime, ridimensiona o converte le immagini, aggiunge solo gli attributi loading e decoding.

Il toggle header chiuso mostra sempre il simbolo o segno della valuta corrente, come $, €, £ oppure il codice ISO come fallback. Se Show ISO label in toggle è abilitato, il toggle mostra anche il codice ISO corrente accanto al simbolo. Il dropdown aperto elenca sempre ogni valuta con il suo simbolo/segno, e se Show currency names in dropdown è abilitato mostra anche il nome completo della valuta accanto a ogni simbolo.

Il toggle non renderizza un tooltip hover. I nomi valuta sono usati nelle righe del dropdown, incluso l'attributo title del link per ogni opzione valuta.

Sì. Il modulo registra il proprio selettore nell'hook displayNav2 e carica uno stylesheet che nasconde il selettore valuta desktop nativo di PrestaShop con #_desktop_ps_currencyselector { display: none !important; }. Il cliente vede il dropdown compatto a simbolo del modulo invece del blocco valuta predefinito.

Abilita il modulo, incolla il tuo ActiveCampaign Account ID, poi salva la configurazione. L'Account ID è il valore numerico che ActiveCampaign mostra in Settings > Tracking > Site Tracking; viene salvato come ACCOUNT_ID, e il modulo non renderizza lo script storefront finché non sono presenti sia ENABLED sia ACCOUNT_ID.

• In PrestaShop, apri la configurazione del modulo ActiveCampaign.
• Attiva Enable ActiveCampaign.
• Incolla l'Account ID numerico, per esempio 123456789.
• Visita una pagina storefront e conferma che il sorgente pagina contenga lo script diffuser ActiveCampaign.

Quando è attivo, l'hook displayBeforeBodyClosingTag carica lo script diffuser di ActiveCampaign, esegue vgo('setAccount', ...), abilita default tracking e chiama vgo('process'). Per clienti loggati può anche passare l'email del cliente con vgo('setEmail', ...).

Lo script viene inserito appena prima del tag body di chiusura, non nell'head della pagina. Questo è utile quando controlli l'installazione: cerca nel sorgente renderizzato vicino al fondo diffuser-cdn.app-us1.com/diffuser/diffuser.js, vgo('setAccount' e il tuo account ID. Se mancano, il modulo è disabilitato, l'Account ID è vuoto o il tema non esegue l'hook displayBeforeBodyClosingTag.

La configurazione ha anche un campo opzionale EVENT_KEY, ma l'hook storefront attuale è solo site tracking. Non invia chiamate event-tracking custom ActiveCampaign da questo percorso codice modulo. Usalo per aggiungere lo snippet ufficiale site-tracking e identificare clienti loggati via email; costruisci automazioni eventi custom separatamente se ti serve event tracking ActiveCampaign più profondo.

Per privacy, ricorda che questo è uno script di tracking. Abbinalo alla configurazione consenso se lo store richiede consenso marketing o analytics prima di caricare tracking terzo, perché questo modulo non implementa da solo un cookie-consent gate.

Sì, i clienti PrestaShop loggati vengono identificati via email nello script tracking ActiveCampaign. Il modulo legge il cliente corrente dal contesto PrestaShop e invia l'email solo quando il cliente è loggato; i visitatori anonimi sono tracciati senza valore email.

Il controllo avviene nell'hook storefront di chiusura body. Il tracking viene renderizzato solo quando il modulo è abilitato ed è presente un ActiveCampaign Account ID. L'hook assegna poi tre valori template: account ID, email cliente e un booleano che indica se un'email è stata trovata.

Nel template, vgo('setEmail', ...) è avvolto in un controllo logged-in, quindi i guest non ricevono una chiamata email vuota. Ogni pagina tracciata imposta comunque account, abilita default page tracking e chiama vgo('process'). Questo significa che ActiveCampaign può collegare visite note delle pagine all'email del cliente loggato, mentre le visite guest restano anonime finché ActiveCampaign non può identificarle in altro modo.

Logged in customer -> setAccount + setTrackByDefault + setEmail + process
Guest visitor -> setAccount + setTrackByDefault + process

L'impostazione richiesta è l'ActiveCampaign Account ID, più il modulo deve essere abilitato. Il codice controlla entrambi prima di renderizzare lo script storefront PrestaShop; il campo Event Key viene salvato in configurazione, ma l'attuale template tracking non lo usa.

All'installazione, ENABLED è 0 di default, ACCOUNT_ID è una stringa vuota e anche EVENT_KEY è una stringa vuota. L'avviso di configurazione richiesta dichiara solo ACCOUNT_ID come richiesto, e il controllo di attivazione è semplicemente enabled più account ID non vuoto.

L'opzione admin descrive l'Account ID come ID numerico da site tracking ActiveCampaign, ma questo sorgente non applica un validator numerico prima di renderizzare. Per un setup pulito, copia l'account ID esattamente dalle impostazioni site tracking di ActiveCampaign, abilita il modulo, poi controlla il sorgente pagina per lo script diffuser.js e vgo('setAccount', ...).

ENABLED = 1
ACCOUNT_ID = 123456789
EVENT_KEY = optional, stored but not rendered by tracking.tpl

I moduli PrestaShop hanno ciascuno bisogno di job pianificati (feed, pulizie, sync), ma collegare una riga cron server separata per ognuno e fragile. Un cron manager ti offre un unico endpoint protetto da token che li esegue tutti. Con Cron Manager, PrestaShop espone un URL come /module/mprcron/cron?token=… (piu un entry point cron.php per chiamate CLI o HTTP con opzioni max-task e context) che esegue a turno ogni task registrato. Punta un solo cron server - o un servizio esterno come cron-job.org - a quell'URL sull'intervallo scelto, e gestisci pianificazioni individuali, stato abilita/disabilita e storico esecuzioni dal back office invece di modificare crontab. Mantieni segreto il token cosi utenti esterni non possono attivarlo, e inizia con un intervallo di 5-15 minuti in base a quanto sono time-sensitive i tuoi task. Il logging centralizzato rende anche facile individuare un job fallito.

Il comando CLI generato e un comando crontab su una riga usando il token condiviso, per esempio * * * * * php /path/to/modules/mprcron/cron.php --token=TOKEN --max-seconds=300. L'entry point richiede un token, limita max_tasks tra 1 e 100, limita max_seconds tra 10 e 300 e usa come default 20 task e 300 secondi. Il token condiviso e generato come valore esadecimale di 64 caratteri e validato con hash_equals.

Internamente il package condiviso possiede due tabelle: mpr_cron_task per i task registrati e mpr_cron_log per lo storico esecuzioni. Ogni task salva modulo, task key, label, callable o payload, tipo executor, schedule, stato enabled, next run, context, priorita e timeout. Il runner rivendica un task prima di eseguirlo, registra stati completed, failed, skipped, timeout o crashed e scrive una riga log. In modalita CLI, quando il cron.php locale supporta task isolati e proc_open e disponibile, ogni task puo girare in un subprocess cosi un task fatale non ferma il resto del batch.

No, questo modulo non invia eventi ecommerce ActiveCampaign di prodotto, carrello, ordine o custom. Il suo codice PrestaShop carica solo site tracking, imposta account, identifica opzionalmente l'email di un cliente loggato e chiama la funzione di processing pagina ActiveCampaign.

L'impostazione salvata EVENT_KEY è descritta come opzionale per eventi custom, ma il template storefront non la riferisce mai. Non ci sono chiamate evento purchase, cart, product o checkout nel template tracking; le uniche chiamate ActiveCampaign sono setAccount, setTrackByDefault, setEmail opzionale e process.

Per i merchant, il risultato pratico è page-visit tracking invece di ecommerce tracking. Puoi usarlo per permettere ad ActiveCampaign di vedere page view tracciate e identificare clienti loggati via email, ma valore ordine, product ID, contenuto carrello e line item non vengono inviati da questo modulo. Se servono, richiedono un'altra integrazione o nuovo codice che si agganci davvero agli eventi prodotto, carrello e ordine.

Una buona sezione FAQ risponde alle domande degli acquirenti prima che scrivano email e cattura traffico long-tail dai motori di ricerca. Per aggiungerne una a PrestaShop, usa FAQ Manager: crea un hub FAQ pubblico con route categoria, tag, ricerca e domanda, mostra una scheda FAQ prodotto tramite displayProductExtraContent e può mostrare contenuto FAQ in contesto categoria come blocco left-column/sidebar tramite displayLeftColumn. Salvi domande, categorie, tag e assegnazioni prodotto o categoria, così la stessa risposta può apparire nell'hub e su ogni prodotto correlato. I clienti possono inviare le loro domande per moderazione, e risposte community approvate con voti helpful aggiungono contenuto fresco. Per SEO, dai a ogni domanda indicizzabile un title e una meta description unici, mantieni le risposte davvero utili invece di una riga sola, e usa FAQ schema solo dove è accurato e ancora utile per il tuo obiettivo di ricerca/visualizzazione.

Nella configurazione pratica, inizia dal menu admin FAQ: crea categorie FAQ, poi aggiungi domande con testo domanda multilingua, HTML risposta, friendly URL, meta title e meta description. Se il friendly URL resta vuoto, le categorie generano uno slug dal nome categoria e le domande generano uno slug dal testo domanda. Una domanda pubblica è visibile solo quando è attiva, la sua publish date è vuota o già passata, e il gruppo cliente corrente è autorizzato. Puoi anche impostare una Answer Reveal Date, che permette alla domanda di esistere prima che la risposta venga mostrata.

• Usa Categories per hub FAQ pubblici e per mappare categorie FAQ a categorie PrestaShop dove i blocchi contestuali di pagina categoria sono utili.
• Usa Questions per le vere voci FAQ; assegna prodotti direttamente quando una domanda deve apparire in una scheda FAQ prodotto.
• Usa Tags per migliorare ricerca FAQ, pagine tag e scoperta interna.
• Usa Pending Questions e Additional Replies per moderare gli invii dei visitatori prima che diventino pubblici.

Per le pagine prodotto, non fare affidamento su ampie mappature categoria quando ti serve una FAQ prodotto esatta. La scheda prodotto carica domande dalla tabella di assegnazione diretta product-question e non restituisce nulla se nessuna domanda è assegnata a quel prodotto. Le domande assegnate esattamente a un solo prodotto possono renderizzare una risposta nell'HTML iniziale della pagina prodotto; le domande condivise tra più prodotti sono trattate come correlate/condivise e le loro risposte vengono caricate lazy quando aperte. Questo evita di iniettare grandi articoli di troubleshooting in ogni pagina prodotto e aiuta a evitare contenuto duplicato rumoroso.

Le pagine categoria non vengono renderizzate come scheda da questo modulo. L'integrazione categoria è un blocco left-column/sidebar che carica un set limitato di domande per la categoria corrente e le collega all'esperienza FAQ.

I controlli SEO sono volutamente granulari. L'indicizzazione dell'hub FAQ è on di default, ma pagine categoria, pagine tag e pagine domanda individuali non sono indicizzate salvo abilitazione dello switch globale relativo e, per categorie o domande, marcatura indexable dell'entità stessa. Le pagine ricerca sono sempre noindex. I campi meta title e meta description ripiegano sul titolo visibile, descrizione categoria o excerpt risposta quando lasciati vuoti, e gli URL canonical sono costruiti dallo slug FAQ localizzato, slug categoria e slug domanda.

Schema è uno switch, non magia automatica. L'impostazione è SCHEMA_ENABLED e ha default 0; l'hint admin dice che Google ha deprecato i rich result FAQ a maggio 2026, quindi trattalo come dati strutturati opzionali invece che come trigger garantito di rich result. La gestione delle risposte pianificate non è coerente in ogni percorso schema nel codice attuale: i builder JSON-LD front question e category controllano answer_visible, ma l'output QAPage header a livello modulo legge direttamente questionData['answer'], e il percorso query/build schema dell'hub FAQ non controlla date_response o answer_visible. Se usi risposte ritardate, mantieni schema disabilitato o correggi quei percorsi prima di fare affidamento sullo schema per nascondere contenuti risposta futuri.

Il flusso invio visitatore è moderato. Ask a Question è abilitato di default, valida nome, email e testo domanda, limita il testo domanda a 5000 caratteri, usa un campo honeypot e salva l'elemento in mprfaq_pending con stato pending. Il rate limit predefinito è ASK_MAX_PENDING=2 domande pending per email per categoria prodotto top-level; impostalo a 0 solo se vuoi deliberatamente nessun limite alle domande pending. Se il visitatore domanda da una pagina prodotto e non viene fornita alcuna categoria FAQ, il controller risolve una categoria dal contesto prodotto.

Le risposte pubbliche sono separate dalla risposta ufficiale. CA_ENABLED ha default 0; quando abilitato, il modulo può richiedere login, valida i dettagli autore, limita il testo risposta a 5000 caratteri e salva la risposta come pending. Le risposte aggiuntive approvate possono apparire come community answers e possono essere votate. I voti helpful sono limitati a un voto per IP per domanda o risposta, con un cookie PrestaShop usato solo per ricordare lo stato UI del visitatore.

FAQ_SLUG=faq
FAQ_HUB_INDEXABLE=1
FAQ_CATEGORY_INDEXABLE=0
FAQ_TAG_INDEXABLE=0
QUESTION_INDEXABLE=0
SCHEMA_ENABLED=0
ASK_ENABLED=1
ASK_MAX_PENDING=2
CA_ENABLED=0

Per una FAQ SEO, la regola pratica è mantenere ampio l'hub, rendere indicizzabili solo pagine categoria o domanda solide e autonome, assegnare le domande prodotto direttamente e lasciare le piccole risposte specifiche per prodotto nella scheda prodotto. Questo offre risposte ai clienti dove servono, mantenendo l'indice focalizzato su pagine che possono stare in piedi da sole.

Il modulo gestisce record catalogo digitali per moduli, temi e addon. In PrestaShop ogni prodotto digitale può salvare nome tecnico, branch, versione corrente, campi compatibilità, URL documentazione, demo e repository, changelog, mesi di supporto e limiti dominio.

Sì, MPR FAQ può raccogliere domande dei clienti per revisione. In PrestaShop i record pending salvano nome, email, domanda, prodotto o categoria FAQ, stato, eventuale risposta admin e timestamp prima della pubblicazione.

Usa l'area di pulizia per rimuovere i vecchi record supportati da PrestaShop. Il modulo conta ed elimina carrelli abbandonati oltre 30 giorni senza ordini, statistiche ricerca, prezzi specifici scaduti, log, connessioni, ospiti orfani e record mail.

Se ti serve solo un avviso cookie chiaro accetta-o-rifiuta, un banner leggero è l'implementazione più semplice. Lightweight Cookie Banner renderizza il banner dagli hook a livello footer, salva la scelta del visitatore in un cookie consenso e ti permette di configurare testo banner, pulsanti, colori, posizione, link privacy policy e durata del consenso prima di chiederlo di nuovo (365 giorni di default). È intenzionalmente minimale - niente script pesanti - quindi non rallenta il negozio. Usalo quando il tuo footprint di tracciamento è piccolo e hai principalmente bisogno di informare i visitatori e registrare la loro scelta. Se devi anche bloccare script fino al consenso, registrare log consenso o offrire preferenze granulari per categoria, una piattaforma consenso completa è più adatta. Abbina sempre il banner a una cookie policy e privacy policy accurate e aggiornate.

Il modulo ha come default abilitato, posizione bottom-left, pulsanti affiancati, tema scuro, COOKIE_EXPIRY di 365 giorni, Google Consent Mode abilitato e DEFAULT_CONSENT impostato a denied. Può renderizzare come barra full-width in alto o basso, banner angolare, banner flottante in basso o modale centrale con overlay. La scelta del visitatore viene salvata nel cookie first-party mprcookie_consent con valore granted o denied; JavaScript lo scrive con path=/, SameSite=Lax e Secure quando il negozio è su HTTPS.

Quando Google Consent Mode è abilitato, l'hook header inietta il segnale di consenso predefinito e carica asset/config sicuri per l'head; non renderizza il markup visibile del banner. Il markup banner viene renderizzato da displayFooterAfter o displayFooter, con guard per emetterlo una sola volta, e lo script front invia un aggiornamento consenso dopo che il visitatore accetta o rifiuta. Il modulo non categorizza cookie, non riscrive script di terze parti e non mantiene una tabella log consenso. Inoltre avvisa quando Cookies Revolution è disponibile perché solo un modulo consenso cookie dovrebbe controllare lo storefront alla volta.

Il Meta (Facebook) Pixel traccia le azioni degli acquirenti così puoi misurare le performance ads e costruire audience di retargeting. PrestaShop non ha un Pixel nativo, quindi lo aggiungi con un modulo di tracciamento. Con Facebook Pixel, inserisci il tuo Pixel ID e abilita il tracciamento browser; il modulo emette poi gli eventi ecommerce standard - PageView, ViewContent, AddToCart, InitiateCheckout, Search, AddToWishlist, CompleteRegistration e Purchase - con switch individuali così puoi attivare o disattivare eventi specifici. Per conversioni accurate nonostante perdite da browser e ad-blocker, abilita anche la Conversions API lato server, che invia eventi Purchase a Meta con un event ID corrispondente così hit browser e server vengono deduplicate. Verifica tutto nello strumento test Events Manager di Meta prima di lanciare campagne, e assicurati che l'attivazione del Pixel rispetti il tuo banner consenso cookie, così il tracciamento gira solo dopo il consenso marketing.

Il modulo si installa con ENABLED off e PIXEL_ID vuoto, quindi nessun tracciamento browser parte finché non lo configuri. I Pixel ID sono validati come solo cifre. La maggior parte degli switch evento standard ha default on una volta abilitato il modulo stesso, mentre CAPI_ENABLED ha default off e richiede Pixel ID più CAPI_ACCESS_TOKEN. La versione Graph API predefinita nel modulo è v25.0, e durante la validazione in Meta Events Manager può essere inviato un test event code opzionale.

Il consenso viene controllato prima di renderizzare il template di tracciamento. Se Cookies Revolution è attivo, il modulo legge il valore marketing da mprcr_consent; se Lightweight Cookie Banner è attivo, legge mprcookie_consent; se nessuno è attivo e il rispetto del consenso è abilitato, il modulo tratta il consenso marketing come disponibile. Anche la navigazione dipendenti può essere esclusa. AddToCart viene tracciato tramite l'evento PrestaShop updateCart quando disponibile, con fallback click per temi più vecchi. Purchase viene emesso su conferma ordine con un order event id deterministico, e quando CAPI è configurata lo stesso acquisto viene accodato ed elaborato tramite la coda conversioni condivisa, incluso un task cron pianificato ogni 300 secondi per retry/processing.

Gli acquirenti convertono meglio quando possono vedere quando arriverà un ordine. Per mostrare una data di consegna stimata in PrestaShop, usa Estimated Delivery Date: aggiunge i giorni di preparazione configurati alla data corrente e mostra il risultato nella pagina prodotto tramite il blocco displayProductAdditionalInfo. Puoi impostare un orario limite giornaliero (gli ordini inseriti dopo contano dal giorno successivo), escludere i weekend così sabato e domenica non vengono conteggiati e un risultato finale nel weekend slitta a lunedì, e scegliere il formato data visto dagli acquirenti. Il messaggio appare automaticamente sulle pagine prodotto idonee, dando un'aspettativa concreta di arrivo entro una data invece di un vago "spedito presto". Mantieni onesti i tempi di preparazione e allinea il cutoff al tuo reale programma di spedizione, così la data promessa corrisponde a ciò che i clienti ricevono: stime accurate riducono i ticket "dov'è il mio ordine".

I default di installazione sono ENABLED=1, PROCESSING_DAYS=1, CUTOFF_HOUR=14, EXCLUDE_WEEKENDS=1 e DATE_FORMAT=l, F j. Il calcolo usa il DateTime corrente del server, legge l'ora corrente come valore intero a 24 ore e aggiunge un giorno di preparazione extra quando l'ora corrente è maggiore o uguale al cutoff. Poi avanza un giorno alla volta finché il numero configurato di giorni di preparazione non è stato conteggiato, saltando sabato e domenica quando l'esclusione weekend è abilitata.

Il messaggio storefront riceve anche hours_left, che è semplicemente la differenza in ore intere fino al cutoff quando l'ordine è ancora prima del cutoff. Questo modulo non ispeziona range di consegna del corriere, stato stock, calendari magazzino, festività, CAP destinazione o lead time specifici per prodotto. È una promessa semplice sulla pagina prodotto basata su regole di preparazione a livello negozio, quindi funziona meglio quando il tuo catalogo condivide lo stesso pattern di spedizione.

Nel tempo un database PrestaShop si riempie di dati che non ti servono piu: carrelli abbandonati, righe carrello orfane, prezzi specifici e regole carrello scaduti, vecchi record connection e guest, statistiche ricerca, log mail e 404, visualizzazioni pagina e thread cliente chiusi. Se non controllate, queste tabelle rallentano le query e gonfiano i backup. Per pulirle in sicurezza, usa Cleanup Revolution: raggruppa ogni pulizia in task nominati, conta le righe interessate prima dell'eliminazione, supporta anteprime dry-run di default e registra le esecuzioni reali nello storico cleanup. Inizia con carrelli abbandonati piu vecchi di 30 giorni e statistiche ricerca/connection obsolete, controlla i conteggi in anteprima, poi elimina in batch. Fai sempre prima un backup del database. Per manutenzione continua, pianifica i task invece di eseguirli a mano; vedi la nostra guida performance PrestaShop.

Before any real cleanup, make a fresh database backup and run the module preview first. Do not delete rows manually with SQL; use Cleanup Revolution's dry-run counts, review the affected tasks, then run the cleanup from the module in controlled batches.

mysqldump -u db_user -p db_name > prestashop-before-cleanup.sql

La configurazione predefinita e volutamente conservativa: dry run e abilitato di default, trash mode e abilitato, i carrelli abbandonati hanno default 30 giorni, molti log/statistiche 90 giorni, thread cliente chiusi 180 giorni, account vuoti 365 giorni, e il motore usa dimensioni batch per task piu un limite totale di 50000. Un task senza righe da rimuovere viene saltato dal runner bulk, e l'eliminazione reale avviene in batch invece che come una singola istruzione enorme.

Un dettaglio dell'audit-log conta: le esecuzioni dry-run restituiscono il conteggio interessato prima che venga chiamato MPRCleanupLog::record(), quindi le anteprime dry-run non vengono scritte nello storico cleanup. Le pulizie database reali vengono loggate con dry_run = 0. Le azioni manuali nel Back Office chiamano DatabaseCleanupEngine::executeTask(..., $employeeID) oppure DatabaseCleanupEngine::executeAll($dryRun, $employeeID), quindi usano il valore predefinito trigger_type = manual e registrano l’ID del dipendente quando disponibile. La pulizia programmata del database chiama MPRCleanupRevolution::cronDBCleanup(), che passa DatabaseCleanupEngine::executeAll(false, null, 'cron'); di conseguenza, quelle righe di log registrano trigger_type = cron senza ID dipendente.

Il motore cleanup database include task nominati per carrelli abbandonati, prodotti carrello orfani, statistiche ricerca, prezzi specifici scaduti, regole carrello scadute con quantita zero, vecchi log, vecchie connessioni, righe connection orfane, vecchi guest, log mail, log 404, visualizzazioni pagina, thread cliente chiusi e cache referrer. Ha anche pulizie commerciali a rischio piu alto come account ospite senza ordini, indirizzi orfani e vecchi account registrati senza ordini o carrelli recenti. I default cron dividono il lavoro in finestre di database cleanup, file cleanup e ottimizzazione tabelle, cosi puoi automatizzare la manutenzione senza eseguire ogni operazione pesante insieme.

Il rendering nello storefront è gestito dall'hook displayMprSubtitle. Il resolver può rilevare la pagina prodotto, categoria, CMS, produttore o fornitore corrente, e i template possono anche passare un ID prodotto esplicito quando serve.

Per piena conformità GDPR ed ePrivacy serve più di un banner: gli acquirenti devono poter accettare o rifiutare i cookie per finalità. Cookies Revolution aggiunge consenso granulare a PrestaShop con le categorie standard - necessary, functional, analytics e marketing - e un pannello preferenze dove i visitatori possono accettare tutto, rifiutare le categorie opzionali o salvare una selezione personalizzata; la loro scelta viene salvata in un cookie consenso. Può anche bloccare script di tracciamento corrispondenti finché non viene dato il consenso, riscrivendo i tag affinché girino solo per categorie consentite, e registrare log consenso con identificatori hashati per il tuo audit trail. Il consenso preventivo (niente caselle opzionali preselezionate) e il ritiro del consenso con la stessa facilità con cui è stato dato sono requisiti legali: questo copre entrambi. Combinalo con Google Consent Mode v2 così i tuoi tag Google si adattano automaticamente alla scelta di ogni acquirente.

All'installazione il modulo crea tabelle per categorie, cookie, script-rule, consent-log, scan-result e design. Le categorie seed sono necessary, functional, analytics e marketing; necessary è richiesta e abilitata di default, mentre le categorie opzionali sono off di default salvo modifica della modalità consenso predefinito. Lo stato browser salvato è compatto, per esempio necessary:1|functional:0|analytics:0|marketing:0 in mprcr_consent, con un cookie separato mprcr_version usato quando RECONSENT_ON_CHANGE è abilitato.

Il blocco script funziona su due livelli. Sull'output server il modulo riscrive script esterni corrispondenti a type="text/plain" con data-cookiecategory e salva la source originale in data-original-src; può anche riscrivere script inline corrispondenti in base a regole sul contenuto script. Lato browser, un MutationObserver controlla gli script iniettati dinamicamente contro la stessa lista regole e li blocca se la categoria corrispondente non è concessa. Quando il consenso viene salvato, il modulo aggiorna Google Consent Mode, attiva gli script consentiti, elimina cookie per categorie revocate dove configurato, emette mprcr:consent e registra la decisione tramite AJAX quando il logging è abilitato, con un breve throttle per evitare log duplicati.

Sì, puoi bloccare per IP, intervallo CIDR, codice paese o pattern user-agent, incluso scope solo checkout. Il ban manager PrestaShop controlla prima le whitelist, poi le regole ban attive, e applica scope full, checkout o authentication in base al contesto della richiesta corrente.

Il form ban supporta IP singolo, wildcard IP come 192.168.1.*, range IP come 1.1.1.1-1.1.1.255, CIDR come 192.168.1.0/24, codice ISO paese e pattern user-agent. Le regole user-agent possono essere testo semplice abbinato case-insensitively, oppure una regex racchiusa tra slash.

Lo scope è basato sul controller corrente. Checkout scope si applica a order, orderopc, cart, supercheckout, onepagecheckout e checkout. Login/auth scope si applica a authentication, my-account, identity, registration e password. I full ban sono controllati prima dei ban scope-specific, quindi un full ban blocca il visitatore ovunque.

• Enablement: BAN_ENABLED viene installato come abilitato di default.
• Temporary bans: un ban può avere date_expiry; i ban attivi scaduti vengono disattivati durante il caricamento active-ban.
• Message: ogni ban può avere il proprio messaggio, altrimenti il modulo ripiega sul messaggio predefinito multilingua configurato.
• Multishop: record ban con id_shop=0 si applicano globalmente, mentre ban shop-specific si applicano solo nel contesto shop corrente.

Checkout-only CIDR example:
ip_cidr = 203.0.113.0/24
ban_type = checkout
reason = Repeated fraudulent checkout attempts

Sì, può creare o sincronizzare un job cron-job.org quando configurato. La configurazione admin PrestaShop può testare la chiave API cron-job.org, verificare la raggiungibilità esterna e puntare il job remoto all'URL cron tokenizzato di stato o esecuzione del modulo.

Flash sale, promozioni stagionali e offerte a tempo limitato funzionano meglio quando iniziano e finiscono automaticamente. Per pianificare sconti basati sul tempo in PrestaShop, usa Smart Dynamic & Scheduled Discounts: crea campagne con date di inizio e fine, e l'hook prezzo controlla finestra attiva, ambito prodotto, accesso per gruppo cliente e limiti d'uso, poi applica il miglior sconto idoneo al prezzo prodotto senza lavoro manuale. Poiché lo sconto è calcolato al momento della visualizzazione e del checkout, i prezzi tornano automaticamente quando la finestra si chiude: non devi ricordarti di annullare una promozione. Usa lo scope per gruppo cliente per offerte riservate ai membri, e affidati alla logica best-price per mantenere prevedibili le campagne sovrapposte. Mostra sempre il prezzo originale accanto all'offerta così il risparmio è visibile, e controlla che i prezzi pianificati rispettino eventuali regole di margine minimo che hai.

Il model campagna supporta tipi campagna come scheduled, recurring, flash sale, countdown, early bird e last chance, con tipi sconto percent, amount e fixed_price. Lo scope prodotto può essere assegnazione diretta prodotto/combinazione, categorie con sottocategorie opzionali, produttori, gruppi cliente o nessuno scope, nel qual caso una campagna attiva può applicarsi a tutti i prodotti. Gli sconti custom per prodotto possono sovrascrivere lo sconto campagna quando la riga prodotto non eredita il default.

Le campagne ricorrenti aggiungono righe schedule con finestre daily, weekly, monthly o custom, ore di inizio/fine e timezone. L'uso e tracciato per ordine/prodotto/cliente in mprdsd_campaign_usage, e il modulo controlla limiti d'uso totali, limiti per cliente e limiti quantità per prodotto prima di applicare uno sconto. L'hook prezzo usa deliberatamente il prezzo corrente passato da PrestaShop invece di chiamare Product::getPrice(), perché questo ricadrebbe ricorsivamente nell'hook prezzo. Poi sottrae il maggiore importo sconto idoneo dal prezzo calcolato corrente e non scrive mai righe native specific-price, motivo per cui lo sconto scompare automaticamente quando nessuna campagna è attiva.

Dipende da quale download intende:

• Un modulo con licenza, sì. I download con licenza sono legati al suo negozio, quindi il controller di download verifica la proprietà della licenza, la sua validità, il limite di download residui e che il negozio selezionato sia assegnato alla licenza, prima di emettere un URL di download tokenizzato. È quel vincolo a mantenere una licenza a pagamento legata al suo negozio.
• La demo gratuita di 30 giorni, no. Fornire email e dominio di installazione al momento del download è facoltativo. L'unica cosa che le garantisce è la comodità in seguito: se acquista con quella stessa email, il suo negozio può offrirle l'attivazione con un clic. Se lo salta, incollerà semplicemente una chiave di licenza.

Per l'intero percorso, dalla prova all'attivazione fino all'assistenza, veda Come funzionano licenze, attivazione e assistenza.

Sì, il modulo fornisce un workspace back office per i task pianificati. Può elencare task dei moduli che usano CronTrait condiviso, eseguire test, abilitare o disabilitare task, modificare schedule, eliminare task custom, consultare log e applicare cambi frequenza massivi.

Sì, può bloccare gli script corrispondenti finché il consenso non viene dato. Con il blocco script attivo, l'hook di output riscrive i tag come type text/plain con metadati categoria, e il JavaScript front ripristina solo gli script della categoria autorizzata.

Sì, la modalità dry-run mostra i risultati prima dell'eliminazione. Il modulo la abilita per impostazione predefinita, usa batch specifici per attività e limiti di sicurezza configurabili, e registra cronologia, trigger, righe interessate, stato dry-run e dipendente.

PrestaShop non ha un blog integrato, quindi per pubblicare articoli, guide e contenuti SEO aggiungi un modulo blog. Blog Revolution crea un blog completo dentro il tuo negozio: registra route dedicate per indice blog, singoli post, categorie, tag, autori, archivi mensili, ricerca e feed RSS, e aggiunge blocchi per homepage, colonne laterali, footer, pagine prodotto e listing in stile categoria, così i post più recenti emergono in tutto il negozio. Poiché il blog condivide tema, design e configurazione lingue, gli articoli ereditano automaticamente branding e URL multilingua. Un blog è uno degli investimenti SEO più efficaci per PrestaShop: intercetta query informative che pagine prodotto e categoria non possono coprire, costruisce link interni verso quelle pagine e guadagna backlink. Pianifica prima una struttura categorie, poi pubblica con costanza e collega ogni post ai prodotti pertinenti.

Nel codice, non è solo un wrapper di pagine CMS. Il modulo crea tabelle proprie per post, traduzioni post, categorie, tag, autori, commenti, link post-prodotto, tracking visualizzazioni/like, immagini, restrizioni gruppo e redirect slug. I post hanno campi SEO come meta title, meta description, meta keywords e canonical URL per lingua, e il modulo può emettere dati Open Graph, autodiscovery RSS, link hreflang e link paginazione previous/next dall'hook header.

Il prefisso URL predefinito è blog, quindi il set di route generato include percorsi come /blog, /blog/tag/{rewrite}, /blog/author/{slug}, /blog/archive/{year}/{month}, /blog/search e /blog/rss. I default assumono anche 12 post per pagina, griglia a tre colonne, commenti, rating, excerpt, metadati autore/data/visualizzazioni/commenti, social sharing, schema, hreflang, Open Graph e RSS abilitati. Questo ti offre una superficie di pubblicazione completa, ma dovresti comunque definire regole editoriali: quali post linkano ai prodotti, quali categorie mappano termini commerciali e quali vecchi URL dovrebbero reindirizzare invece di generare 404.

I tag canonical dicono a Google quale versione di una pagina è l'originale, prevenendo problemi di contenuto duplicato da filtri, paginazione e prodotti quasi identici. PrestaShop imposta automaticamente i canonical ma non ti offre un modo per sovrascriverli per pagina. Per impostare un canonical personalizzato per un prodotto, categoria, pagina CMS, produttore o fornitore specifico, usa Product Canonical Manager: crea una regola per l'entità target, inserisci l'URL a cui vuoi attribuire credito ai motori di ricerca e salva un valore diverso per lingua negozio quando necessario. Usalo quando più prodotti sono varianti di un master, quando una pagina CMS riprende un articolo blog o quando un URL campagna dovrebbe consolidarsi nella pagina prodotto pulita. Per capire come canonical, URL, schema e sitemap si integrano, vedi la nostra guida SEO PrestaShop.

Il modulo salva le regole in una tabella dedicata mprcanonical_rule e supporta i tipi entità product, category, cms, manufacturer e supplier. Ogni regola ha un'azione: override sostituisce un canonical esistente con l'URL entità, add_missing ne inserisce uno solo quando la pagina non ha già un canonical, e custom usa l'URL custom multilingua salvato sulla regola. Le regole possono anche impostare noindex e nofollow.

Per le regole prodotto, il resolver può corrispondere a un prodotto specifico, tutti i prodotti, prodotti per categoria, produttore o fornitore, e supporta esclusioni selector. Quando più regole corrispondono, la query ordina per priority DESC, quindi la regola con priorità più alta vince per il canonical URL, mentre i flag noindex/nofollow possono accumularsi. L'hook output modifica l'head HTML finito, quindi può sostituire tag canonical esistenti, aggiungere direttive robots, aggiungere link hreflang quando abilitato e normalizzare URL generati con rimozione parametri configurata, conversione in minuscolo e gestione slash finale opzionale.

Sì, può saltare sabati e domeniche quando l’esclusione dei weekend è attiva. Il calcolo PrestaShop non conta i giorni del fine settimana durante l’aggiunta del tempo di preparazione e sposta al lunedì un risultato finale che cade nel weekend.

Sì, l'area admin mostra i conteggi prima di eseguire la pulizia. In PrestaShop ogni task include una query di conteggio e il template mostra totale e singoli conteggi, così puoi eseguire una sola attività o tutte.

Sì. Le regole dei sottotitoli prodotto possono includere tutti i prodotti, prodotti specifici, prodotti in categorie, prodotti per produttore e prodotti per fornitore. Le regole di esclusione possono anche rimuovere prodotti specifici o corrispondenze di categoria da una regola più ampia.

Sì, gli IP in whitelist vengono controllati prima dei ban e non vengono mai bloccati dal matcher ban. Il modulo PrestaShop supporta entry whitelist per IP esatto o intervallo CIDR, con filtering shop-aware così i record whitelist shop-specific si applicano solo nel contesto shop pertinente.

La whitelist è basata su IP, non su paese o user-agent. Nel form admin, inserisci o un campo indirizzo IP o un intervallo CIDR, non entrambi. Il campo indirizzo IP è documentato per un singolo IP o wildcard come 192.168.1.*; il campo CIDR si aspetta notazione come 192.168.1.0/24.

Quando una richiesta viene controllata, isBanned() chiama prima isWhitelisted(). Se l'IP visitatore corrisponde a una riga whitelist, la funzione restituisce subito false e non viene applicato alcun ban paese, user-agent, IP esatto o CIDR. È utile per IP di ufficio, sviluppatori, provider pagamento o monitoraggio che non devono essere bloccati da regole ampie per paese o range.

• Storage: le righe whitelist salvano indirizzo IP, CIDR, label, employee ID, shop ID e creation date.
• Shop handling: quando multishop è attivo, la query whitelist carica righe per lo shop corrente e righe globali id_shop=0.
• Gotcha: una whitelist aiuta solo quando il modulo rileva lo stesso IP reale visitatore che hai salvato. Se un proxy o CDN cambia l'IP visto da PrestaShop, metti in whitelist l'indirizzo che PrestaShop riceve davvero.

Sì, supporta eventi Purchase lato server tramite Meta Conversions API. In PrestaShop il modulo mette in coda le conversioni d’acquisto, le invia alla versione Graph API configurata e usa event ID coerenti tra browser e server.

Sì, supporta risposte aggiuntive approvate e voti di utilità. In PrestaShop i record risposta salvano tipo autore, riferimenti cliente o dipendente, stato, conteggi voto e contenuto, mentre i voti su domande e risposte sono tracciati separatamente per entità e IP.

Sì, supporta Google Consent Mode v2 quando è attivato. Il modulo scrive un comando di consenso predefinito prima dei tag e aggiorna ad_storage, ad_user_data, ad_personalization e analytics_storage dopo che il cliente accetta o rifiuta i cookie in PrestaShop.

Il modulo rimane installato, ma hookDisplayHeader() non restituisce nulla perché isActive() richiede il Brand ID. L'avviso di configurazione obbligatoria informa inoltre lo staff che il tracciamento resta inattivo finché il Brand ID non viene aggiunto.

Sì, i task cron personalizzati possono essere aggiunti dal controller task. Il form admin PrestaShop valida modulo proprietario, schedule, contesto e tipo executor, e supporta task URL, callable e command, con i command limitati al contesto cron o a test admin espliciti.

Il generatore controlla il registro dei riferimenti del modulo, la tabella nativa orders e i riferimenti in order_payment. Prova fino a 10 candidati prima di registrare un errore e rinunciare.

Il resolver ordina le corrispondenze attive per priorità. In modalità singola restituisce il sottotitolo con priorità più alta; in modalità tutti restituisce l'elenco ordinato, così il template può mostrare più di un sottotitolo.

Sì, le scelte di consenso possono essere registrate quando il logging è attivo. Il controller AJAX PrestaShop salva mappa del consenso, sorgente e versione, mentre il modello log esegue hash di visitatore, IP e user agent invece di salvarli in chiaro.

Puoi aggiungere Criteo OneTag a PrestaShop configurando un Criteo Partner ID numerico e attivando il tracking browser. Il modulo costruisce poi eventi OneTag nell'header per le pagine e-commerce supportate e resta inattivo se il Partner ID manca o non è valido.

Puoi raccogliere IP visitatore e informazioni dispositivo con questo modulo PrestaShop quando la raccolta è attiva. Salva ID cliente o ospite, ID negozio, indirizzo IP, dati paese, dettagli dispositivo analizzati e campi opzionali user agent, sistema operativo, browser e risoluzione schermo.

Sì, il modulo contiene un percorso ban authentication automatico per login PrestaShop falliti, ma gira solo quando il recorder failed-login del modulo viene invocato dall'integrazione authentication. Ogni failure registrato salva IP visitatore, email tentata, user agent, shop ID e timestamp in mprceiipban_failed_logins.

Le due impostazioni che controllano il ban sono MPRCEIIPBAN_AUTOBAN_THRESHOLD e MPRCEIIPBAN_AUTOBAN_WINDOW. I default install sono threshold 0 e window 60 minuti, quindi auto-ban è disattivato finché non viene configurata una soglia positiva. Quando il numero di failure dallo stesso IP dentro la finestra configurata raggiunge la soglia, il modulo aggiunge un ban auth con reason Auto-banned: X failed login attempts in Y min e scadenza un'ora nel futuro.

Un ban auth è più stretto di un ban full site: punta alle pagine legate all'autenticazione, mentre i full ban esistenti hanno comunque precedenza. Poiché questo sorgente contiene recorder e logica ban ma non un file override authentication concreto, verifica che la build installata includa l'integrazione authentication prima di affidarti a essa come unica protezione login.

Il contatore soglia è basato su IP. L'email fallita viene salvata per review, ma countRecentFailedLogins() conta solo righe con lo stesso ip_address più recenti della finestra configurata; non conta separatamente per indirizzo email tentato. Il controllo auto-ban salta anche la creazione di un nuovo ban auth temporaneo se l'IP è già sotto un full ban.

• Per abilitarlo: imposta AUTOBAN_THRESHOLD a un numero positivo come 5 e lascia o modifica AUTOBAN_WINDOW in minuti.
• Cosa viene creato: una riga attiva in mprceiipban_banned con ban_type=auth, IP visitatore e date_expiry di un'ora.
• Cleanup: le righe failed login sono coperte dal percorso purge del modulo, che usa i giorni di retention log configurati.

AUTOBAN_THRESHOLD = 5
AUTOBAN_WINDOW = 60
Result after 5 failures from one IP in 60 minutes: temporary auth ban for 1 hour

PrestaShop include una sola pagina contatto fissa, che non basta quando ti servono richieste preventivo, richieste B2B, intake supporto o iscrizioni eventi. Per costruire i tuoi form, usa Better Contact Form: salva form e campi in tabelle dedicate e li renderizza tramite un controller modulo o hook, con gestione funzionante dei valori inviati per campi text, email, phone, textarea, select, checkbox, URL e number. Puoi creare più form per scopi diversi, posizionarli su qualsiasi pagina e raccogliere invii strutturati invece di email a testo libero. Mantieni ogni form breve, marca chiaramente i campi obbligatori e aggiungi protezione anti-spam. Per GDPR, includi una checkbox di consenso e un link alla privacy policy così i dati della richiesta vengono raccolti legittimamente.

Il template ha anche un ramo input file, ma l'attuale processor submission legge i valori campo tramite Tools::getValue() e non gestisce $_FILES. Questo significa che i campi file possono essere renderizzati, ma i file caricati non vengono persistiti come valori campo inviati nell'implementazione attuale. Non fare affidamento sulla raccolta upload file salvo aggiunta della gestione file.

Form, campi, invii e singoli valori submission sono salvati in tabelle separate, quindi una richiesta mantiene sia una riga riepilogo sia dati campo strutturati. Il renderer può scegliere un form specifico o il form predefinito attivo, non restituisce nulla quando un form è inattivo o non ha campi e precompila nome/email del cliente loggato quando disponibili.

L'elaborazione submission controlla che il pulsante submit sia stato postato, esegue controlli su campi obbligatori, validazione tipo, validazione opzioni select, metodi di validazione PrestaShop opzionali, enforcement checkbox GDPR, rilevamento spam e persistenza database. Il valore nascosto _mpr_ft non è un token CSRF; è un timestamp base64 usato dal controllo anti-spam timing. Honeypot e time-check anti-spam sono abilitati di default, con tempo minimo di invio predefinito di 3 secondi. Gli invii spam sono comunque salvati con is_spam e spam_reason, ma le email admin/cliente vengono inviate solo per invii non spam. Questo offre una traccia audit senza lasciare che traffico bot evidente attivi notifiche.

Le recensioni fotografiche permettono agli acquirenti di allegare immagini reali dei prodotti alle loro valutazioni, aumentando la fiducia e aggiungendo contenuto unico e ricco di keyword alle pagine prodotto. PrestaShop non ha una funzione integrata di recensioni con immagini, quindi la aggiungi con un modulo recensioni. Con Product and Store Reviews, abilita gli upload immagini nelle impostazioni recensioni: il form accetta poi file JPEG, PNG e WebP, applica dimensione file massima e numero massimo immagini, ridimensiona automaticamente gli upload grandi, genera miniature e collega le immagini al record recensione salvato. Le recensioni fotografiche approvate vengono mostrate accanto al prodotto e alimentano i rich result star-rating. Imposta un limite sensato - per esempio 3-5 immagini per recensione - e mantieni la moderazione attiva così solo foto autentiche e pertinenti vanno online. Le foto dei clienti riducono anche i resi impostando aspettative accurate prima dell'acquisto.

Nella fonte locale questa funzione vive nel modulo mprcomments. Gli upload immagini sono abilitati da ALLOW_IMAGES, con default di 3 immagini per recensione e 2 MB per immagine. Il template recensione prodotto usa un input file multiplo chiamato review_images[] e accetta image/jpeg, image/png e image/webp. L'uploader valida MIME type, dimensione file e dimensioni immagine, poi ridimensiona le immagini grandi a un massimo di 1200 per 1200 pixel e crea miniature 150 per 150.

La recensione viene salvata prima con stato pending o approved in base alle impostazioni di moderazione, poi gli upload immagini vengono processati subito contro quell'ID recensione salvato. L'approvazione controlla la visibilità pubblica, non l'allegato immagine. La normale validazione recensione si applica comunque prima: il contenuto recensione deve rispettare la lunghezza minima, il rating deve essere tra 1 e 5, gli ospiti sono bloccati salvo autorizzazione, le recensioni cliente duplicate vengono controllate e la moderazione può lasciare la recensione pending invece che immediatamente pubblica. I dati strutturati sono intenzionalmente basati su recensioni prodotto native; le recensioni aziendali importate sono escluse dallo schema prodotto, e il renderer schema limita le review item incorporate pur emettendo aggregate rating quando esistono recensioni native.

I clienti possono inviare gallerie di progetto dal flusso front-office del modulo. In PrestaShop lo showcase salva progetti, titoli e descrizioni multilingua, immagini, categoria e stato di moderazione, con limiti predefiniti di 20 immagini e 5 MB per immagine.

No. Il modulo verifica se mprcheckoutrevolution è installato e abilitato. Quando è attivo, questo modulo gli lascia l'interfaccia di modifica degli ordini invece di gestire direttamente gli hook di modifica ordine.

In PrestaShop l'H1 della pagina categoria è il nome categoria, quindi cambiare l'heading per SEO di solito cambia anche etichette menu e breadcrumb, cosa che normalmente non vuoi. La soluzione è sovrascrivere l'H1 in modo indipendente. Con Custom Category H1, salvi un valore H1 separato per categoria e il modulo lo sostituisce nella pagina categoria tramite hook PrestaShop, lasciando intatto il nome dell'oggetto Category (e quindi navigazione e breadcrumb). Questo ti permette di puntare a un heading ricco di keyword come "Piatti doccia impermeabili per wet room" mentre il menu continua a leggere un breve "Piatti doccia". Nota che le categorie root sono intenzionalmente escluse, perché non renderizzano una normale pagina categoria storefront con H1 visibile all'acquirente. Usa un H1 chiaro e unico per categoria e mantienilo allineato al title tag della pagina: vedi la nostra guida SEO PrestaShop.

Il modulo salva gli override in tabelle dedicate per righe override, valori lingua e assegnazioni categoria. I default sono abilitato, mostra campo modifica categoria, sostituisce il nome pagina categoria nel contenuto categoria filtrato, applica lo stesso valore alle etichette product-listing, ripiega sulla lingua predefinita, ripiega da un valore specifico negozio a un valore all-shops, rimuove tag HTML e normalizza gli spazi. Esiste fallback categoria padre, ma è disabilitato di default per evitare heading duplicati tra categorie figlie.

Per lavoro SEO bulk, un override può essere assegnato a più categorie. Se un merchant modifica poi direttamente una categoria e quella categoria appartiene a un override condiviso, il codice stacca quella singola categoria e crea un override locale alla categoria, lasciando l'override condiviso alle altre. Il valore H1 può usare placeholder come {category_name}, {nb_products}, {page}, {page_label}, {shop_name} e {lang}. La paginazione può anche aggiungere automaticamente un'etichetta pagina quando abilitata. Il modulo cambia i dati categoria renderizzati; non rinomina il record categoria PrestaShop salvato.

Registra displayHeader, displayOrderConfirmation, actionValidateOrder e actionCustomerAccountAdd. Questi hook renderizzano il tracking browser e mettono in coda dati di conversione legati a ordini o registrazioni.

Il form offre virgola, punto e virgola, tabulazione e pipe. Il controller converte l'opzione tab in un vero carattere di tabulazione prima di inviare il CSV in streaming.

Lo schema include tabelle per team, dipendenti dei team, mapping team-stato, stati workflow e traduzioni, storico ordine, commenti ordine, promemoria, notifiche e preferenze di notifica dei dipendenti.

No. Il codice di rilevamento controlla se il riferimento prodotto inizia con mpr-pack-. I contenuti del pack vengono poi letti dalla tabella propria del modulo mpr_pack_content.

L'hook controlla actionDispatcherBefore e gestisce solo Dispatcher::FC_FRONT e Dispatcher::FC_MODULE. I dispatch Back Office vengono ignorati.

hookPaymentOptions() richiede modulo attivo, configurazione abilitata, cliente loggato, almeno un termine di pagamento attivo assegnato ai gruppi del cliente e credito sufficiente per il totale del carrello corrente.

Rileva il paese visitatore in un ordine fallback fisso. Il modulo legge prima l'header Cloudflare HTTP_CF_IPCOUNTRY quando esiste e non è XX. Se non è disponibile, prova PrestaShop GeoIP tramite GeoIp::getCountryByAddr($ip) e converte il nome paese restituito di nuovo in codice ISO. Se GeoIP non è disponibile, controlla infine il cookie di contesto PrestaShop iso_code_country.

1. Cloudflare reverse proxy sends HTTP_CF_IPCOUNTRY=US -> module stores country code US and resolves the country name.
2. No Cloudflare header -> PrestaShop GeoIP returns United States -> module looks up ISO code US.
3. GeoIP unavailable -> PrestaShop cookie iso_code_country=US is used.
4. No signal -> empty country code and empty country name.

Questo significa che i ban paese dipendono dal segnale disponibile per quella richiesta. Se ti affidi alla country detection di Cloudflare, assicurati che il traffico shop raggiunga davvero PrestaShop attraverso Cloudflare così l'header è presente.

L'IP visitatore usato per GeoIP viene da Tools::getRemoteAddr() quando PrestaShop lo fornisce. Il modulo ha una fallback chain per HTTP_CF_CONNECTING_IP, HTTP_X_REAL_IP, il primo valore da HTTP_X_FORWARDED_FOR, poi REMOTE_ADDR. Questo conta perché la qualità GeoIP dipende dal vero IP client, non dall'IP di un proxy intermedio.

Un ban paese corrisponde solo quando la richiesta corrente ha un codice paese non vuoto. Se Cloudflare invia XX, GeoIP manca, il lookup nome-paese non può mappare il risultato GeoIP a un codice ISO e il cookie è assente, allora regole solo paese non scatteranno per quella richiesta. VPN, proxy e configurazione CDN possono anche far differire il paese rilevato dalla posizione fisica dell'acquirente.

Il controller checkout personalizzato reindirizza i clienti alla pagina ordine nativa di PrestaShop quando il one page checkout è disattivato. Il modulo quindi non forza il proprio flusso se l'impostazione one_page_checkout_enabled è spenta. Così la configurazione resta collegata alle impostazioni del modulo e al comportamento reale di PrestaShop.

Sì, il modulo include strumenti di import ed export per contenuti blog. Il controller admin PrestaShop può importare XML WordPress WXR, inclusi commenti opzionali, ed esportare i dati blog in XML o JSON tramite il servizio BlogExporter.

Il banner ricompare quando il cookie di consenso manca o è scaduto. Nel front office PrestaShop il JavaScript legge mprcookie_consent e nasconde il banner ai clienti di ritorno; la scadenza configurata controlla la durata della scelta, con 365 giorni di default.

Sì, il modulo ha un interruttore per la visualizzazione mobile. Prima di renderizzare il widget Crisp, il guard PrestaShop controlla l'impostazione SHOW_MOBILE e il contesto dispositivo; se il mobile è disattivato e il contesto è mobile, non viene emesso script Crisp.

No. S2S_ENABLED è false di default. Il pannello readiness considera esplicitamente S2S come opzionale, e il tracking Pixel browser può funzionare con un Marketer ID valido e tracking browser abilitato.

Sì, i merchant possono definire regole trigger personalizzate per eventi Criteo supportati. La configurazione PrestaShop accetta regole JSON validate con trigger click, URL, controller o evento DOM, poi normalizza i nomi evento al vocabolario OneTag supportato da Criteo.

Il Front Controller accetta un nome evento e parametri JSON, rifiuta payload oltre 8192 caratteri, mantiene al massimo 50 chiavi normalizzate per livello, limita la profondità di annidamento e tronca i valori stringa a 512 caratteri.

No, la disinstallazione non rimuove le tabelle cron condivise. Il percorso uninstall PrestaShop rimuove il menu admin del modulo e deregistra i suoi task, ma mantiene volutamente le tabelle cron perché altri moduli MPR possono dipendere dalla stessa infrastruttura.

No, le categorie root vengono rifiutate dalla logica di salvataggio override. Il controller admin PrestaShop verifica che le categorie selezionate siano categorie storefront, perché le root non renderizzano normali pagine categoria dove un H1 visibile al cliente sarebbe applicato.

Sì, il modulo include uno scanner cookie del front office. Può eseguire crawl di un URL PrestaShop, ispezionare header Set-Cookie e assegnazioni inline document.cookie, salvare nuovi cookie non categorizzati e suggerire categorie per pattern noti analytics, marketing e funzionali.

Sì, può abbinare pattern user agent come target di ban. Nell'admin PrestaShop, una regola può usare testo semplice per un contains case-insensitive oppure una regex racchiusa tra slash, e può essere combinata con filtri IP, CIDR o paese.

No, gli upload di file non vengono elaborati dal codice attuale di invio. L'elenco campi admin include un input file, ma il processore legge i valori con Tools::getValue e non gestisce array PHP files, percorsi di salvataggio o allegati email.

Sì. Il validatore accetta cifre separate da virgole o spazi, entro le regole di lunghezza configurate, quindi è possibile salvare più ID numerici nel campo Marketer ID.

Il pannello diagnostico include un'azione Retry failed events. Chiama il reset della queue condivisa per questo modulo e il provider outbrain, riportando gli eventi falliti allo stato pending.

Il modulo salva gli ID prodotto nel cookie browser del visitatore mprrecent_ids. Il cookie viene scritto con path /, durata di 30 giorni e SameSite=Lax.

No. Il controller AJAX crea un oggetto Product per ogni ID richiesto e salta le voci non caricate o non attive prima di restituire i dati delle card prodotto.

La risposta AJAX include nome di ogni prodotto, URL prodotto, URL immagine cover usando home_default e prezzo formattato. Lo script front renderizza questi valori come card prodotto compatte.

No, non serve un account, e la descrizione sorgente dice che funziona per guest, clienti loggati e visitatori di ritorno. Ricorda le pagine prodotto recenti in un cookie del browser invece di riempire una tabella PrestaShop di storico utente. Dovresti comunque descrivere l'uso del cookie nella privacy o cookie information dove i requisiti legali del tuo store lo richiedono.

Lo script storefront usa un cookie chiamato mprrecent_ids. Sulle pagine prodotto, mette l'ID prodotto corrente all'inizio della lista, rimuove duplicati, limita la lista al massimo configurato e scrive il cookie per 30 giorni con SameSite=Lax. Il default install è MAX_PRODUCTS=8, e l'hook display predefinito è displayFooterProduct.

Quando il widget viene renderizzato, il browser legge il cookie e posta la lista ID prodotto al controller AJAX del modulo. Il controller sanifica gli ID con intval, rimuove valori vuoti, limita la richiesta a 20 ID e restituisce solo prodotti attivi. La risposta contiene ID prodotto, nome, URL, immagine cover e prezzo formattato così il widget può disegnare la lista recent-products.

Quindi il modulo non costruisce un profilo di navigazione server-side legato a un account cliente. Il server riceve comunque gli ID prodotto recenti durante la lookup AJAX, e gli ID sono salvati nel cookie browser del visitatore, quindi la funzione resta tracking basato su cookie dal punto di vista di una privacy notice.

Inserisci l'AdRoll Advertiser ID da adroll_adv_id, inserisci il Pixel ID da adroll_pix_id, abilita browser tracking e scegli gli eventi da inviare. Entrambi gli ID devono contenere solo lettere, numeri, underscore o trattini, e il tracking resta inattivo finché gli ID non sono validi e il modulo è abilitato.

• Setup richiesto: Advertiser ID, Pixel ID e browser tracking abilitato.
• Eventi page journey: page view, product view, checkout start e search.
• Eventi interazione: add to cart, add to wishlist, signup ed eventi browser custom configurati.
• Evento purchase: inviato su conferma ordine quando purchase tracking è abilitato.

Il modulo è un'integrazione browser Pixel. I suoi demo metadata indicano AdRoll server-side purchase come non disponibile perché l'accesso pubblico AdRoll S2S non è esposto in questo modulo come flusso stabile token/endpoint.

All'installazione, il browser tracking stesso è disabilitato di default, mentre i toggle evento standard sono abilitati di default. Questo permette al merchant di configurare prima gli ID e poi attivare tracking quando pronto. Employee exclusion e rispetto consenso marketing sono entrambi abilitati di default, così dipendenti back-office che navigano lo storefront e visitatori senza consenso marketing supportato possono essere soppressi prima che gli eventi vengano inviati.

L'hook header prepara la coda AdRoll, imposta window.adroll_adv_id, window.adroll_pix_id e window.adroll_version='2.0', poi carica https://s.adroll.com/j/roundtrip.js. Gli eventi header sono costruiti server-side per page view, product view, checkout start, search e signup, mentre add-to-cart e wishlist sono collegati in JavaScript a eventi PrestaShop o selector pulsante comuni.

Gli eventi browser custom sono opzionali e disabilitati di default. Se abilitati, il JSON deve essere un array o un oggetto con array events. I nomi evento sono limitati a lettere, numeri, underscore e trattini, con limite 64 caratteri, e questo modulo limita gli eventi custom a 15 nomi evento distinti. I trigger supportati sono click, url, controller e event.

[{"event":"GalleryBrowse","trigger":"click","selector":".product-images img","params":{"segment_name":"gallery_browse"}}]

Sì, purchase tracking invia valore ordine e valuta dalla pagina conferma ordine PrestaShop. Il modulo costruisce anche item count, riferimento ordine, product ID, nomi, categorie, prezzi e quantità, poi invia l'evento purchase tramite browser pixel quando purchase tracking è abilitato.

L'hook order-confirmation controlla prima il normale tracking gate: il modulo deve essere attivo, gli ID devono essere validi, employee exclusion non deve bloccare la richiesta, il consenso marketing deve passare quando abilitato e TRACK_PURCHASE deve essere on. Poi accetta order o objOrder dai parametri hook PrestaShop e costruisce il payload purchase da quell'ordine caricato.

La mappatura value è esplicita. I dati conversion comuni sono convertiti in parametri stile AdRoll: value diventa conversion_value, currency diventa adroll_currency, num_items resta item count, order_id è impostato al riferimento ordine PrestaShop, e i dati prodotto diventano product_id, content_ids e un array products con item ID, name, price e quantity dove disponibili.

L'evento è comunque browser-side. Il template chiama window.mpradrollTrack('purchase', params, 'Order confirmation') quando lo script header è presente, oppure ripiega su window.__adroll.track/window.adroll.track. Se la funzione legacy record_user di AdRoll esiste, il template chiama anche quella, ma il modulo non invia una richiesta purchase server-to-server.

Sì. Quando MPRADROLLPIXEL_RESPECT_CONSENT è abilitato, il modulo controlla i moduli cookie-consent supportati prima di renderizzare o sparare tracking AdRoll. Con mprcookiesrevolution, il consenso marketing è concesso solo quando il cookie mprcr_consent contiene marketing:1. Con mprcookiebanner, il consenso è concesso quando mprcookie_consent=granted. Se il cookie pertinente manca, il modulo ripiega sul valore DEFAULT_CONSENT di quel modulo consenso.

mprcookiesrevolution allowed: mprcr_consent=essential:1|marketing:1|statistics:1
mprcookiesrevolution blocked: mprcr_consent=essential:1|marketing:0|statistics:1
mprcookiebanner allowed: mprcookie_consent=granted

Se nessuno dei moduli consenso supportati è attivo, il controllo consenso non blocca il tracking. Employee exclusion può comunque sopprimere il tracking separatamente quando MPRADROLLPIXEL_EXCLUDE_EMPLOYEES è abilitato.

I default install sono orientati alla privacy: RESPECT_CONSENT=1 ed EXCLUDE_EMPLOYEES=1. Il metodo server-side canTrack() restituisce false se il modulo è inattivo, un contesto dipendente valido sta navigando il front office o il consenso marketing non è concesso secondo i controlli dei moduli consenso supportati.

Anche il template browser esegue un controllo consenso prima di caricare AdRoll. Quando un modulo consenso supportato è attivo, controlla window.MPRCR.isGranted('marketing') se disponibile, poi gli stessi due cookie. Se quel controllo client-side fallisce, lo script ritorna prima di caricare roundtrip.js o sparare eventi accodati. Una gotcha pratica è che il controllo client-side non conosce il valore server-side DEFAULT_CONSENT, quindi un setup che dipende dal consenso default granted senza cookie consenso va testato nel browser.

No, questo modulo invia eventi AdRoll tramite browser pixel, non tramite una API server-side pubblica. Il codice PrestaShop include una nota demo secondo cui AdRoll S2S è una beta gestita dal supporto; in produzione carica roundtrip.js e invia solo eventi browser.

Usa questo modulo per impostare display name separati per le pagine CMS PrestaShop. Salva un display name per id_cms, lingua e shop nella propria tabella mprcmsnames, quindi il record CMS nativo e il suo meta_title SEO non vengono riscritti nella tabella CMS.

• Esempio: mantieni il meta title della pagina CMS come Terms and Conditions | My Shop per SEO.
• Apri la schermata CMS Display Names del modulo e trova quella riga pagina CMS per ID e meta title esistente.
• Inserisci un display name più corto come Terms nel campo Display Name e salva.
• Sul front office, l'heading della pagina CMS riceve il display name tramite filterCmsContent, e i link CMS che corrispondono al pattern cms-page-link di PrestaShop vengono sostituiti nell'HTML finale.
• Se svuoti il campo display name, il modulo elimina la propria riga custom per quella pagina CMS e lo shop ripiega sul meta_title CMS originale.

Quindi la divisione pratica è: usa il titolo CMS nativo per snippet di ricerca e comportamento browser title, e usa questo modulo per heading pagina, link footer e label menu più brevi che gli acquirenti leggono davvero.

Il modulo ha due percorsi front-office. Primo, filterCmsContent cambia l'oggetto CMS passato al template pagina sostituendo meta_title con il display name salvato per lingua e shop correnti. Secondo, actionOutputHTMLBefore modifica l'HTML finale per link CMS corrispondenti prima che la risposta venga inviata.

Il commento sorgente è esplicito: il vero tag HTML <title> non è influenzato perché PrestaShop lo costruisce tramite Meta::getMetaTags() usando il proprio percorso SQL. Per questo il modulo può accorciare nomi visibili senza sovrascrivere il titolo SEO CMS salvato da PrestaShop.

Il markup tema conta comunque. La relabel dei link gira solo su anchor che corrispondono al pattern link CMS atteso dal modulo, con l'ID pagina CMS in link-cms-page-{id}-... e l'esatto attributo classe cms-page-link nell'ordine atteso dalla regex. Se un tema costruisce menu CMS con markup diverso o HTML annidato dentro il testo anchor, l'heading può comunque essere cambiato ma il testo link potrebbe non essere sostituito.

No, non riscrive il tag HTML title. Il modulo è intenzionalmente limitato al contenuto CMS visibile e al testo dei link CMS renderizzati, così PrestaShop può continuare a usare il meta title CMS originale per l'head pagina e gli snippet di ricerca.

Il commento sorgente dice che il tag <title> è costruito dal percorso Meta::getMetaTags() di PrestaShop ed è non influenzato. Il modulo non aggiorna la tabella CMS nativa, non si aggancia alla generazione meta tag e non scrive un nuovo titolo SEO in PrestaShop.

Ciò che può cambiare è l'oggetto CMS passato tramite filterCmsContent. Se il template pagina usa il meta_title di quell'oggetto CMS filtrato come heading visibile, gli acquirenti vedono il display name più corto sulla pagina. Separatamente, actionOutputHTMLBefore può sostituire il testo dei link CMS corrispondenti nell'HTML finale. Sono cambi di contenuto visibile, non cambi di head tag.

Per lavoro SEO, continua a modificare il vero meta title CMS nella pagina CMS nativa PrestaShop. Usa questo modulo quando il titolo SEO è troppo lungo per menu, footer, breadcrumb o heading on-page.

Rinomina i link CMS che corrispondono al markup link CMS atteso da PrestaShop. L'hook output cerca un anchor il cui id inizi con link-cms-page-{id}- e la cui classe sia cms-page-link, poi sostituisce il testo link semplice con il display name salvato per lingua e shop correnti.

<a id="link-cms-page-3-1" class="cms-page-link" href="/content/3-terms-and-conditions">Terms and conditions</a>

Quel pattern conta per temi personalizzati: se il link CMS ha una classe diversa, nessun id link-cms-page-..., la classe appare prima dell'id nel markup target del modulo, oppure la label è costruita da HTML annidato invece che testo semplice, la sostituzione output potrebbe non trovarlo.

La regex è volutamente stretta. Si aspetta l'attributo id prima di class="cms-page-link", e cattura testo semplice tra tag anchor di apertura e chiusura. Un link con classi multiple come class="footer-link cms-page-link", uno span dentro l'anchor o un componente menu completamente custom può restare fuori dal pattern.

La sostituzione inoltre non fa nulla nel back office e ritorna presto se non ci sono display name per lingua e shop correnti. Se il footer o menu CMS del tuo tema non viene rinominato, ispeziona prima il markup anchor generato; spesso la correzione è fare in modo che il template produca il pattern ID e classe CMS nativo di PrestaShop.

Sì, i display name sono salvati per pagina CMS, lingua e shop. La tabella del modulo usa id_cms, id_lang e id_shop come chiave, e salvare un valore vuoto rimuove quella label salvata così PrestaShop ripiega sul titolo CMS nativo.

Anche il lookup front-office è specifico per lingua e shop. Carica righe da mprcmsnames dove id_lang uguale alla lingua corrente del contesto e id_shop uguale allo shop corrente del contesto. In questo lookup non esiste un fallback ampio id_shop=0, quindi un display name salvato per uno shop non viene automaticamente riusato da un altro.

Al salvataggio, il modulo itera pagine CMS e lingue, sostituendo righe quando viene postato un valore e cancellando righe quando il valore inviato è vuoto. Per questo svuotare un campo è un vero reset, non solo una label custom vuota.

Un dettaglio implementativo da controllare in questa versione sorgente: la tabella configurazione renderizzata mostra l'input della lingua predefinita per ogni pagina CMS. Database e logica salvataggio supportano id_lang, ma il form visibile in questo checkout non renderizza colonne input separate per ogni lingua. Se ti servono display name in lingue non predefinite, conferma che la build installata esponga quegli input o aggiungili prima di affidarti all'editing multilingua dal form standard.

Sì, il modulo genera automaticamente una password per i form registrazione e checkout supportati. In PrestaShop punta ai campi password comuni di customer, authentication e checkout, poi riempie input password, passwd, confirmation e password_confirmation quando lo scope pagina configurato corrisponde.

I default install abilitano il modulo, lo applicano sia a registrazione sia a checkout, nascondono i campi password, generano una password di 12 caratteri e includono lettere maiuscole, numeri e caratteri speciali. I controller applicabili sono authentication, registration e identity per registrazione, più order, orderopc e order-opc per checkout.

Su PrestaShop 1.7+, il modulo registra CSS e JavaScript front tramite actionFrontControllerSetMedia. Su PrestaShop 1.6, carica gli asset da displayHeader. Lo stesso hook header inietta le impostazioni password in window.mprcustomerpassword_config perché JavaScript le usi.

Lo script front trova campi nominati come password, passwd, confirmation e password_confirmation, e scansiona anche form registration/authentication comuni per qualsiasi input type=password. Genera una password per pagina, riempie tutti i campi corrispondenti con lo stesso valore, imposta autocomplete=new-password e aggiunge al form un marker nascosto mprcustpass_auto=1.

• Hidden mode: il wrapper del campo password viene nascosto e marcato aria-hidden.
• Optional mode in code: il campo viene mostrato con il valore generato e un messaggio informativo, ma lo script imposta il campo a readonly.
• Dynamic checkout forms: un MutationObserver rielabora campi password appena inseriti, e lo script protegge i valori generati al submit e con un controllo periodico.

Sì, può inviare via email la password generata quando la modalità email è impostata a send password. L'hook account-add PrestaShop invia quella email solo quando il form inviato include il marker di autogenerazione del modulo, così gli account cliente normali non vengono processati accidentalmente.

Il default EMAIL_MODE è send_password. Quando actionCustomerAccountAdd gira, il modulo controlla prima che sia abilitato, poi controlla mprcustpass_auto nel form inviato. Quel marker è aggiunto da JavaScript solo dopo aver riempito i campi password, quindi il percorso email è legato alle password generate dal modulo.

Per l'email password, il modulo legge la password inviata da password prima e ripiega su passwd per form PrestaShop più vecchi. Se nessun valore è presente al momento dell'hook, ritorna senza inviare. Quando invia, usa il template email mprcustomerpassword_account e passa nome, cognome, email, password generata, nome shop e URL shop del cliente.

Ci sono due alternative importanti. Con EMAIL_MODE=silent, l'hook esce senza inviare alcuna email password. Con EMAIL_MODE=setup_link, invia un link reset/setup invece della password generata. I merchant che non vogliono password inviate via email dovrebbero usare setup-link o silent mode invece del default send-password.

Sì, il modulo può inviare un link di setup invece della password generata. In PrestaShop setup-link mode crea un token reset, salva una validità di 24 ore sul record cliente o sui campi legacy e invia al cliente un link alla pagina password.

Questo percorso viene selezionato con EMAIL_MODE=setup_link. Si applicano comunque lo stesso hook account-add e il marker mprcustpass_auto, quindi l'email setup viene inviata solo per account dove lo script front del modulo ha generato e inviato i campi password.

Sugli oggetti cliente PrestaShop più nuovi che espongono reset_password_token, il modulo crea un token da random_bytes(32), lo rende URL-friendly sostituendo caratteri base64 non sicuri, lo salva in reset_password_token, imposta reset_password_validity a 24 ore nel futuro, aggiorna il cliente e costruisce un URL pagina password con token, id_customer e reset_token.

Per il percorso legacy, il modulo crea un token MD5, aggiorna direttamente i campi tabella customer reset_password_token e reset_password_validity con finestra di validità 24 ore, e costruisce l'URL pagina password con token e id_customer. L'email usa il template mprcustomerpassword_setup con {setup_link}, valori identità cliente, nome shop e URL shop.

La password generata viene comunque usata per permettere a PrestaShop di creare l'account durante checkout o registrazione. La differenza è ciò che il cliente riceve dopo: setup-link mode invia un link per scegliere una password, mentre send-password mode invia la password generata stessa.

No, la modalità opzionale mostra la password generata ma lo script attuale rende il campo in sola lettura. In PrestaShop la modalità nascosta elimina il blocco password, mentre quella opzionale lascia visibile il valore con una nota informativa.

Aggiungi un Facebook Page Access Token e Page ID, poi abilita il feed. In PrestaShop il modulo recupera post dalla Facebook Graph API e può renderizzarli negli hook home, footer, left column o right column.

Il form connessione richiede Page Access Token e Page ID. L'aiuto admin indirizza i merchant verso una Facebook Developer app con accesso Pages API e permessi pages_read_engagement e pages_read_user_content. Page Name è opzionale e viene usato per l'header feed quando fornito.

• L'hook display predefinito è displayHome, ma il modulo supporta anche displayFooterBefore, displayFooter, displayLeftColumn e displayRightColumn.
• Il conteggio post predefinito è 6, il layout predefinito è una griglia a 3 colonne, e la cache feed condivisa è di default 3600 secondi.
• Se access token o Page ID mancano, il fetch Facebook API non restituisce post, quindi il blocco front-office non ha nulla da renderizzare.

MPRFB_ACCESS_TOKEN=your-page-token
MPRFB_PAGE_ID=your-page-id
MPRFB_DISPLAY_HOOK=displayHome
MPRFB_POST_COUNT=6

Quando configurato, il modulo chiama Facebook Graph API v21.0 per i post della pagina, salva il feed normalizzato in cache e renderizza solo nell'hook selezionato nelle impostazioni modulo.

Sì, può mostrare testo post, media, data, reactions, shares, comments e informazioni autore. In PrestaShop queste opzioni display sono configurate separatamente, e i post condivisi possono essere esclusi quando l'impostazione EXCLUDE_SHARED è abilitata.

Gli switch pertinenti sono impostazioni separate come SHOW_TEXT, SHOW_MEDIA, SHOW_DATE, SHOW_REACTIONS, SHOW_SHARES, SHOW_COMMENTS e SHOW_AUTHOR. Il testo è abilitato di default e viene troncato con ellissi quando supera TEXT_LENGTH, che di default è 200 caratteri.

• I media vengono presi prima da attachment e subattachment Facebook, con full_picture usato come fallback.
• I conteggi reaction, comment e share vengono dai campi summary restituiti da Facebook, quindi i conteggi mostrati dipendono da ciò che la risposta API include.
• Quando EXCLUDE_SHARED è abilitato, i post con status_type uguale a shared_story vengono saltati.
• I post senza testo messaggio né immagine vengono saltati prima del rendering.

Questo conta perché un merchant può costruire un blocco social proof compatto con sole immagini e conteggi engagement, oppure un feed editoriale più completo con didascalie, date e attribuzione pagina.

I progetti approvati supportano il voto della community e i commenti nidificati. Il numero di voti e di visualizzazioni viene salvato per ogni progetto, offrendo un semplice segnale di quali lavori dei clienti riscuotono più interesse.

Sì. Il modulo mette in cache il feed Facebook in un file JSON chiamato mprfb_feed_cache.json. La cache salva un timestamp cached_at e i posts recuperati, poi riusa quei post finché la durata configurata non scade.

Cache file: mprfb_feed_cache.json
Duration setting: MPRFB_CACHE_DURATION=3600
Admin refresh: submitMprfbSync clears the file; the next front-office feed load fetches fresh posts and writes cached_at + posts

La durata cache predefinita nel trait feed condiviso è 3600 secondi. Il form configurazione del modulo espone durate comuni come 30 minuti, 1 ora, 2 ore, 6 ore, 12 ore e 24 ore. Le azioni admin refresh e clear-cache rimuovono entrambe il file cache, quindi la richiesta feed successiva è forzata a tornare alla fonte Facebook invece di servire post in cache obsoleti.

La cache è indipendente dalla richiesta, quindi gli acquirenti normali non attivano una chiamata Facebook API a ogni page view. Se il file cache manca, è vuoto, contiene JSON non valido o è più vecchio della durata configurata, il trait feed condiviso lo tratta come scaduto e recupera di nuovo. Salvare configurazioni legate al feed svuota anche la cache feed, impedendo che cambi layout o count si mescolino con vecchi dati post.

Per store trafficati, questa è la protezione principale contro page load lenti e pressione API evitabile. Per lanci campagna, usa l'azione admin refresh dopo aver pubblicato su Facebook se vuoi che il blocco storefront raccolga subito il nuovo contenuto invece di aspettare la prossima scadenza cache.

Sì, può pubblicare post blog su Facebook, ma il workflow autopublish è costruito intorno ai post MPR Blog Revolution, non a ogni possibile modulo blog terzo. Il modulo Facebook usa il trait social publisher condiviso, ascolta gli hook PrestaShop object add e update, controlla che auto-publish sia abilitato, controlla un oggetto stile Blog Revolution o Post, e continua solo quando l'oggetto ha status = 1.

La prevenzione duplicati è salvata nella tabella mpr_social_publish. Prima dell'invio, il modulo controlla se mprfacebookpostsintegration ha già pubblicato object type blog_post con quell'ID post sulla piattaforma facebook. Gli invii riusciti sono registrati con platform post ID, platform URL, caption, media URLs e status published, così hook add o update successivi saltano lo stesso post invece di inviarlo di nuovo.

Le caption vengono dal template auto-publish del modulo Facebook. I placeholder supportati sono {title}, {excerpt}, {url} e {shop_name}. Se il post blog ha un'immagine in evidenza, il publisher costruisce il suo media URL da img/mprblogrevolution/posts/. Se mancano credenziali Facebook, il publisher non è configurato o una condizione piattaforma richiesta non è soddisfatta, il percorso auto-publish ritorna senza postare.

Il publisher specifico Facebook è configurato solo quando esistono entrambi PAGE_ID e ACCESS_TOKEN. Usa Facebook Graph API v21.0, supporta post testo, link post e photo/image post nel percorso publish() implementato, consente un elemento media per invio e ha limite caratteri 63206. Un image post media-only viene inviato tramite endpoint page photos, mentre link o text post usano endpoint page feed.

Anche se getSupportedMediaTypes() attualmente elenca video, il publisher implementato non carica video né chiama un endpoint videos. Tratta la pubblicazione video come non supportata salvo venga aggiunto un vero percorso video publishing.

MPRFB_AUTOPUBLISH=1
MPRFB_AUTOPUBLISH_CAPTION={title}
{excerpt}
Read more: {url}

Il modulo salta anche il proprio percorso publisher quando il takeover più ampio mprsocialrevolution è attivo per Facebook, così due moduli social non cercano di pubblicare lo stesso post blog nello stesso momento.

Il modulo aggiunge pagine dedicate di galleria, categoria, progetto, invio e un'area cliente „i miei progetti“, ciascuna con il proprio URL ottimizzato per il SEO. I progetti approvati in evidenza possono inoltre essere mostrati in aree selezionate del negozio.

Tutti i testi della galleria, categorie, progetti e commenti, sono memorizzati per lingua, quindi la galleria è completamente multilingua. Il modulo funziona su PrestaShop dalla 1.6.1 alla 9.x.

Sì, ogni profilo feed può avere lingua, valuta, paesi target e label propri. È utile quando uno store vende in diversi mercati con wording catalogo o struttura advertising diversi. Una separazione chiara dei feed aiuta anche i manager a capire quale mercato produce ricavi e quale richiede attenzione.

Nel modello feed, ogni profilo salva id_lang, id_currency, id_shop, target_country, feed_label, content_language e sync_mode. Un nuovo feed usa default francesi nel sorgente attuale: target_country=FR, feed_label=FR e content_language=fr.

target_country=AE,AU,GB,US
feed_label=GB
content_language=en
sync_mode=file_only or api

• target_country è normalizzato in maiuscolo e può essere un codice paese a due lettere o una lista separata da virgole.
• feed_label è normalizzato in maiuscolo e deve rispettare la forma label di Google Merchant API: lettere maiuscole, numeri e trattini, fino a 20 caratteri.
• content_language è normalizzato in minuscolo e deve essere un codice lingua a due lettere per API product input.
• Per API sync, profili feed separati sono di solito più puliti quando ogni mercato richiede label, valuta o lingua distinta.

Il front feed controller serve un feed specifico per ID o nome file con token, usa TTL cache predefinito 3600 secondi e può rigenerare con generate=1. Questo permette a uno shop PrestaShop di mantenere feed Merchant separati senza mescolare paesi, lingue o label campagna.

No, la descrizione sorgente dice che i valori numerici interni di PrestaShop restano intatti sotto. Il modulo personalizza i numeri mostrati su fatture, delivery slips e credit notes. Se hai bisogno di personalizzare i riferimenti ordine stessi, il sorgente raccomanda di usare il prodotto separato Custom Order Numbering.

Il modulo fattura conferma questa divisione nel codice: hookActionSetInvoice genera e logga il riferimento fattura formattato, ma lascia intenzionalmente numerico/nativo il numero fattura salvato da PrestaShop. La stringa formattata visualizzata viene fornita più tardi tramite actionInvoiceNumberFormatted, e la generazione delivery note salva il valore contatore numerico in order_invoice.delivery_number.

Default invoice format: {DOC_TYPE}/{YYYY}/{NNNNNN}
Default delivery format: {DOC_TYPE}/{YYYY}/{NNNN}
Default credit slip format: {DOC_TYPE}/{YYYY}/{NNNN}

I valori generati sono registrati in mprinvoicenumber_number con tipo documento, ID ordine, fattura o slip, valore contatore, pattern e numero formattato. Questo ti dà documenti customer-facing personalizzati senza cambiare order IDs o riferimenti ordine random; quelli sono gestiti da mprordernumber.

Il modulo genera un indicatore tramite displayProductListReviews. Il suo JavaScript trova la miniatura prodotto circostante e inietta un badge Bundle nell'area immagine.

Il tab elenca in una griglia i prodotti inclusi configurati. Ogni card può mostrare immagine prodotto, nome prodotto, prezzo formattato oppure FREE per prezzo zero, e un link al prodotto incluso.

Include un helper dispatcher per route rewrite-only. Quando una route non ha un ID, può risolvere slug corrispondenti di categoria, prodotto, CMS o produttore e aggiornare di conseguenza i parametri della request.

Sì. Il form admin salva il flag enabled, e ogni hook front termina subito quando isFeatureEnabled() è false.

Il percorso server-side richiede CAPI attivo e un Reddit access token configurato. L'Events Testing ID è opzionale e viene usato solo quando presente.

No, la fonte descrive eventi browser ed eventi lato server che lavorano in parallelo con ID di conversione condivisi. Il percorso lato server può aiutare a ridurre le lacune quando il tracciamento nel browser viene bloccato, mentre il pixel browser continua a rilevare il comportamento lato client. Usarli entrambi con attenzione fornisce a Reddit segnali più completi rispetto al solo pixel incollato.

Il tracciamento browser viene preparato negli hook header e conferma ordine. Il modulo può emettere eventi come PageVisit, ViewContent, Search, SignUp, InitiateCheckout, eventi bridge in stile add-to-cart e Purchase. Quando la Conversions API è abilitata, gli eventi corrispondenti vengono messi in coda lato server con la stessa identità: i parametri browser usano conversionId, mentre il payload API salva conversion_id nei metadati dell'evento.

• Per il tracciamento browser è richiesto un Reddit Pixel ID.
• Conversions API richiede anche un access token, e il modulo invia all'endpoint conversioni di Reddit per il pixel configurato.
• L'esclusione dei dipendenti e i controlli sul consenso marketing passano da canTrack() prima che il tracciamento front office venga preparato.
• Il limite batch predefinito della coda CAPI è 20, mentre i percorsi front bridge e purchase elaborano subito piccoli batch.

La configurazione pratica consiste nel mantenere attivo il pixel browser per i normali eventi lato client e usare la Conversions API come segnale lato server complementare, non come sostituto.

Il modulo mappa direttamente la maggior parte delle azioni standard, mentre InitiateCheckout viene inviato come evento personalizzato Reddit chiamato InitiateCheckout nel mapping server-side.

Sì. La configurazione include l'esclusione dipendenti e il gate di tracking la controlla prima di costruire l'output pixel front o consentire eventi tramite il percorso tracking del modulo.

L'elenco degli hook disponibili include displayHome, displayFooterCategory, displayLeftColumn, displayRightColumn, displayFooterBefore, displayFooterProduct, displayProductAdditionalInfo, displayOrderConfirmation2 e displayCrossSellingShoppingCart.

Sì, la descrizione della fonte include sia collezioni di prodotti curate sia widget dinamici. Le collezioni selezionate a mano sono utili per campagne, merchandising editoriale e promozioni orientate al margine. Le fonti dinamiche sono utili quando vuoi che bestseller, nuovi arrivi o prodotti tornati disponibili restino aggiornati con meno lavoro manuale.

Le collezioni curate sono salvate separatamente dai widget. La tabella collection-product salva id_collection, id_product e position, e setProducts() riscrive quell'elenco nell'ordine salvato dall'admin. Un widget può quindi usare il tipo widget collection e puntare alla collezione scelta.

• I tipi di collezione includono curated, staff_picks, seasonal e spotlight.
• Le query pubbliche delle collezioni restituiscono prodotti attivi del negozio e mantengono l'ordine collezione-prodotto salvato.
• Se il widget richiede immagini, il provider filtra i prodotti senza un'immagine utilizzabile.
• I tipi di widget automatici con provider prodotto implementati includono bestsellers, new, sale, featured, trending, back_in_stock e cart_recommendations.
• recently_viewed è indicato come tipo/etichetta di widget nel model, ma getProducts() non ha ancora un case provider per questo tipo, quindi non dovrebbe essere presentato come lista automatica funzionante finché tale implementazione non viene aggiunta.

Questo significa che puoi scegliere manualmente una collezione di campagna per la homepage o per un blocco nella pagina prodotto, continuando a usare blocchi dinamici implementati in altre aree dello stesso negozio PrestaShop.

Sì. Il modello del widget salva hide_products_without_images e le query prodotto/l'assemblaggio del provider usano questo flag per richiedere un'immagine di copertina shop per molte fonti widget.

Il modulo ascolta actionUpdateQuantity. Quando la quantità di un prodotto passa da zero o meno a un valore positivo, inserisce una riga in mprshowcaserevolution_stock_change, che la fonte prodotti tornati disponibili può usare.

Installa e abilita il modulo per aggiungere un pulsante Ask a question nelle pagine prodotto di PrestaShop. Viene renderizzato tramite l'hook displayProductAdditionalInfo, apre un form modale accanto alle informazioni del prodotto e passa nome prodotto, riferimento e ID prodotto nella richiesta.

All'installazione, il modulo salva ENABLED=1, imposta RECIPIENT_EMAIL da PS_SHOP_EMAIL e usa [Product Question] come prefisso oggetto predefinito. L'hook assegna al template Smarty il nome prodotto, il riferimento prodotto, l'ID prodotto, l'URL AJAX e un valore token nascosto.

• Hook front: displayProductAdditionalInfo.
• Endpoint AJAX: module/mpraskaboutproduct/ask.
• Impostazioni admin: interruttore di abilitazione, email destinatario e prefisso oggetto.

Il risultato è un form di richiesta specifico per il prodotto nella pagina prodotto, così il merchant riceve il messaggio con il contesto del prodotto invece di una richiesta di contatto generica.

Sì, i clienti inviano la richiesta sul prodotto direttamente dalla modale del front office. Il front controller PrestaShop riceve nome mittente, email mittente, messaggio, nome prodotto e ID prodotto tramite AJAX, poi restituisce un messaggio JSON di successo o errore senza far aprire al cliente un client email.

Il template invia una richiesta FormData al front controller del modulo e aggiorna la modale con la risposta JSON. In caso di successo, il form viene azzerato e il cliente vede il messaggio di conferma; in caso di errore di validazione o di invio email, la stessa modale mostra l'errore restituito.

• La richiesta è considerata non valida se manca il marker di invio previsto sender_email.
• Il controller invia al destinatario configurato nel modulo, oppure ripiega sull'email del negozio.
• Se il template email question del modulo esiste, viene usato; altrimenti il codice ripiega sul template core PrestaShop contact.

Questo mantiene la richiesta dentro il flusso del front office PrestaShop e conserva nome prodotto e ID prodotto nel corpo dell'email.

Valida la richiesta nel front controller AJAX prima di inviare l'email. Una richiesta deve inviare sender_email, e i campi obbligatori sono sender_name, sender_email e message. L'email viene controllata con Validate::isEmail(), e il messaggio con Validate::isCleanHtml().

POST /module/mpraskaboutproduct/ask sender_name=Alice&sender_email=alice@example.com&message=Can you confirm availability?&id_product=42&product_name=Demo product

• Se manca il marker di invio sender_email, restituisce {"success":false,"message":"Invalid request."}.
• Nome, email o messaggio vuoti restituiscono {"success":false,"message":"All fields are required."}.
• Un'email non valida restituisce {"success":false,"message":"Invalid email address."}.
• HTML non sicuro nel messaggio restituisce {"success":false,"message":"Invalid message content."}.

Se la validazione passa, il modulo invia la richiesta all'email destinatario configurata, ripiegando sull'email del negozio quando non è impostato alcun destinatario del modulo.

Dopo la validazione, il controller costruisce l'oggetto email dal prefisso oggetto configurato più il nome prodotto inviato. Il messaggio viene escapato e convertito con nl2br() per il template email. Nome prodotto e ID prodotto sono inclusi nelle variabili email, così lo staff può identificare l'articolo senza chiedere al cliente di reinviare i dettagli.

La modale include un campo token nascosto, ma il percorso attuale del controller valida i campi della richiesta e il contenuto del messaggio invece di controllare quel token. Se serve una protezione anti-spam più forte, aggiungila attorno al form front office invece di presumere che questo controller esegua un controllo CSRF-token.

Sì, il modulo ti permette di impostare email destinatario e prefisso oggetto per le domande sui prodotti. Se non è configurato alcun destinatario, il front controller PrestaShop ripiega sull'indirizzo email del negozio, poi invia il messaggio includendo il contesto del prodotto.

La classe di configurazione espone RECIPIENT_EMAIL e SUBJECT_PREFIX. Durante l'installazione, RECIPIENT_EMAIL viene inizializzato da PS_SHOP_EMAIL, e SUBJECT_PREFIX ha come predefinito [Product Question]. Nel front controller, un destinatario vuoto viene sostituito con Configuration::get('PS_SHOP_EMAIL').

Recipient: mpraskaboutproduct.RECIPIENT_EMAIL or PS_SHOP_EMAIL
Subject: SUBJECT_PREFIX + product name

È utile quando le domande sui prodotti devono arrivare a una casella vendite, a un team tecnico o al desk di un fornitore invece che all'indirizzo principale di contatto PrestaShop.

Sì. Le recensioni vengono controllate prima di essere salvate, e i controlli falliti restituiscono un errore di validazione invece di accettare la recensione in modo silenzioso. La fonte include queste protezioni:

• Limite per stesso IP: quando MIN_TIME_BETWEEN è maggiore di zero, il modulo controlla se lo stesso IP ha pubblicato un'altra recensione in quel negozio entro il numero di secondi configurato.
• reCAPTCHA: quando abilitato, il modulo verifica il token inviato con Google. Supporta v2 e v3; v3 usa una soglia punteggio di 0.5. Un token mancante fa fallire il controllo, mentre una secret key mancante o un problema di verifica di rete viene trattato come non bloccante.
• Controlli link e tag: il contenuto con più di due URL viene rifiutato, e HTML incorporato evidente come <script>, <iframe>, <object>, <embed> e <form> viene bloccato.

La protezione sul tempo minimo è un controllo del tempo tra recensioni per lo stesso IP, non un timer di caricamento del form. Per usare reCAPTCHA come protezione attiva, abilitalo e configura site key e secret key nelle impostazioni del modulo.

Il flusso di invio più ampio aggiunge altre protezioni pratiche. Le recensioni richiedono tipo entità valido, ID entità, contenuto di almeno 10 caratteri e una valutazione da 1 a 5. Le recensioni degli ospiti sono disabilitate per impostazione predefinita, e ai clienti loggati viene impedito di recensire due volte la stessa entità, a meno che la recensione precedente sia stata marcata come spam.

• MODERATION ha come predefinito 1, quindi le nuove recensioni vengono salvate come pending salvo disabilitazione della moderazione.
• MIN_TIME_BETWEEN ha come predefinito 30 secondi.
• Per le recensioni prodotto di clienti loggati, il modulo può marcare una recensione come acquisto verificato quando trova un ordine valido che contiene quel prodotto.
• I caricamenti foto, quando abilitati, sono limitati a JPEG, PNG e WebP, con limiti predefiniti di 3 immagini e 2 MB per immagine.

Non è comunque un sistema di rilevamento frodi. Il codice fornisce rate limiting, reCAPTCHA, controlli contenuto, prevenzione duplicati, marcatura acquisto verificato e moderazione, quindi i merchant dovrebbero mantenere la moderazione abilitata quando la qualità delle recensioni è importante.

Sì, le recensioni non sono limitate alle pagine prodotto. Il modulo include gestione entità per recensioni prodotto, categoria, CMS e negozio, oltre a una route pubblica per le recensioni, con ogni area di visualizzazione controllata dalla configurazione e renderizzata tramite hook o controller front office PrestaShop.

Il data model salva le recensioni con entity_type e entity_id, e il servizio di invio accetta product, category, cms e store come tipi entità validi. La pagina impostazioni ha interruttori separati per PRODUCT_REVIEWS, CATEGORY_REVIEWS, CMS_REVIEWS e STORE_REVIEWS; nei default attuali sono abilitate solo le recensioni prodotto.

L'integrazione automatica nella pagina prodotto è il percorso più completo nel codice ispezionato: le recensioni prodotto vengono renderizzate tramite displayProductExtraContent, le stelle nelle liste tramite displayProductListReviews e il badge valutazione prodotto tramite hook della pagina prodotto. La pagina pubblica recensioni è esposta come /reviews e può filtrare le recensioni approvate per type=product, category, cms o store.

Allowed entity types: product, category, cms, store
Public route: /reviews
Filtered examples: /reviews?type=category or /reviews?type=store

Per il posizionamento su categoria, CMS e negozio, pianifica con attenzione la collocazione nel front office. La fonte supporta quei record recensione e l'hub recensioni, ma le pagine prodotto hanno la copertura hook integrata più forte nei file ispezionati.

Sì, i promemoria possono essere creati dopo che un ordine raggiunge lo stato consegnato configurato. L'hook stato ordine PrestaShop pianifica i promemoria solo quando la funzione promemoria è abilitata, e il modulo salva righe promemoria con dati di ordine, cliente, ritardo e stato recensione.

Più precisamente, l'hook ispezionato ascolta actionOrderStatusPostUpdate e controlla se il nuovo stato ordine PrestaShop ha il flag delivery impostato. Quando REMINDERS_ENABLED è attivo, carica i prodotti dell'ordine e crea una riga promemoria per prodotto tramite ReviewReminder::createForOrder().

• REMINDERS_ENABLED ha come predefinito 0.
• REMINDER_DELAY_DAYS ha come predefinito 7.
• Le righe duplicate per lo stesso ordine e prodotto vengono saltate.
• I prodotti già recensiti da quel cliente vengono saltati.
• Ogni riga promemoria salva un token di 64 caratteri e uno stato come pending, sent o reviewed.

Il model include anche helper per trovare promemoria pendenti dopo il ritardo configurato, marcarli come inviati, marcarli come recensiti e caricare un promemoria tramite token. Nei file ispezionati ho trovato pianificazione e data model, ma non un flusso cron completo di invio email che chiami quei metodi helper.

Sì, il modulo include gestori di recensioni esterne per Google Business Profile e Trustpilot. Quando le credenziali API richieste sono configurate, le recensioni esterne possono essere sincronizzate in tabelle locali per recensioni esterne e poi visualizzate o aggregate secondo le impostazioni del modulo PrestaShop.

La tabella delle recensioni esterne salva fonte, ID recensione della fonte, autore, titolo, contenuto, valutazione, URL fonte, data di pubblicazione, lingua, ID prodotto opzionale, ID negozio, dati API grezzi e timestamp di sincronizzazione. Una chiave unica su source più source_review_id evita import duplicati quando la stessa recensione viene recuperata di nuovo.

• La sincronizzazione Trustpilot richiede EXT_TRUSTPILOT_ENABLED, una API key e Business Unit ID. Il provider ha anche un fallback di import CSV per export Trustpilot.
• La sincronizzazione Google Business Profile richiede EXT_GOOGLE_ENABLED, JSON del service account contenente client_email e private_key, più Account ID e Location ID.
• Il cron controller gira su /module/mprcomments/cron?token=EXT_CRON_TOKEN&action=sync e restituisce risultati di sincronizzazione per fonte come JSON.
• Le recensioni aziendali esterne possono essere mostrate sulle pagine prodotto, caricate lazy per impostazione predefinita e, opzionalmente, conteggiate nei badge valutazione prodotto quando l'aggregazione esterna è abilitata.

Per sicurezza SEO, il renderer schema usa le recensioni prodotto native per i dati strutturati Product. Le recensioni aziendali importate possono essere mostrate agli acquirenti, ma i commenti della fonte le tengono esplicitamente fuori dal markup recensioni prodotto, salvo che il merchant abbia recensioni prodotto native.

No, i progetti inviati non vengono pubblicati automaticamente per impostazione predefinita. In PrestaShop l'impostazione auto_approve ha come predefinito 0, quindi i nuovi progetti vengono salvati come pending e le query della galleria pubblica usano lo stato progetto approved prima di mostrarli.

Il controller di invio è autenticato come cliente e richiede un token di sicurezza valido prima di creare un progetto. Valida il titolo del progetto, richiede almeno un'immagine caricata e applica il limite configurato sul numero di immagini prima di salvare il progetto. Le impostazioni immagine predefinite sono max_images=20 e max_image_size_mb=5.

Default: auto_approve=0
Submitted project status: pending
Public gallery status filter: approved

• Se auto_approve resta disattivato, il cliente viene reindirizzato a My Projects dopo l'invio e il progetto attende moderazione.
• Se auto_approve è abilitato, lo stesso flusso di invio salva il nuovo progetto con stato approved.
• La lista admin dei progetti supporta azioni massive di approvazione, rifiuto, evidenziazione ed eliminazione.
• Il controller progetto pubblico restituisce un 404 per progetti non approvati, salvo presenza di una sessione preview admin valida.

Per la maggior parte dei negozi, lasciare l'approvazione automatica disattivata è l'impostazione più sicura, perché titoli, descrizioni e foto inviati dai clienti vengono revisionati prima di apparire nella vetrina pubblica.

Sì, gli admin possono aggiungere pin prodotto alle immagini showcase. In PrestaShop ogni pin salva coordinate immagine x e y, un'etichetta e ID prodotto fallback ordinati, poi risolve un prodotto attivo e disponibile per la visualizzazione pubblica del progetto.

Il controller admin dei pin aggiunge, aggiorna, elimina e carica pin tramite JSON AJAX. Le coordinate devono essere tra 0 e 100 e sono arrotondate a due decimali. Gli ID prodotto fallback vengono normalizzati, deduplicati e salvati come JSON, con il primo ID scritto anche nel campo legacy id_product.

Pin fields: id_showcase_image, id_product, product_fallback_ids, x_percent, y_percent, label, position
Resolution order: first active in-stock product, then first active product

• La ricerca prodotti admin restituisce prodotti attivi per nome, riferimento o ID prodotto, limitata a 20 risultati.
• Nella pagina progetto pubblica, i pin vengono arricchiti con URL prodotto, immagine di copertina e prezzo formattato.
• L'endpoint AJAX front dei pin può anche renderizzare il template product miniature del tema quando disponibile.
• Se tutti i prodotti fallback sono inattivi, il pin resta posizionato ma non risolve alcun prodotto.

Questo permette al merchant di trasformare un'immagine della galleria cliente in un lookbook acquistabile mantenendo una lista fallback per prodotti esauriti o disattivati.

Sì, i voti duplicati dello stesso cliente sullo stesso progetto sono impediti. In PrestaShop la tabella voti ha una chiave unica progetto-cliente e il modello aggiorna il voto esistente invece di inserire una nuova riga.

Sì. Una pagina progetto Customer Showcase non in preview può emettere JSON-LD quando il controller progetto ha dati sufficienti per costruirlo. Il controller raccoglie titolo progetto, meta description risolta della pagina, URL canonico del progetto, URL grandi delle immagini showcase e nome categoria, poi il template front stampa il JSON in uno script application/ld+json quando project_schema_json non è vuoto.

{"@context":"https://schema.org","@type":"ImageGallery","name":"Bathroom renovation","description":"Short project summary","url":"https://shop.example/showcase/bathroom-renovation","mainEntityOfPage":"https://shop.example/showcase/bathroom-renovation","image":["https://shop.example/img/showcase/large/photo.jpg"],"about":"Bathrooms"}

Il tipo schema usato dal modulo è ImageGallery, quindi descrive la galleria del progetto cliente invece di dichiarare uno schema prodotto, servizio o recensione separato.

Il controller salta intenzionalmente lo schema in modalità preview: le pagine preview ricevono un valore project_schema_json vuoto e l'helper preview applica gestione noindex. Sulle pagine progetto normali, gli URL delle immagini grandi sono costruiti da img/showcase/large/ usando il dominio SSL del negozio e la base URI, quindi i dati strutturati puntano a URL immagine assoluti invece che ai file thumbnail o medium usati altrove nella pagina.

• Fonte della descrizione: il JSON-LD usa la meta description risolta della pagina. Questa è la meta description progetto salvata quando esiste; altrimenti il controller genera una descrizione customer-showcase basata sul titolo. La descrizione progetto ripulita e troncata è solo un fallback finale dentro buildProjectSchema() se la meta description risolta è ancora vuota.
• Campi opzionali: image è incluso solo quando esistono immagini progetto, e about solo quando il progetto ha un nome categoria.
• Sicurezza output: il JSON è generato con json_encode(..., JSON_UNESCAPED_SLASHES | JSON_UNESCAPED_UNICODE) e ripiega su Tools::jsonEncode() se necessario, poi Smarty stampa quel JSON preparato senza filtri dentro lo script JSON-LD.

No. Il modulo implementa solo il codice Google Customer Reviews lato PrestaShop; non contiene codice che possa iscrivere, approvare o rendere un negozio idoneo in Google Merchant Center. Devi avere il programma Google Customer Reviews disponibile per il negozio in Merchant Center, un Merchant ID numerico e dati ordine che Google accetti per l'opt-in al sondaggio.

Quello che il modulo può controllare è l'implementazione storefront dopo che questi prerequisiti esistono: salva il Merchant ID, carica l'opt-in al sondaggio Google nella pagina di conferma ordine, invia ID ordine, email cliente, paese di consegna, data di consegna stimata e valori GTIN dei prodotti dall'ordine, e renderizza il badge valutazione nella posizione configurata.

Consegna del sondaggio, approvazione del programma, calcolo seller-rating e modalità di visualizzazione delle valutazioni nelle proprietà Google restano sotto il controllo di Google. Il modulo può far apparire il codice opt-in e badge, ma non può approvare il negozio o forzare Google a mostrare le valutazioni.

All'installazione il modulo parte disabilitato con MERCHANT_ID vuoto, posizione badge predefinita BOTTOM_RIGHT e lingua badge en. Il guard storefront richiede sia ENABLED sia un Merchant ID non vuoto, quindi un modulo installato ma non configurato non emetterà il codice opt-in o badge.

• Opt-in su conferma ordine: l'hook gira solo per un ordine caricato, usa l'email cliente dell'ordine, legge il paese di consegna dall'indirizzo di consegna, usa una data di consegna stimata semplice pari a oggi più sette giorni e passa ean13 di ogni prodotto ordinato come valore GTIN.
• Badge: l'hook di chiusura body renderizza il badge valutazione Google con il merchant ID configurato e una delle posizioni supportate, come BOTTOM_RIGHT, BOTTOM_LEFT o INLINE.
• Limite: se i prodotti non hanno valore EAN13, il modulo invia comunque la voce prodotto con GTIN vuoto; se Google accetta o usa quei dati prodotto viene gestito fuori da PrestaShop.

Non automaticamente. Il modulo fornisce anteprima e storico, ma la fonte non contiene un rollback con un clic che ripristini ogni prodotto al prezzo precedente. Prima di applicare un aggiornamento massivo, usa l'anteprima per controllare ID prodotto interessati, prezzo attuale, nuovo prezzo calcolato e differenza.

• Prima di applicare: esporta o fai backup degli ID prodotto interessati e del campo prezzo che stai modificando, soprattutto se aggiorni un ambito ampio come tutti i prodotti, una categoria o un produttore.
• Dopo l'applicazione: il modulo scrive una voce di log con formula, ambito, campo prezzo, numero di elementi interessati, dipendente e data.
• Se devi annullare: usa il log per identificare l'esecuzione, poi ripristina dal tuo backup/export. Applicare la formula inversa può essere rischioso perché arrotondamenti, modifiche prezzo successive e cambiamenti nell'ambito prodotto possono rendere il calcolo inverso diverso dai valori originali.

Per modifiche ad alto rischio, esegui l'anteprima, esporta lo stesso set di prodotti e applica l'aggiornamento in un periodo tranquillo, così eventuali correzioni possono essere fatte da valori sorgente noti.

L'anteprima e l'aggiornamento reale usano lo stesso helper di calcolo, quindi i numeri che vedi in anteprima si basano sulle stesse azioni formula che saranno poi applicate: increase_percent, decrease_percent, increase_fixed e decrease_fixed. Le diminuzioni percentuali e fisse sono limitate a zero, e i prezzi calcolati vengono arrotondati a sei decimali prima della scrittura.

increase_percent:10 => current price * 1.10; decrease_fixed:5 => max(0, current price - 5)

Quando applicato, il modulo aggiorna sia product sia product_shop per il campo selezionato, e supporta solo price o wholesale_price. Il selettore ambito può puntare a tutti i prodotti attivi o ai prodotti attivi in una categoria, produttore o fornitore selezionato; i prodotti inattivi non vengono selezionati dalle query ambito.

L'hook consente URL che contengono module/mprpasswordprotect o module-mprpasswordprotect, e ritorna anche quando il parametro module della request è uguale al nome del modulo.

La classe config espone abilita protezione password, password, messaggio, bypass dipendente/maintenance e switch noindex tramite il form OptionsManager.

Sì. L'installazione crea una pagina meta non configurabile per module-mprpasswordprotect-gate con titolo Password Required e URL rewrite password.

Il controller gate imposta un flag errore e renderizza di nuovo lo stesso template password, che mostra il messaggio tradotto Incorrect password. Please try again..

No. Il controller di reinvio invia l'email di conferma ordine ricostruita e registra un messaggio privato, ma non chiama alcuna logica di cambio stato ordine.

Prima dell'invio, il controller AJAX richiede un ID ordine e un token modulo, li valida entrambi, carica ordine e cliente, poi chiama lo standard Mail::Send() di PrestaShop con il template order_conf da _PS_MAIL_DIR_ e l'ID negozio originale dell'ordine.

• Prodotti: ricostruisce righe prodotto sia HTML sia testo semplice da $order->getProducts(), includendo nome prodotto, riferimento opzionale, quantità, prezzo unitario IVA inclusa e prezzo totale IVA inclusa.
• Indirizzi: i blocchi consegna e fatturazione vengono generati con AddressFormat::generateAddress(), con fallback assemblato da azienda, nome, via, CAP e città se la formattazione indirizzo fallisce.
• Audit trail: dopo un reinvio riuscito aggiunge un messaggio ordine privato e scrive una voce di log PrestaShop; se l'invio email fallisce, restituisce un errore JSON invece di cambiare lo stato ordine.

Il modulo invia il template standard PrestaShop order_conf tramite Mail::Send, dopo aver ricostruito righe prodotto, indirizzi, totali, corriere e valori pagamento dall'ordine.

Dopo un invio riuscito, il modulo crea un messaggio ordine privato che indica che la conferma è stata reinviata, includendo email destinatario e timestamp.

Il modulo deve essere abilitato e PHONE_NUMBER deve essere impostato. Il validatore della configurazione obbligatoria accetta solo cifre e un segno più iniziale opzionale, per esempio +1234567890.

Sì. Il trait chat condiviso supporta i filtri pagina all, product, category e checkout tramite l'impostazione PAGES.

No. Il template renderizzato crea un normale link a Signal e usa CSS locale del modulo più SVG inline per il pulsante. Nel template hook non c'è alcun loader JavaScript esterno di Signal.

Se DELAY è maggiore di zero, il template nasconde inizialmente il widget e usa un timeout per mostrarlo dopo il numero di secondi configurato.

Il modulo salva la scelta di visualizzazione del visitatore nel cookie leggero mpr_tax_display e, presto nel front controller, prepara la cache di visualizzazione prezzo gruppo di PrestaShop in modo che i calcoli prezzo prodotto renderizzino IVA inclusa o esclusa per quella richiesta. Non aggiorna carrelli, ordini, regole fiscali, fatture o gruppi clienti nel database.

Nelle pagine prodotto/listing inietta anche dati nascosti .mpr-tax-prices con prezzi IVA inclusa e IVA esclusa preformattati, così JavaScript può sostituire subito i prezzi visibili. Se una pagina non ha dati prezzo prodotto iniettati, come alcune pagine carrello o checkout, lo script salva la preferenza e ricarica la pagina affinché PrestaShop la renderizzi con la modalità di visualizzazione scelta.

Il totale checkout e l'importo IVA sono ancora calcolati da PrestaShop da carrello, indirizzo, regole fiscali e normale flusso checkout. Questo modulo influisce su preferenza di visualizzazione ed etichette prezzo, non sul calcolo fiscale.

Abilita il modulo per renderizzare un pulsante fisso torna su nel front office PrestaShop. Il codice emette il pulsante dagli hook footer/body-closing, evita rendering duplicati quando entrambi gli hook sono disponibili e include CSS e JavaScript necessari per il pulsante.

Dopo l'installazione i default sono abilitato, mostra dopo 300 pixel, stile circle e posizione right. Il modulo registra displayFooter, displayFooterAfter e displayBeforeBodyClosingTag; qualunque hook supportato venga renderizzato per primo dal tema emetterà il pulsante, e le chiamate hook successive restituiranno stringa vuota perché buttonRendered è già impostato.

Il template crea un singolo pulsante fisso con ID mprb2t-btn, label/title accessibile, una freccia verso l'alto SVG inline e CSS/JavaScript inline. Questo modulo non include regole per prodotto, categoria o pagina, quindi abilitarlo rende il pulsante disponibile ovunque il tema esegua uno di quegli hook footer/body-closing.

Sì, puoi impostare la distanza di scroll prima che il pulsante appaia. La configurazione PrestaShop salva un valore Show After in pixel, e il JavaScript del front office confronta quella soglia con window.pageYOffset prima di aggiungere o rimuovere la classe pulsante visibile.

La soglia predefinita è 300 pixel, e il campo admin viene salvato come SHOW_AFTER. Il valore viene assegnato a Smarty come mprb2t_show_after e diventa la variabile JavaScript threshold nel template.

if (window.pageYOffset > threshold) { btn.classList.add('mprb2t-visible'); } else { btn.classList.remove('mprb2t-visible'); }

Il listener di scroll è registrato come passive e toggleBtn() viene eseguito anche una volta subito dopo il caricamento dello script, quindi lo stato del pulsante è corretto anche quando un acquirente arriva su una pagina con anchor o torna a una posizione già scrollata.

Sì, il modulo supporta le opzioni di stile presenti nella sua configurazione: forma cerchio o quadrato e posizione a sinistra o destra dello schermo. Il template PrestaShop applica quei valori al CSS inline; il codice non include un color picker o regole di targeting per pagina.

I default installati sono STYLE=circle e POSITION=right. Nel template, POSITION=left scrive left: 30px; qualsiasi altro valore configurato segue il ramo destro e scrive right: 30px. Per la forma, STYLE=circle scrive border-radius: 50%, mentre l'opzione quadrata usa un piccolo raggio 6px.

• Dimensioni fisse: il pulsante è 48 per 48 pixel, fisso in basso nella viewport e usa z-index: 9999.
• Colori integrati: il template usa sfondo scuro, icona bianca e stato hover più scuro. Questi valori sono hard-coded nel template attuale.
• Limite pratico: nella classe di configurazione non esiste impostazione per scelta icona, posizione per dispositivo, durata animazione o colori personalizzati.

Sì, cliccando il pulsante la pagina scorre fluidamente verso l'alto. Lo script del front office PrestaShop ascolta il click sul pulsante, impedisce l'azione predefinita e chiama window.scrollTo con top impostato a 0 e behavior impostato a smooth.

Il click handler è piccolo e diretto: è collegato al pulsante generato mprb2t-btn, chiama e.preventDefault() e poi chiede al browser di scorrere verso l'alto usando lo smooth scrolling nativo.

window.scrollTo({ top: 0, behavior: 'smooth' });

Poiché il modulo usa il comportamento nativo scrollTo del browser invece di un loop di animazione personalizzato, resta leggero e non salva alcuno stato di scroll. Il pulsante diventa visibile solo dopo il superamento della soglia configurata; cliccarlo non ricarica la pagina e non cambia l'URL.

Usa MPR Compare per aggiungere a PrestaShop una lista di confronto lato client. Gli ID prodotto selezionati vengono salvati nel localStorage del browser sotto la chiave mprcompare, mentre il modulo interroga i dettagli prodotto tramite AJAX solo quando la pagina confronto o le miniature flottanti hanno bisogno dei dati.

Il commento header del modulo descrive il design come zero archiviazione database e zero cookie per l'interazione sulle pagine listing. Gli hook product-list e product-page emettono pulsanti statici con attributo data-id-product; lo script browser aggiunge o rimuove quegli ID da localStorage e aggiorna localmente stato pulsanti, contatori e barra flottante.

Il server viene coinvolto solo quando servono dati prodotto reali. La pagina confronto legge gli ID da localStorage e li invia in POST al front controller actions con action=getProducts, mentre le miniature flottanti chiamano action=getProductImage. Svuotare la lista confronto salva semplicemente un array vuoto in localStorage.

La tabella confronto può mostrare nome prodotto, URL, immagine di copertina, prezzo attuale, vecchio prezzo, descrizione breve, riferimento, produttore, peso, stato stock, caratteristiche, condizione ed EAN13 quando quei valori esistono. Il controller AJAX salta i prodotti PrestaShop inattivi.

I dati provengono da oggetti Product caricati nella lingua e nel negozio correnti. I prezzi sono formattati da Product::getPriceStatic() con IVA abilitata; il vecchio prezzo viene restituito solo quando il prezzo senza riduzione è maggiore del prezzo attuale. Le immagini di copertina usano medium_default per la tabella confronto e cart_default per l'endpoint miniature flottanti.

• Caratteristiche: il controller chiama getFrontFeatures() e restituisce ogni coppia nome/valore caratteristica, mentre lo script front raggruppa i nomi caratteristica unici in righe di confronto.
• Disponibilità: lo stato stock viene restituito da Product::getQuantity($idProduct) > 0, quindi è un semplice indicatore disponibile/non disponibile.
• Dati mancanti: campi opzionali come produttore, riferimento, peso, EAN13 e vecchio prezzo sono vuoti o omessi nella tabella quando PrestaShop non ha un valore per essi.

Sì, la dimensione massima del confronto è configurabile. L'impostazione MAX_ITEMS ha come predefinito quattro all'installazione, lo script front rifiuta di aggiungere altri elementi una volta raggiunto il limite e l'endpoint prodotto AJAX tronca gli ID in ingresso allo stesso massimo configurato.

All'installazione, MAX_ITEMS viene creato con valore 4; il controller admin lo salva con minimo 1. Quel valore viene inviato al browser in mprCompareConfig.maxItems e assegnato anche al template della pagina confronto come maxItems.

var max = config.maxItems || 4;

L'applicazione del duplicato è anche lato client: se il prodotto è già in localStorage, la funzione di aggiunta ritorna senza aggiungerlo di nuovo. L'endpoint AJAX tronca comunque la lista ID richiesta al massimo configurato, quindi una richiesta modificata manualmente non può far caricare alla pagina confronto più prodotti del limite configurato.

Sì, aggiunge controlli di confronto tramite hook PrestaShop. Il modulo renderizza pulsanti su liste prodotto e pagine prodotto, un contatore di navigazione e una barra confronto flottante opzionale con miniature prodotto, controlli di rimozione e link alla pagina confronto.

Per PrestaShop 1.7 e versioni più nuove, il modulo registra hook media, pagina prodotto, navigazione e chiusura body; per i vecchi temi 1.6 usa gli hook legacy header, product button, nav e footer. I pulsanti nei listing prodotto sono link statici con js-mprcompare-toggle, i controlli nella pagina prodotto sono pulsanti, ed entrambi usano lo stesso valore data-id-product per il gestore lista JavaScript.

La barra flottante è controllata dall'impostazione SHOW_FLOATING, abilitata per impostazione predefinita. Quando ci sono prodotti selezionati, lo script mostra la barra, carica dati miniatura tramite AJAX se non sono già in cache, renderizza pulsanti di rimozione per i singoli prodotti e mantiene sincronizzati il contatore header e il contatore flottante con il numero di ID in localStorage.

I clienti possono inviare richieste di funzionalità dalla scheda della pagina prodotto quando il modulo e la visualizzazione prodotto sono abilitati. In PrestaShop il controller AJAX valida token, prodotto, titolo, descrizione e campi identità ospite, poi applica un rate limit agli invii per prodotto e IP.

La scheda prodotto viene aggiunta solo quando ENABLED e SHOW_ON_PRODUCT sono attivi e il modulo riesce a risolvere l'ID prodotto. La scheda parte come lista riepilogo/lazy, poi lo script front richiede la prima pagina di elementi quando la scheda diventa visibile, usando il valore configurato REQUESTS_PER_PAGE, che ha come predefinito 10.

• Sicurezza: le azioni di scrittura richiedono un token CSRF da Tools::getToken(false). JavaScript recupera un token con action=getToken se il markup iniziale della scheda non ne contiene già uno.
• Validazione: il titolo deve avere almeno 5 caratteri, la descrizione almeno 10, gli ospiti devono fornire nome ed email valida, e i clienti loggati usano automaticamente nome ed email dell'account.
• Rate limit: il controller consente al massimo 3 invii per lo stesso prodotto e indirizzo IP nel giorno precedente.
• Dati salvati: la richiesta registra prodotto, identità cliente o ospite, testo descrizione ripulito, negozio, lingua, indirizzo IP, stato, timestamp e un conteggio voti iniziale di 1.

Sì, le richieste possono richiedere login cliente e approvazione admin. In PrestaShop REQUIRE_LOGIN blocca l'invio da ospite, REQUIRE_APPROVAL salva le nuove richieste come submitted, e le liste pubbliche nascondono gli elementi submitted ai non autori finché non passano a uno stato pubblico.

I default sono adatti ai merchant: REQUIRE_LOGIN è disattivato, ma REQUIRE_APPROVAL è attivo. Con l'approvazione abilitata, il controller salva i nuovi elementi come submitted; senza approvazione, i nuovi elementi partono come under_review.

La visibilità è gestita nel model, non solo nel template. Le normali liste prodotto escludono sia elementi declined sia submitted, poi riaggiungono gli elementi submitted solo quando il viewer corrente corrisponde all'autore per ID cliente o indirizzo IP. Anche la query roadmap pubblica indicizzabile esclude submitted e declined, quindi le idee pendenti non diventano contenuto SEO pubblico.

Per l'autore, JavaScript può mostrare un avviso di attesa: Your request is pending review and only visible to you. Questo rende chiaro il flusso di approvazione senza esporre richieste non revisionate ad altri acquirenti.

Sì, il voto può essere abilitato e il voto ospite può essere consentito o bloccato. In PrestaShop l'endpoint voto attiva/disattiva un voto per richiesta, usa ID cliente o tracciamento basato su IP e restituisce un requisito di login quando il voto ospite è disabilitato.

Il voto è attivo per impostazione predefinita, mentre il voto ospite è disattivato per impostazione predefinita. Quando il voto ospite è disabilitato e il visitatore non è loggato, la risposta AJAX include require_login, e lo script front reindirizza al link di accesso quando presente.

L'archiviazione dei voti è una tabella separata mprfeaturerequest_vote. I votanti loggati sono associati tramite id_customer; gli ospiti, quando consentiti, sono associati per indirizzo IP. Chiamare di nuovo l'endpoint disattiva il voto eliminando la riga esistente, mentre un nuovo voto inserisce una riga e marca lo stato voted restituito come true.

Dopo ogni toggle, il modulo ricalcola il contatore della richiesta incrementando o decrementando vote_count con un aggiornamento database che usa GREATEST(0, ...), quindi il conteggio mostrato non può scendere sotto zero. Anche le richieste appena inviate ricevono un voto automatico dell'autore, motivo per cui il conteggio iniziale parte da 1.

Sì, l’hub principale della roadmap può essere indicizzabile quando il modulo Feature Requests è attivo, la pagina roadmap è attiva e l’impostazione INDEX_ROADMAP_PAGE consente l’indicizzazione. Le pagine di dettaglio, le pagine roadmap specifiche per prodotto e gli endpoint AJAX vengono volutamente tenuti fuori dall’indice.

• URL pulito dell’hub roadmap, per esempio /feature-requests: il tipo di pagina roadmap usa la policy SEO del modulo. Quando l’indicizzazione è attiva, robots viene risolto in index, follow.
• Hub roadmap con parametri di filtro/ordinamento supportati, per esempio /feature-requests?status=planned: il controller esegue un redirect 301 per questi (status, sort, view, search, page) verso l’hub canonico /feature-requests, così i duplicati non vengono mai indicizzati. Qualsiasi altra query string non reindirizzata viene renderizzata come noindex, follow.
• Pagina specifica per prodotto, per esempio /feature-requests/module/my-product: il tipo di pagina module è configurato come non indicizzabile, quindi robots viene risolto in noindex, follow.
• Pagina dettaglio richiesta, per esempio /feature-requests/some-request: il tipo di pagina detail è configurato come non indicizzabile, quindi robots viene risolto in noindex, follow. Le risposte 404 delle pagine di dettaglio inviano inoltre X-Robots-Tag: noindex, nofollow, noarchive.
• Endpoint AJAX, per esempio module/mprfeaturerequest/ajax: il controller invia X-Robots-Tag: noindex, nofollow, noarchive.

L’hook della sitemap segue la stessa logica: aggiunge l’URL dell’hub roadmap solo quando il modulo, la visualizzazione della roadmap, l’inclusione nella sitemap e la policy SEO lo consentono tutti.

Il percorso codice è limitato al rendering del widget JivoChat da displayBeforeBodyClosingTag. Controlla che il modulo sia abilitato, che esista un WIDGET_ID, che la pagina corrente corrisponda al filtro pagina configurato e che la visualizzazione mobile sia consentita quando il visitatore è su mobile.

Quando renderizza, il template inietta lo script esterno JivoChat da //code.jivosite.com/widget/{widget_id}, opzionalmente dopo il ritardo configurato. Se PASS_USER_DATA è abilitato e il cliente è loggato, definisce jivo_onLoadCallback() e chiama jivo_api.setContactInfo() con nome ed email del cliente.

In questa fonte non c'è tabella, model o controller del modulo per messaggi o trascrizioni chat. Rimuovere o disabilitare il modulo PrestaShop interrompe l'incorporamento del widget, ma non esporta, elimina o gestisce lo storico conversazioni conservato da JivoChat.

hookPaymentOptions() mostra Pay by Invoice solo quando ogni controllo di idoneità passa. Il modulo deve essere attivo, l'impostazione del modulo deve essere abilitata, il carrello deve appartenere a un cliente loggato e l'oggetto cliente deve caricarsi correttamente.

• Controllo cliente: carrelli ospite e record cliente non validi non restituiscono alcuna opzione di pagamento.
• Controllo gruppo: il cliente deve appartenere ad almeno un gruppo assegnato a un termine di pagamento attivo.
• Controllo termine: vengono restituiti solo termini attivi collegati tramite mpr_payment_term_group, ordinati per posizione e giorni.
• Controllo credito: il modulo prende il limite credito più alto dai gruppi del cliente; 0 significa illimitato. Altrimenti ordini differiti non pagati più totale carrello corrente devono restare entro il limite.
• Controllo validazione: il front validation controller ripete il controllo termine e credito prima di creare l'ordine, quindi un'opzione checkout obsoleta non può aggirare le regole.

Se un controllo fallisce, il modulo restituisce una lista opzioni pagamento vuota e PrestaShop semplicemente non offre Pay by Invoice per quel carrello.

I termini disponibili sono calcolati dai gruppi cliente sul carrello corrente. Il servizio interroga i termini attivi collegati tramite mpr_payment_term_group, usa la lingua corrente per nome e descrizione del termine e ordina il risultato per position e poi days. I termini predefiniti creati all'installazione includono Due on Receipt più Net 15, Net 30, Net 60 e Net 90.

Il template checkout renderizza poi ogni termine disponibile come opzione radio, con il primo termine selezionato, il suo badge colore, testo giorni scadenza e descrizione opzionale. Se il limite credito non è illimitato, mostra anche credito disponibile e importo differito in sospeso prima della lista termini.

Quando il cliente invia l'opzione di pagamento, il validation controller legge il mpr_pt_term_id selezionato, ricalcola il totale carrello, richiama canPlaceDeferredOrder(), crea l'ordine PrestaShop nello stato configurato OS_AWAITING, con fallback a bankwire se mancante, e poi crea un record mpr_deferred_order con importo, cliente, negozio e data scadenza basata sui giorni del termine selezionato.

La data di scadenza viene calcolata aggiungendo il numero di giorni del termine selezionato alla data in cui viene creato l'ordine differito. I termini installati di default includono Due on Receipt / Net 0, Net 15, Net 30, Net 60 e Net 90.

• Se l'ordine viene creato il 2026-06-17 con Net 0, la data di scadenza è 2026-06-17.
• Se l'ordine viene creato il 2026-06-17 con Net 15, la data di scadenza è 2026-07-02.
• Se l'ordine viene creato il 2026-06-17 con Net 30, la data di scadenza è 2026-07-17.

Il modulo salva il risultato come data in formato Y-m-d, non come timestamp con ora del giorno. Il calcolo usa la data runtime corrente del server/negozio PHP quando viene creato l'ordine differito, quindi gli ordini effettuati vicino a mezzanotte seguono il confine data lato server invece dell'orologio locale del cliente. I cambi di ora legale non aggiungono un'ora alla data di scadenza salvata, ma possono contare indirettamente se l'ordine viene creato vicino a un cambio data.

Al checkout il cliente seleziona un termine di pagamento tramite mpr_pt_term_id. Il modulo valida che il termine sia attivo, appartenga a uno dei gruppi del cliente e rientri nel limite credito effettivo del cliente prima di creare l'ordine PrestaShop. Solo dopo la validazione dell'ordine crea il record pagamento differito con il termine selezionato, il totale ordine IVA inclusa e la data di scadenza calcolata.

$dueDate = date('Y-m-d', strtotime('+' . (int) $term->days . ' days'));

Il valore salvato viene copiato in mpr_deferred_order.due_date al momento dell'ordine. Cambiare in seguito il numero di giorni di un termine di pagamento non ricalcola le date di scadenza degli ordini già esistenti. I controlli sugli scaduti confrontano la data di scadenza salvata con la data server corrente, quindi una fattura non pagata in scadenza oggi è ancora in scadenza oggi; diventa scaduta solo dopo che quella data è passata.

Il valore del limite credito è per gruppo cliente, non per singolo cliente. Il modulo salva i limiti in mpr_pt_credit_limit, dove id_group è la chiave primaria, e anche i termini di pagamento sono assegnati ai gruppi tramite mpr_payment_term_group.

Per un cliente in più gruppi, il servizio recupera tutti i gruppi del cliente e usa MAX(credit_limit) tra essi. Esempio: se Ana appartiene a Retail senza limite configurato, B2B Silver con 1000.00 e B2B Gold con 2500.00, il suo limite credito effettivo è 2500.00.

Un limite configurato di 0 viene trattato come illimitato dal servizio checkout. Quando esiste un limite reale, il modulo sottrae gli ordini differiti in sospeso di quel cliente nel negozio corrente e mostra i termini Pay by Invoice solo quando outstanding + cart total resta entro il limite gruppo effettivo.

Limiti di credito e disponibilità dei termini sono collegati ma separati. Assegnare un limite a un gruppo non rende da solo disponibile ogni termine di pagamento; il termine deve anche essere attivo e assegnato ad almeno uno dei gruppi del cliente. Allo stesso modo, assegnare un termine a un gruppo senza un limite credito reale significa che il gruppo può usare il termine finché il limite effettivo risulta illimitato o un altro gruppo fornisce limite sufficiente.

L'importo in sospeso è calcolato dalle righe non pagate in mpr_deferred_order per lo stesso cliente e negozio corrente. Le righe già marcate pagate sono escluse, e il totale carrello usato per il nuovo ordine è il totale ordine IVA inclusa. Se il cliente supera il limite effettivo, il servizio checkout rimuove tutti i termini differiti dalle opzioni pagamento disponibili e il validation controller rifiuta un pagamento differito inviato anche se qualcuno posta manualmente il termine.

L'installazione crea uno stato ordine chiamato Awaiting Deferred Payment, salva il suo ID in OS_AWAITING, e il validation controller usa quello stato quando chiama validateOrder() per ordini Pay by Invoice. Se lo stato salvato manca, il controller ripiega sullo stato bonifico bancario di PrestaShop.

• logable = true significa che PrestaShop tratta l'ordine come un ordine valido inserito per flussi storico ordine e statistiche, anche se il pagamento è ancora in sospeso.
• invoice = true e pdf_invoice = true significano che la generazione fattura è abilitata per lo stato ordine differito.
• paid = false significa che lo stato ordine non marca l'ordine come pagato; il modulo traccia il saldo separatamente in mpr_deferred_order.is_paid.

Quando il record differito viene creato, is_paid parte da 0. Il metodo markAsPaid() del model deferred-order imposta poi is_paid a 1 e registra paid_date, senza cambiare il significato dello stato ordine iniziale.

Lo stato installato è di proprietà del modulo, usa l'etichetta Awaiting Deferred Payment in ogni lingua ed è creato con send_email = false, unremovable = false e un valore colore blu. La pagina payment-return può quindi mostrare il termine di pagamento selezionato, l'importo dovuto e la data di scadenza mentre l'ordine resta non pagato dal punto di vista dello stato pagamento PrestaShop.

C'è un follow-up importante nel back office: quando un admin marca un ordine differito come pagato tramite il controller deferred-orders del modulo, il modulo aggiorna prima mpr_deferred_order. Se l'ordine PrestaShop collegato è ancora nello stato awaiting del modulo e lo stato pagato standard PS_OS_PAYMENT esiste, sposta anche l'ordine PrestaShop a quello stato pagato. Se l'ordine è già stato spostato in un altro stato, il modulo non sovrascrive ciecamente quello stato.

Una notifica reale viene costruita da ordini PrestaShop validi nello shop corrente, limitati dall'età massima ordine configurata e da regole include o exclude prodotto. Usa il prodotto ordinato, la città di consegna e il nome mascherato.

No. Le notifiche di vendita generate non sono ordini PrestaShop reali e non vengono scritte nella tabella ordini. Il modulo ha tre modalità di notifica:

• Solo ordini reali: mostra ordini validi recenti da PrestaShop, usando nomi cliente mascherati, città, dati prodotto, immagine prodotto, prezzo e tempo relativo.
• Solo generate: costruisce notifiche dall'aspetto realistico da prodotti catalogo attivi più pool di nomi e città configurati o integrati. Sono messaggi di visualizzazione, non ordini.
• Mista: usa prima notifiche da ordini reali e riempie gli slot rimanenti con notifiche generate quando non ci sono abbastanza ordini reali recenti.

La modalità installata di default è mixed. In modalità mista, se le notifiche reali sono meno del numero richiesto, il codice genera automaticamente riempitivi; non c'è un toggle separato per il riempimento generato dentro la modalità mista. Se ogni notifica deve corrispondere a un acquisto reale, passa il modulo alla modalità Real orders only e assicurati che età massima ordine e filtri prodotto siano abbastanza ampi da restituire ordini recenti.

Le notifiche reali vengono caricate da ordini PrestaShop validi nel negozio corrente, limitate dall'età massima ordine configurata. L'età massima predefinita è 72 ore. Le liste prodotti include ed exclude vengono applicate prima che la notifica sia restituita, e il nome cliente mostrato è mascherato invece di mostrare il nome completo.

Le notifiche generate sono costruite da prodotti attivi nel catalogo. Il modulo seleziona dati prodotto, calcola un prezzo di visualizzazione, prova a usare l'immagine di copertina prodotto, sceglie nome e città dai suoi pool e crea un tempo relativo come un numero recente di minuti fa. Questo avviene al momento della visualizzazione tramite l'endpoint notifiche del front office; non crea carrelli, ordini, clienti, dettagli ordine, pagamenti o righe storico ordine.

Il toast front-end etichetta le notifiche come Verified Purchase nel template di visualizzazione, incluse le notifiche generate. Quell'etichetta fa parte della presentazione del pop-up, non è prova che una notifica generata provenga da un ordine reale. Per negozi con requisiti rigidi di conformità o audit, usa la modalità Real orders only.

Sì. La configurazione accetta liste di ID prodotto include ed exclude separate da virgole. Questi filtri vengono applicati sia nella selezione degli articoli ordine reali sia nella selezione dei prodotti per notifiche generate.

Il front controller notifications restituisce JSON con header risposta noindex quando il modulo è attivo. Lo script browser recupera quel feed e renderizza le notifiche toast in base alle impostazioni di timing.

No, il modulo crea il punto di ingresso storefront verso Telegram. Dopo il click dell'acquirente, Telegram gestisce la conversazione nell'app Telegram o nell'esperienza web. Questo mantiene il modulo semplice ed evita di creare una seconda inbox messaggi dentro PrestaShop.

Il widget renderizza un link Telegram fisso usando lo username configurato. Se è configurato un messaggio precompilato opzionale, il modulo lo aggiunge all'URL https://t.me/... e sostituisce {url} con l'URL della pagina corrente prima di mandare l'acquirente a Telegram. Il browser apre Telegram in una nuova scheda o nel contesto app; la chat stessa non è incorporata nella pagina PrestaShop.

Il modulo non salva messaggi Telegram in arrivo, non crea thread del servizio clienti PrestaShop e non esegue un webhook Telegram o una inbox bot nel back office. Storico conversazioni, risposte, allegati e notifiche restano in Telegram.

La visualizzazione è controllata dalle impostazioni del modulo. Il widget viene renderizzato solo quando il modulo è abilitato e c'è uno username Telegram valido. Puoi anche controllare posizione storefront, stile icona o barra, testo call-to-action, colore, dimensione, margine, tooltip, animazione, ritardo di visualizzazione, visibilità mobile e ambito pagina come tutte le pagine, pagine prodotto, pagine categoria o pagine checkout.

Sì, Weekly Flash Sale può pubblicare automaticamente, ma solo tramite moduli publisher compatibili. Il task cerca mprinstagramintegration con publishToInstagram(), mprfacebookpostsintegration con publishToFacebook() e mprxintegration con publishToX(). Costruisce ogni caption dai template Instagram, Facebook e X usando placeholder come {product_name}, {original_price}, {sale_price}, {discount}, {code} e {product_url}.

• ok:... significa che il publisher ha restituito un risultato piattaforma, quindi l'invio è stato trattato come riuscito.
• skipped significa che il modulo piattaforma manca o è inattivo, il metodo publish richiesto manca, oppure la caption della piattaforma è vuota.
• FAIL significa che il metodo publish ha restituito false.
• FAIL:message significa che il publisher ha lanciato un'eccezione, e il messaggio dopo il prefisso viene salvato per diagnosi.
• dry-run è uno stato complessivo di esecuzione test. Il task ritorna prima di creare la regola carrello, pubblicare o scrivere lo storico vendita.
• disabled viene restituito quando weekly sale è disabilitato e l'esecuzione non è dry run.

Per le esecuzioni reali, i risultati per piattaforma vengono salvati in mprweeklysale_history come ig_result, fb_result e x_result, insieme a prodotto, sconto, codice generato e date vendita.

Il post automatico fa parte del task flash-sale. Un'esecuzione reale prima sceglie un prodotto attivo che non è stato usato di recente secondo la finestra storico configurata, crea una regola carrello per lo sconto, poi chiama i moduli social publisher disponibili. La configurazione predefinita usa uno sconto 50%, durata 24 ore, prefisso codice FLASH, finestra storico 12 settimane e pianificazione settimanale il mercoledì alle 08:00.

La regola carrello generata è specifica per prodotto, attiva, evidenziata, limitata a quantità 1000 e quantità per utente 1. Le caption sono costruite dopo che prezzo vendita, codice sconto, URL prodotto e immagine prodotto sono stati preparati. La caption X viene accorciata per rispettare il limite della piattaforma, e anche la caption Instagram viene limitata prima della pubblicazione.

La pubblicazione automatica quindi richiede più che abilitare Weekly Flash Sale. Il modulo di integrazione corrispondente deve essere installato, attivo ed esporre il metodo publish previsto, e il task cron pianificato deve girare con il token corretto. Se un modulo piattaforma manca, la vendita può comunque essere creata e la piattaforma mancante viene registrata come skipped.

Usa lo slider homepage del modulo per renderizzare un hero carousel sull'hook displayHome di PrestaShop. Il codice risolve lo slider predefinito tramite l'identificatore homepage, carica i suoi banner attivi, unisce i campi testo della lingua/negozio corrente quando disponibili ed emette il carousel solo quando esistono immagini utilizzabili.

All'installazione il modulo inserisce uno slider attivo con identificatore homepage. Per mostrare un hero in homepage, crea o modifica banner per quello slider, carica almeno un'immagine valida, mantieni il banner attivo e assicurati che il modulo resti agganciato a displayHome. L'hook chiama lo stesso renderer widget con slider = homepage, quindi l'output homepage segue le stesse regole dei widget incorporati.

La query del carousel carica banner attivi assegnati allo slider selezionato e li ordina per posizione e poi per ID banner. La riga lingua/negozio è unita con un LEFT JOIN, quindi titolo, sottotitolo e testo CTA vengono presi dalla lingua e negozio correnti quando quella riga esiste, ma un banner non viene rifiutato solo perché manca la riga testo lingua/negozio. Questo significa che un banner solo immagine non tradotto può comunque renderizzarsi.

Se nessun banner attivo ha un file immagine desktop o mobile esistente, il modulo restituisce una stringa vuota invece di renderizzare un'area hero rotta.

Il comportamento di visualizzazione deriva dalla configurazione del modulo. La velocità predefinita è 5000 millisecondi, autoplay è abilitato, controlli e indicatori sono abilitati, la transizione è slide, lo stile Ken Burns è abilitato e l'altezza predefinita è 500. Il template assegna anche eager loading e fetch priority al primo slide, mentre gli slide successivi sono lazy-loaded per ridurre il peso iniziale della pagina.

Sì, ogni banner può salvare un'immagine desktop e un'immagine mobile opzionale per PrestaShop. Il template carousel emette sorgenti picture responsive, usa l'immagine mobile su schermi piccoli e aggiunge sorgenti AVIF o WebP quando esistono file corrispondenti accanto alle immagini configurate.

L'immagine mobile è destinata agli schermi stretti ed è emessa con una condizione media max-width: 767px. L'immagine desktop resta la normale immagine fallback dello slide, quindi è meglio caricare un'immagine desktop per ogni banner e aggiungere un'immagine mobile quando il crop deve cambiare per i telefoni.

Il modulo non converte immagini durante il rendering. Controlla se file fratelli con lo stesso nome base ed estensioni .avif o .webp esistono già, poi aggiunge quelle sorgenti quando presenti. Se quei file ottimizzati non sono su disco, il carousel ripiega sui percorsi originali delle immagini caricate.

Un banner senza file immagine desktop né mobile viene saltato prima del rendering. Questo evita slide carousel vuoti. Se esiste solo un'immagine mobile, il banner può comunque passare il controllo file, ma i visitatori desktop potrebbero non avere un fallback desktop adeguato, quindi la configurazione merchant dovrebbe trattare l'immagine desktop come base e l'immagine mobile come override responsive opzionale.

Sì, il modulo implementa il rendering widget PrestaShop per slider fuori dalla homepage. Un template può chiamare il widget con un slider_id numerico o con un identificatore slider salvato nella tabella slider del modulo.

{widget name='mprbannerrevolution' slider_id=2} {widget name='mprbannerrevolution' slider='homepage'} {widget name='mprbannerrevolution' slider='landing-sale'}

Se non viene passato alcun parametro, il modulo risolve lo slider predefinito homepage. Il codice non assegna automaticamente slider alle pagine CMS; risolve lo slider dai parametri widget, poi renderizza solo banner attivi per quello slider che hanno un'immagine desktop o mobile disponibile.

La versione con identificatore funziona solo per slider attivi, perché la lookup usa il controllo active della tabella slider. Il percorso numerico slider_id carica esattamente quell'ID slider. Dopo la risoluzione dello slider, viene usata la stessa pipeline della homepage: lingua corrente, negozio corrente, banner attivi, controlli esistenza file, sorgenti responsive, impostazioni carousel e template carousel condiviso.

C'è un commento codice che menziona slider_cms, ma il resolver implementato gestisce slider_id, slider e lo slider homepage predefinito. Per pagine CMS o landing page, usa una chiamata widget esplicita nel contenuto pagina o nel template tema invece di aspettarti che il modulo mappi automaticamente le pagine CMS agli slider.

Puoi configurare il contenuto banner reale usato dal carousel PrestaShop: titolo tradotto, sottotitolo, testo CTA e URL CTA. Ogni banner salva anche colore overlay, opacità overlay, allineamento testo, stato attivo, posizione, immagine desktop e immagine mobile opzionale.

I campi contenuto sono multilingua, quindi titolo banner, sottotitolo, testo pulsante e URL pulsante possono variare per lingua. Il titolo viene usato come heading principale dello slide, il sottotitolo appare sotto e il pulsante CTA appare solo quando sia testo CTA sia URL CTA sono presenti per quella lingua.

I controlli visuali sono salvati con il banner stesso. Il colore overlay predefinito è nero, l'opacità overlay è un valore percentuale e l'allineamento testo supporta left, center e right. Il flag attivo controlla se il banner può apparire, e il valore posizione controlla l'ordinamento dentro lo slider selezionato.

I campi immagine sono i media reali usati dal carousel. L'immagine desktop è l'immagine principale dello slide, e l'immagine mobile opzionale offre ai telefoni un crop diverso. Il flusso di upload admin accetta formati web comuni come JPG, PNG, WebP e GIF, mentre il renderer front office può aggiungere anche sorgenti AVIF o WebP se esistono file ottimizzati corrispondenti su disco.

I campi testo vuoti sono consentiti. Un banner può quindi essere usato come slide puramente visuale, hero con testo sopra immagine o slide promozionale con pulsante, in base ai campi tradotti compilati.

Sì, i messaggi inviati vengono salvati in PrestaShop. Il processor crea un record submission con stato, flag spam, indirizzo IP, user agent, contesto cliente o ospite, poi salva ogni valore campo inviato nella tabella submission-data del modulo.

La riga principale submission viene salvata in mprcontactform_submission. Include ID form, ID negozio, ID cliente quando il visitatore è loggato, nome cliente, email cliente, indirizzo IP, user agent, stato, flag spam, motivo spam e data creazione. Gli invii ospite vengono salvati con ID cliente 0.

Le singole risposte sono salvate separatamente in mprcontactform_submission_data. Ogni riga salva ID submission, ID campo, nome campo e valore campo inviato. Questo permette al modulo di mantenere separati l'intestazione submission e i campi dinamici del form, cosa importante perché ogni form può avere un set di campi diverso.

Il processor valida il form attivo e i suoi campi attivi prima del salvataggio. Campi obbligatori, formato email, formato telefono, formato URL, campi numerici, opzioni select, validatori personalizzati e checkbox GDPR possono tutti rifiutare l'invio prima che venga registrato. Poi girano i controlli anti-spam; gli invii spam vengono comunque salvati con is_spam = 1 e un motivo, ma le normali email admin e cliente vengono inviate solo per invii non spam.

L'indirizzo IP viene preso dagli header forwarded quando presenti, poi dal fallback remote address, e lo user agent viene salvato con limite di lunghezza. Questo crea una traccia audit per le richieste senza trasformare il modulo in un CRM completo; il follow-up avviene comunque tramite i destinatari email configurati o qualunque flusso back-office il merchant usi per revisionare gli invii.

Sì, le richieste possono essere instradate ai destinatari admin configurati. Ogni form può definire indirizzi email admin e una riga oggetto; il mailer accetta destinatari separati da virgola e ripiega sull'email globale del modulo o sull'email del negozio quando il destinatario del form è vuoto.

Questo routing è per form, quindi un contact form può inviare richieste vendita a una casella mentre un altro form invia richieste supporto a una casella diversa. Il form ha anche un'impostazione send_admin_email; se le email admin sono disabilitate per quel form, l'invio può comunque essere salvato senza inviare una notifica admin.

Il fallback destinatario avviene in ordine. Il mailer usa prima la lista email admin del form, poi l'impostazione email admin a livello modulo, poi PS_SHOP_EMAIL. Si possono inserire più destinatari come lista separata da virgole. Gli indirizzi email non validi vengono saltati invece di essere usati per l'invio.

L'oggetto admin proviene dall'oggetto email tradotto del form quando impostato, altrimenti ripiega su un oggetto generico di nuovo invio. Il nome negozio viene aggiunto, e l'email cliente inviata viene usata come reply-to quando disponibile, così rispondendo dalla casella si può tornare al cliente.

La conferma cliente è separata. Se send_customer_email è abilitato e l'invio include un indirizzo email cliente, il modulo può inviare anche al visitatore un messaggio di conferma. Gli invii spam sono salvati per revisione, ma il mailer non viene chiamato per essi, quindi di norma lo spam non viene inoltrato ai destinatari admin o ai clienti.

Sì. Il modulo controlla gli invii prima di mandare email, marca lo spam rilevato nel record submission e salva un motivo spam. La fonte include questi trigger anti-spam:

• Honeypot: il campo nascosto website_url_confirm deve restare vuoto.
• Tempo di invio: il timestamp nascosto _mpr_ft deve essere presente, valido e più vecchio del min_submit_time configurato del form.
• Rate limit: l'IP mittente viene bloccato quando ha già raggiunto il massimo di invii per ora del form.
• IP bloccati: l'IP mittente viene confrontato con la lista di IP bloccati del form, separata da nuove righe.
• Parole bloccate: ogni campo inviato viene controllato per parole bloccate configurate usando una corrispondenza substring case-insensitive.

Per impostazione predefinita, i form appena installati abilitano honeypot e controllo tempo con un tempo minimo di invio di 3 secondi. Gli invii spam sono salvati per revisione, ma il normale flusso email admin/cliente gira solo per invii non spam.

Il rate limit predefinito a livello modulo è 10 invii per IP per ora. Impostare il massimo invii per IP per ora a 0 disabilita quel controllo rate-limit. La query rate-limit conta gli invii salvati dallo stesso indirizzo IP nell'ora precedente, quindi tentativi ripetuti possono essere bloccati anche se il visitatore continua a reinviare lo stesso form.

Il controllo tempo è progettato per intercettare post automatici che inviano subito o omettono il timestamp nascosto. Un visitatore reale riceve il campo nascosto _mpr_ft con il form, mentre un bot che posta direttamente senza caricare la pagina di solito fallirà il requisito timestamp.

I motivi spam sono salvati come etichette machine-readable come honeypot, timing, rate_limit, blocked_ip e blocked_words. Più di un motivo può essere registrato sullo stesso invio, aiutando a distinguere un semplice invio troppo veloce da un messaggio che contiene anche parole bloccate.

Sì, può sostituire la pagina contatto predefinita di PrestaShop quando quella impostazione è abilitata. Il modulo aggiunge route contatto e usa l'hook dispatcher per reindirizzare il controller contatto core al proprio rendering della pagina contatto, mantenendo disponibili i normali link display del modulo.

L'impostazione è disabilitata per impostazione predefinita. Quando replace_core_contact è abilitato, il modulo espone route contatto tramite hookModuleRoutes, usando la riscrittura della pagina contatto del negozio quando possibile, e gestisce anche il controller core contact tramite l'hook dispatcher.

In termini implementativi, l'hook dispatcher non invia un redirect browser 301 o 302. Riscrive i parametri della richiesta corrente sul posto cambiando il controller al controller display del modulo e impostando il nome modulo a mprcontactform. L'acquirente resta nel flusso contatto, ma PrestaShop renderizza la pagina contatto del modulo invece del controller contatto core.

Il modulo può anche renderizzare form tramite la propria route display modulo e tramite hook come displayMprContactForm e displayContactContent. Questo significa che i merchant possono sostituire la pagina contatto principale, incorporare un form specifico altrove o lasciare invariata la pagina contatto core e usare solo link del modulo.

Se la sostituzione non è abilitata, l'hook route non restituisce route di sostituzione contatto e la pagina contatto core resta sotto il normale controllo di PrestaShop. Questo rende la funzione reversibile dalla configurazione senza disinstallare il modulo.

Il modulo aggiunge un'azione di eliminazione alla pagina dettaglio ordine admin di PrestaShop. Viene renderizzata tramite gli hook displayAdminOrderMain e displayAdminOrder quando il modulo è abilitato e un ID ordine è disponibile, poi invia l'ordine al flusso cestino del modulo.

Su un'installazione standard il modulo è abilitato e la conferma è richiesta. La pagina ordine mostra un blocco Delete Order con un pulsante che collega al controller admin del modulo usando un parametro trash_order. Se la conferma è abilitata, il template aggiunge un prompt di conferma browser prima che l'azione venga inviata.

Quando l'admin conferma, il controller passa ID ordine e ID dipendente corrente al servizio cestino. Il servizio carica l'Order PrestaShop, crea lo snapshot cestino, salva chi l'ha eliminato e poi chiama il metodo delete ordine nativo di PrestaShop. Se l'ordine non può essere caricato come oggetto valido, l'azione cestino restituisce false invece di eliminare qualsiasi cosa.

L'azione è pensata per ordini di test, duplicati o indesiderati che un merchant sceglie deliberatamente di rimuovere dal back office. Non è un flag soft-hide sulla riga ordine originale; dopo il completamento del flusso cestino, il metodo delete ordine nativo di PrestaShop è stato chiamato e il record residuo del modulo è solo lo snapshot cestino.

Prima di eliminare, il modulo carica l'Order PrestaShop, crea un riepilogo JSON compatto, inserisce una riga in mprdeleteorders_trash e poi chiama il metodo delete ordine nativo. La tabella cestino viene mantenuta intenzionalmente alla disinstallazione per sicurezza.

{"id_order":1234,"reference":"ABCDEF123","id_customer":42,"total_paid":149.90,"date_add":"2026-06-17 10:15:00","current_state":2}

• id_order: l'ID ordine PrestaShop originale, salvato anche come colonna top-level della tabella cestino per filtrare.
• reference: il riferimento ordine, salvato anche come order_reference.
• id_customer: l'ID cliente collegato all'ordine eliminato.
• total_paid: il totale ordine da total_paid_tax_incl.
• date_add: la data di creazione originale dell'ordine.
• current_state: l'ID stato ordine al momento dell'eliminazione.
• deleted_by: l'ID dipendente back-office che ha cliccato l'azione cestino.
• date_deleted: quando il record cestino è stato creato.

Questo è uno snapshot audit, non un backup completo e reversibile di ogni tabella collegata all'ordine, fattura, messaggio e riga articolo. Usalo per identificare cosa è stato eliminato e da chi prima dell'eliminazione permanente.

La tabella cestino stessa salva id_trash, id_order, order_reference, order_data, deleted_by e date_deleted. Il controller lista può mostrare queste righe cestino così un admin può revisionare ID ordine originale, riferimento, dipendente eliminatore e data eliminazione.

Il JSON contiene deliberatamente solo un piccolo set di valori header dell'ordine. Non salva prodotti, dettagli ordine, indirizzi, pagamenti, fatture, messaggi, righe corriere, contenuti carrello, voucher o storico movimenti stock. Per questo motivo va trattato come tracciabilità delle eliminazioni, non come pacchetto di ripristino.

No, il modulo non ricostruisce dal cestino un ordine PrestaShop eliminato. Quando un ordine viene spostato nel cestino, salva un piccolo snapshot JSON con valori come ID ordine, riferimento, ID cliente, totale pagato, data creazione e stato corrente, poi chiama il metodo delete ordine di PrestaShop.

Il metodo restore legge solo la riga cestino, conferma che esiste, elimina quella riga cestino e restituisce successo per quell'azione di pulizia. Non ricrea la riga ordine originale, dettagli ordine, pagamenti, fatture, storico ordine, dati carrello o record correlati.

Questa limitazione è importante perché il modulo non salva abbastanza dati relazionali per eseguire una ricostruzione completa e sicura di un ordine. Tratta il cestino come buffer di audit e pulizia, non come backup completo. Per un recupero reale, usa un backup database o un processo di ripristino manuale fuori da questo modulo.

Anche l'azione di pulizia permanente del cestino è separata dal ripristino ordine. Rimuovere una riga cestino rimuove solo lo snapshot audit del modulo; non influisce su un ordine PrestaShop già eliminato perché i dati ordine originali sono già stati rimossi dalla chiamata delete nativa.

Per negozi live, il flusso pratico è usare il modulo per cancellare ordini noti di test o indesiderati, mantenere backup database per il recupero e verificare l'ordine prima di eliminarlo. Se un ordine potrebbe dover essere recuperato con prodotti, pagamenti, fatture e storico intatti, non fare affidamento sulla riga cestino del modulo come fonte di recupero.

No, il percorso di disinstallazione mantiene la tabella cestino per sicurezza. In PrestaShop il modulo rimuove tab e configurazione, ma il commento nel codice dice che mprdeleteorders_trash viene conservata alla disinstallazione.

Sì. Quando il tracciamento acquisti è abilitato e al modulo è consentito tracciare il visitatore, emette un evento Hotjar purchase dall'hook di conferma ordine PrestaShop. Il template front office chiama hj('event', 'purchase') nella pagina di conferma ordine.

Questo è utile per l'analisi Hotjar perché puoi filtrare registrazioni, heatmap, survey o funnel attorno alle sessioni che hanno raggiunto un acquisto, poi ispezionare il comportamento prima dell'ordine. Aiuta a rispondere a domande come dove gli acquirenti hanno esitato, quali passaggi checkout hanno ripetuto o quali pattern pagina compaiono nelle sessioni riuscite.

Non è un sostituto per analytics dei ricavi o report ordini lato server. Hotjar riceve l'evento nominato per segmentazione comportamentale; i dettagli ordine del modulo sono usati principalmente per costruire contesto evento locale e non sono un feed transazionale completo.

La funzione dipende dai normali guard del modulo Hotjar. Il modulo deve essere abilitato, l'Hotjar Site ID deve essere configurato come cifre, il tracciamento acquisti deve essere abilitato e il visitatore deve superare i controlli di tracciamento del modulo, come la gestione consenso quando il rispetto del consenso è abilitato. Se il tracciamento non è consentito, l'hook di conferma ordine non restituisce nulla.

Quando l'hook gira, il modulo costruisce contesto acquisto locale dall'ordine PrestaShop, includendo valori come ID ordine, valuta, valore totale, numero articoli e identificatori prodotto. Quel contesto viene assegnato al template di conferma ordine e può essere usato dal tooling locale di registrazione/demo eventi del modulo, ma la chiamata Hotjar Events API fatta dal template resta il semplice evento nominato purchase.

In Hotjar, usa l'evento purchase come marker comportamentale. Per totali, imposte, margine, attribuzione, gestione rimborsi o report conversione autorevoli, continua a usare i dati ordine PrestaShop o una piattaforma analytics progettata per report transazionali.

No. Il modulo invia eventi PrestaShop e contesto cliente a Klaviyo, ma logica campagne, segmenti, contenuto email e flow SMS sono gestiti in Klaviyo. Questa separazione è utile perché i dati negozio provengono da PrestaShop mentre la strategia marketing resta nella piattaforma marketing.

In termini di fonte, il lato PrestaShop è limitato alla consegna dati onsite. Quando ENABLED è impostato e PUBLIC_API_KEY è presente, l'hook header carica lo script onsite di Klaviyo con il company id. I default di installazione lasciano il modulo disabilitato, mantengono vuota la chiave pubblica e forniscono toggle di tracciamento come TRACK_VIEWED, TRACK_CART e TRACK_PURCHASE.

Il template front può identificare clienti loggati con email e nome, tracciare una pagina prodotto come Viewed Product e tracciare la pagina carrello come Added to Cart. Non contiene un builder flow Klaviyo, editor segmenti, editor template email, schermata workflow SMS o layer API campagne. La fonte espone un toggle acquisto, ma il template di tracciamento browser ispezionato non emette una chiamata di tracciamento acquisto, quindi l'automazione purchase dovrebbe comunque essere verificata in Klaviyo invece di essere presunta dalla sola impostazione PrestaShop.

PUBLIC_API_KEY=YOUR_KLAVIYO_PUBLIC_KEY ENABLED=1 TRACK_VIEWED=1 TRACK_CART=1

In parte. Il modulo ha template product-card e caricamento dati prodotto, ma il percorso storefront implementato non è una colonna dropdown autonoma product_list. MenuBuilder può caricare elementi colonna product_list da un ID categoria e limite, ma extractChildrenFromColumns() non espone gli elementi product_list come figli menu, quindi i merchant non dovrebbero fare affidamento su quel tipo colonna per renderizzare card prodotto finché non viene aggiunto supporto template/children.

Il percorso implementato oggi è l'anteprima prodotti sotto figli di category-tree. Aggiungi una colonna dropdown di tipo category_tree, abilita PRODUCTS_NB con un valore sopra zero, e il builder può collegare prodotti da ogni figlio categoria. Il template storefront renderizza poi il primo prodotto collegato come card in evidenza e i prodotti collegati rimanenti come card più piccole nel pannello.

SHOW_PRICES e SHOW_DISCOUNTS controllano se prezzi e badge sconto appaiono; entrambi sono abilitati per impostazione predefinita. PRODUCTS_NB controlla quante anteprime prodotto dei figli categoria vengono collegate. Il TTL cache menu controlla quanto rapidamente appaiono le modifiche strutturali, e gli hook di aggiornamento prodotto, categoria e CMS sono registrati per pulire i dati menu in cache quando il contenuto del negozio cambia.

Implemented storefront path:
category_tree child + PRODUCTS_NB > 0 = product previews under that category child.
Not currently implemented as rendered storefront cards:
standalone product_list column.

Il modulo renderizza il menu mobile dalla stessa configurazione menu top-level, con un parser mobile dedicato. Questo riduce la manutenzione duplicata e aiuta a mantenere allineata la navigazione desktop e mobile. Dovresti comunque revisionare il layout mobile perché etichette lunghe e alberi categoria profondi possono influire sull'usabilità.

Gli output desktop e mobile ricevono entrambi gli stessi dati $menu.children per l'albero off-canvas. Su mobile, il template renderizza quell'albero, mentre HtmlMobileTreeParser e il menu builder possono convertire diversi layout colonna desktop in una struttura mobile più semplice, incluse category tree, CMS category tree, categorie blog, gruppi link, link CMS, liste link, alberi mobile derivati da HTML e visual tabs.

Questo significa che normalmente mantieni una volta sola nel modulo etichette, link, alberi categoria, link CMS, visual tabs e contenuto custom mobile-tree compatibile. L'eccezione pratica è il contenuto che non viene estratto in menu.children. In particolare, le colonne desktop product_list non vengono estratte nell'attuale albero mobile, e il template mobile renderizza solo $menu.children; il contenuto product-list avrebbe bisogno di supporto template storefront/mobile prima di apparire nel menu off-canvas.

L'HTML personalizzato è un'altra area da testare. Se una colonna contiene markup insolito e nessun albero mobile utilizzabile, il parser mobile può ripiegare su una struttura semplice o vuota, quindi testa etichette lunghe, alberi annidati e HTML promozionale su una larghezza mobile reale prima di farci affidamento per la navigazione.

No. Il modulo collega PrestaShop a Tidio e controlla il comportamento di caricamento storefront. Flow chatbot, gestione inbox e workflow operatori sono gestiti dentro Tidio, dove appartengono questi strumenti.

Le impostazioni PrestaShop sono impostazioni di connessione e rendering: PUBLIC_KEY è richiesto e validato, ENABLED ha come predefinito 1, e il widget può essere ritardato, nascosto su mobile, limitato per tipo pagina e opzionalmente ricevere email/nome del cliente loggato tramite PASS_USER_DATA.

PUBLIC_KEY=your_tidio_public_key ENABLED=1 PAGES=all DELAY=0 PASS_USER_DATA=1

Nel front office il template definisce solo dati opzionali document.tidioIdentify e aggiunge lo script ospitato di Tidio da code.tidio.co. In questo modulo non c'è builder bot lato PrestaShop, vista inbox, schermata assegnazione operatori, tabella storico messaggi o flow API, quindi l'automazione vendite/supporto deve comunque essere configurata nella dashboard Tidio.

La configurazione salva stato di abilitazione, titolo, messaggio HTML, visibilità del campo newsletter, ritardo in secondi, durata del cookie in giorni e se mostrare il popup su tutte le pagine o solo sulla homepage.

Dopo che il visitatore lo chiude, lo script imposta il cookie mprwpop_seen per il numero di giorni configurato. Lo script del popup controlla quel cookie prima di mostrarsi di nuovo.

No. Il campo email è solo visuale in questo modulo. Quando SHOW_NEWSLETTER è abilitato, il template front renderizza un form newsletter con un input email e pulsante Subscribe, ma il modulo stesso non contiene front controller, handler AJAX, inserimento in tabella subscriber o integrazione con modulo newsletter che salvi gli indirizzi inviati.

Lo script popup gestisce solo tempi di visualizzazione, chiusura della modale, chiusura con tasto Escape e cookie mprwpop_seen. Non intercetta l'invio del form e non manda l'indirizzo da nessuna parte.

Se vuoi acquisire lead, collega quel form al tuo handler, a un modulo newsletter, a un endpoint Brevo o Mailchimp, o a una form action a livello tema che il negozio processa. Finché tale integrazione non esiste, abilitare il campo mostra solo una casella email; non crea iscritti newsletter.

Le impostazioni modulo correlate decidono solo se il campo viene mostrato e con quale frequenza appare il popup. I default di installazione impostano SHOW_NEWSLETTER a 0, DELAY a 3 secondi, COOKIE_DAYS a 7 e SHOW_ON a all; SHOW_ON=homepage lo limita al controller index.

Il cookie di visibilità viene impostato quando l'acquirente chiude il popup, clicca l'overlay o preme Escape. Inviare il form newsletter non crea un record subscriber in questo modulo, e il form template non ha action URL, quindi un merchant dovrebbe trattarlo come placeholder front-end finché non viene collegato a un endpoint newsletter reale.

<form class='mprwpop-newsletter' id='mprwpop-nl-form' method='post'>

Sì. Quando l'impostazione di visualizzazione è solo homepage, il hook restituisce contenuto solo se la pagina corrente del front controller è la pagina index.

Aggiungi il tuo Microsoft UET Tag ID numerico e abilita il tracciamento browser nel modulo. L'hook header PrestaShop carica lo script UET, invia l'evento page load e poi invia gli eventi browser configurati quando il tracciamento è attivo e le regole di consenso lo consentono.

In una nuova installazione, il tracciamento non è live finché quelle impostazioni non sono complete: ENABLED ha come predefinito 0, TAG_ID è vuoto, e il modulo si considera attivo solo quando il tag ID è numerico. Nel form admin, salva il Microsoft Ads UET tag ID senza lettere o spazi, mantieni RESPECT_CONSENT abilitato se usi un modulo cookie supportato e decidi quali toggle evento devono restare attivi.

TAG_ID=123456789 ENABLED=1 RESPECT_CONSENT=1 TRACK_PAGE_VIEW=1 TRACK_PRODUCT_VIEW=1 TRACK_PURCHASE=1

Quando l'hook header gira, può anche catturare msclkid dall'URL di atterraggio per il matching conversioni successivo. L'esclusione dipendenti è abilitata di default tramite EXCLUDE_EMPLOYEES, quindi test da back office loggato potrebbero non emettere eventi se non consideri questa impostazione.

Sì, supporta Microsoft Conversions API per eventi acquisto lato server, ma solo quando le impostazioni richieste sono complete. Il modulo richiede tracciamento abilitato, un TAG_ID numerico, CAPI_ENABLED attivato, un CAPI_ACCESS_TOKEN salvato e tracciamento acquisto abilitato.

• Validazione admin: lo UET Tag ID deve contenere solo cifre, CAPI non può essere abilitata senza tag ID numerico, il bearer token è richiesto quando CAPI è abilitata, e il limite batch coda deve essere 1-100.
• Flusso ordine: su actionValidateOrder, il modulo controlla canTrack(), TRACK_PURCHASE e disponibilità CAPI prima di mettere in coda qualcosa.
• Flusso coda: una conversione acquisto viene messa in coda per provider microsoft_uet, legata all'ID ordine, poi il modulo elabora subito un piccolo batch di 3 eventi. Il task cron elabora più tardi il normale batch configurato.

Il tag UET browser può comunque gestire eventi pagina, carrello, ricerca e remarketing; il percorso CAPI in questo modulo è specificamente il percorso acquisto lato server.

Per la configurazione, i campi CAPI importanti sono:

CAPI_ENABLED=1 CAPI_ACCESS_TOKEN=your_microsoft_token CAPI_BATCH_LIMIT=20 TRACK_PURCHASE=1

Il client API invia eventi a Microsoft UET CAPI usando il tag ID numerico nell'endpoint e un bearer token. Il payload normalizza nome/id/tempo evento/source URL, consenso ad-storage, dati utente e dati acquisto personalizzati. Il matching utente può includere indirizzo IP, user agent, msclkid salvato, dettagli cliente hashati e identificatori anonimi carrello/ospite quando disponibili.

Non è un sostituto lato server per ogni evento browser del modulo. Page view, product view, search, add-to-cart, wishlist ed eventi custom click/URL/controller restano lato browser nella fonte ispezionata; CAPI è il supplemento server per gli acquisti.

Il modulo raggruppa gli eventi Microsoft Ads UET attorno ad attività storefront commerce, account, ricerca e trigger custom. Gli eventi principali sono configurabili singolarmente nelle impostazioni del modulo.

• Commerce/storefront: pageView, productView, addToCart, addToWishlist, initiateCheckout e purchase. Gli eventi prodotto, carrello e acquisto includono parametri commerce come ID prodotto, valori ordine, valuta e quantità quando disponibili.
• Ricerca: search si attiva sulle pagine risultati ricerca con il contesto query.
• Account: signUp viene attivato dopo la registrazione cliente tramite il flusso hook registrazione del modulo.
• Custom: eventi custom possono essere configurati con trigger click, URL, controller o DOM-event, con nomi evento limitati alle regole UET consentite dal modulo.

L'evento acquisto viene inviato nella pagina di conferma ordine, mentre gli eventi add-to-cart e wishlist sono catturati da listener JavaScript front office.

La maggior parte di quei toggle è abilitata di default all'installazione, inclusi TRACK_PAGE_VIEW, TRACK_PRODUCT_VIEW, TRACK_ADD_CART, TRACK_ADD_WISHLIST, TRACK_INITIATE_CHECKOUT, TRACK_SEARCH, TRACK_PURCHASE e TRACK_SIGNUP. TRACK_CUSTOM_EVENTS ha come predefinito off finché non definisci regole evento custom.

Le regole custom sono intenzionalmente limitate: il normalizzatore config accetta fino a 15 nomi evento distinti, rimuove parametri riservati event_id e supporta selettori click, corrispondenze URL contains, nomi controller o eventi DOM custom. Il JavaScript front office deduplica eventi pulsante add-to-cart e wishlist per circa un secondo, così la stessa azione ha meno probabilità di essere conteggiata due volte.

Sì. Con RESPECT_CONSENT abilitato, il modulo controlla il consenso marketing prima di considerare attivo il tracciamento Microsoft UET. Controlla prima mprcookiesrevolution leggendo il cookie mprcr_consent e cercando marketing:1. Se quel cookie è assente, ripiega sul valore DEFAULT_CONSENT di quel modulo. Se Cookies Revolution non è attivo, controlla mprcookiebanner tramite mprcookie_consent=granted, ripiegando di nuovo sull'impostazione consenso predefinito di quel modulo quando il cookie è assente.

Se nessun modulo consenso MPR supportato è attivo, la funzione consenso restituisce consentito, quindi il tracciamento non viene bloccato solo dal consenso. Per un blocco GDPR rigido, mantieni RESPECT_CONSENT abilitato e installa/configura uno dei moduli consenso supportati.

Il flusso msclkid gira nell'hook header. Il modulo legge msclkid dall'URL di atterraggio, accetta solo caratteri A-Za-z0-9._:- fino a 500 caratteri, lo rispecchia in $_COOKIE['mprbuet_msclkid'], poi scrive un cookie HTTP-only chiamato mprbuet_msclkid per 7776000 secondi. I dati utente della conversione lato server successiva possono includere quel Microsoft click ID salvato quando presente.

• https://shop.example/?msclkid=abc123 salva abc123 nel cookie del modulo.
• Un acquisto successivo può collegare quel valore ai dati conversione Microsoft UET se le conversioni lato server sono configurate.

Il controllo consenso lato server e il gate JavaScript front office lavorano insieme ma non sono identici. Il guard PHP canTrack() blocca la costruzione eventi per dipendenti, moduli disabilitati e consenso marketing fallito; il template header controlla anche i cookie browser prima di caricare bat.js quando è presente un modulo consenso client supportato.

Se RESPECT_CONSENT è impostato a 0, il controllo consenso viene bypassato. Se nessun modulo consenso MPR supportato è installato, la funzione PHP consente il tracciamento per il solo consenso, quindi i negozi rigorosi non dovrebbero fare affidamento solo sul modulo UET come unico layer consenso.

Il cookie msclkid viene scritto prima dell'acquisto successivo, cosa importante perché un acquirente può arrivare da Microsoft Ads, navigare e ordinare in una richiesta successiva. Il valore viene accettato solo se corrisponde alla whitelist caratteri del modulo; valori non validi o troppo lunghi vengono ignorati invece di essere inviati a Microsoft.

No. Il tag del browser viene iniettato dall'hook dell'intestazione di PrestaShop solo quando il tracciamento è attivo, cioè quando un TAG_ID numerico è salvato e ENABLED vale 1. La libreria Microsoft viene quindi aggiunta con script.async = true da https://bat.bing.com/bat.js, perciò si carica senza bloccare il rendering della pagina.

Al caricamento il modulo invia un singolo pageLoad a window.uetq e poi solo gli eventi che hai abilitato, come vista prodotto, aggiunta al carrello o acquisto, tramite uetq.push('event', ...). Quando è presente un modulo di consenso supportato, il pixel viene caricato solo dopo la conferma del consenso marketing nel browser, quindi i visitatori che rifiutano non generano alcuna richiesta a Microsoft.

L'invio lato server tramite la Conversions API viene eseguito in un'attività cron pianificata, non nella richiesta del cliente, e i dipendenti loggati sono esclusi per impostazione predefinita tramite EXCLUDE_EMPLOYEES.

Quando la Conversions API è abilitata e un token bearer Microsoft è salvato, gli eventi di acquisto vengono accodati alla convalida dell'ordine e inviati lato server da un'attività cron pianificata, send_bing_uet_conversions, che viene eseguita ogni 300 secondi. Ogni esecuzione elabora la coda fino al limite di batch configurato (CAPI_BATCH_LIMIT, predefinito 20, consentito 1–100 e limitato a 100 righe per esecuzione), così gli eventi falliti o in attesa vengono riprovati nel ciclo successivo invece di essere persi.

I dati utente lato server possono includere l'id di clic Microsoft memorizzato (msclkid), email e telefono con hash, IP del client e user-agent. Le voci elaborate e obsolete vengono ripulite automaticamente, mantenendo la cronologia recente e rimuovendo le righe vecchie nel tempo.

Se il token bearer manca o è vuoto, il blocco di prontezza nell'admin mostra un avviso e nessun evento lato server viene inviato finché non lo aggiungi. L'UET del browser può restare abilitato in modo indipendente per le visualizzazioni di pagina e il remarketing mentre configuri la Conversions API.

No, non per il pulsante contatto Messenger di base. L'impostazione richiesta è il Facebook Page ID numerico; senza App ID configurato, il template storefront renderizza un link diretto https://m.me/{page_id} così gli acquirenti aprono Messenger dal pulsante flottante.

• Modalità link m.me: richiede il modulo abilitato e un Page ID valido. È rapida da configurare e funziona come semplice link esterno di contatto Messenger.
• Modalità SDK: il modulo tratta il campo App ID compilato come lo switch per renderizzare il markup del plugin customer chat di Facebook e caricare l'SDK customer chat di Facebook. Il testo di saluto viene usato in quel markup modalità SDK.

Quindi i merchant che vogliono solo un pulsante Messenger affidabile possono lasciare vuoto l'App ID. Aggiungi l'App ID solo quando vuoi deliberatamente il percorso chat incorporata basato su SDK e hai pronta la configurazione lato Facebook.

Il requisito Page ID è rigido: il validator required-config del modulo accetta solo cifre, da 5 a 32 caratteri, e il widget non viene renderizzato mentre il modulo è abilitato ma quel campo è vuoto. I default abilitano il widget, lo mostrano su tutte le pagine incluso mobile, usano lo stile icona in basso a destra e ritardano la visualizzazione di 0 secondi.

Impostazioni di aspetto come POSITION, STYLE, CTA_TEXT, COLOR, SIZE, MARGIN, tooltip e animazione sono usate dal percorso del pulsante link flottante. Filtraggio pagina e visibilità mobile derivano dal guard chat condiviso, quindi puoi mostrare il punto di ingresso Messenger solo su pagine prodotto, categoria o checkout se si adatta al tuo flusso di supporto.

Il metodo fetch controlla prima RSS_URL. Se è vuoto, costruisce un URL RSS da BOARD_URL. Gli URL dei pin vengono usati solo quando il percorso RSS non produce post.

No. mprpinterestintegration è un modulo contenuto/feed Pinterest, non il modulo di tracciamento ads Pinterest. Mostra pin, board o contenuto RSS Pinterest nel negozio e include gestione cache per il feed mostrato. La fonte contiene anche impostazioni opzionali Pinterest API publishing per pubblicare prodotti/contenuti.

• Pinterest Feed Integration: usalo per mostrare contenuti Pinterest nello storefront, configurare username, URL pin, URL board o fonti RSS e opzionalmente pubblicare contenuti del negozio su Pinterest.
• Pinterest Tag: usa il modulo Pinterest Tag separato per misurazione pubblicitaria, eventi tag browser e tracciamento opzionale Conversions API come page visits, product views, add-to-cart, checkout, search e signup.

Se l'obiettivo è migliorare il visual merchandising o incorporare contenuti Pinterest, usa questa integrazione feed. Se l'obiettivo è attribuzione Pinterest Ads o ottimizzazione conversioni, usa invece il modulo Pinterest Tag.

Per il percorso feed, la fonte richiesta può essere semplice come uno o più URL pin salvati, oppure un URL board/fonte RSS in base a come vuoi curare i contenuti. Le impostazioni feed condivise controllano hook di visualizzazione, numero post, colonne, layout grid/slider, pulsante follow, visibilità mobile e durata cache; la cache ha come predefinito 3600 secondi e può essere aggiornata dall'admin del modulo.

Anche il percorso di pubblicazione opzionale è separato dal tracciamento ads. La pubblicazione Pinterest richiede credenziali API Pinterest come access token e board ID, e il publisher invia dati pin basati su immagine a Pinterest. Questo comunque non installa il tag pubblicitario Pinterest né riporta conversioni ads; per questo, il negozio necessita del modulo separato mprpinteresttag.

La config map include ACCESS_TOKEN, BOARD_ID, AUTOPUBLISH e AUTOPUBLISH_CAPTION. La pubblicazione è gestita tramite il PinterestPublisher condiviso.

Ogni item feed linka all'URL del pin, mostra immagine thumbnail, badge video opzionale, testo overlay, nome autore opzionale e caption opzionale in base alle impostazioni modulo e ai dati sorgente.

Il modulo richiede la Website Key Smartsupp. Il pannello di configurazione indica al merchant di copiarla dalle impostazioni Smartsupp e il validatore della configurazione obbligatoria considera non valida una chiave vuota.

Se PASS_USER_DATA è abilitato e il cliente è loggato, il trait chat condiviso restituisce customer_email e customer_name. Il template li assegna a _smartsupp.email e _smartsupp.name.

No. Il template carica lo script widget esterno di Smartsupp. L'interfaccia chat visibile è fornita da Smartsupp dopo l'esecuzione del loader.

Sì. Se l'impostazione DELAY è maggiore di zero, il template avvolge l'inizializzazione Smartsupp e l'iniezione dello script in setTimeout.

No, non ti serve un account sviluppatore TikTok solo per mostrare video. Il feed display si basa su URL video TikTok incollati e sull'endpoint pubblico oEmbed di TikTok. Nelle impostazioni del modulo, inserisci lo username TikTok per il link follow, incolla un URL video TikTok per riga nel campo Video URLs e salva.

Quando il feed viene costruito, il modulo divide la lista URL salvata per riga, salta le voci che non contengono tiktok.com, chiama https://www.tiktok.com/oembed?url=... e salva titolo, caption, autore, thumbnail ed embed HTML restituiti per la visualizzazione. Quel percorso display non usa token API, app review o credenziali sviluppatore.

Le credenziali sono rilevanti solo per il workflow opzionale di pubblicazione. La fonte ha impostazioni publishing come ACCESS_TOKEN, CLIENT_KEY, AUTOPUBLISH e AUTOPUBLISH_CAPTION, e usa un'istanza TikTok publisher per quel percorso. Se il tuo obiettivo è solo incorporare video TikTok selezionati nel negozio, puoi lasciare vuote quelle credenziali publishing.

Il modulo display ha come predefinito abilitato, con toggle caption, view-icon e like-icon attivi, mentre i default feed condivisi usano displayHome, 6 post, 3 colonne desktop, layout grid, lazy loading e durata cache 3600 secondi. Il feed renderizza solo nell'hook social-feed configurato; se l'hook configurato non corrisponde all'hook corrente, non viene emesso nulla.

Ci sono due casi limite pratici: URL senza tiktok.com vengono saltati, e ogni richiesta oEmbed fallita viene saltata invece di renderizzare una card rotta. La card storefront collega all'URL TikTok originale e mostra thumbnail, autore e caption restituiti, quindi video eliminati/privati o risposte oEmbed bloccate ridurranno semplicemente il feed.

VIDEO_URLS=https://www.tiktok.com/@brand/video/1234567890 USERNAME=brand SHOW_CAPTION=1 POST_COUNT=6

Sì. Il trait chat condiviso controlla l'impostazione mobile prima del rendering e non restituisce alcun pulsante quando la visualizzazione mobile è disattivata per un visitatore mobile.

No, il modulo non gestisce agenti, storico conversazioni o workflow di supporto. WhatsApp stesso gestisce la conversazione, mentre il modulo gestisce il pulsante storefront e l'URL click-to-chat. Questo mantiene l'integrazione leggera e chiara.

L'unico campo di connessione richiesto è PHONE. Deve contenere solo cifre, da 7 a 20 caratteri, includere il prefisso paese e non avere segni più o spazi. Il template front costruisce https://wa.me/{phone}, e se è configurato un messaggio aggiunge ?text=... per farlo precompilare da WhatsApp.

• Cosa controlla PrestaShop: abilita/disabilita, numero di telefono, messaggio precompilato opzionale, posizione, stile icona/barra, testo CTA, colore, dimensione, margine, tooltip, animazione, visibilità mobile, ritardo di visualizzazione e filtro pagina.
• Cosa controlla WhatsApp: il thread chat reale, risposte, assegnazione staff, storico messaggi, notifiche e qualsiasi funzione inbox o CRM.

Il messaggio opzionale supporta {product} sulle pagine prodotto e {url} per la pagina corrente, cosa utile per domande sui prodotti. Resta comunque solo un messaggio WhatsApp precompilato, non un ticket o un record supporto PrestaShop salvato.

Il modulo sostituisce {url} con l'URL della pagina corrente. Nelle pagine prodotto può anche sostituire {product} con il nome del prodotto corrente.

Il modulo può renderizzare dal hook footer o before-body, ma un flag statico interno evita output duplicato. L'ambito pagina può essere tutte le pagine, pagine prodotto, pagine categoria o pagine relative al checkout.

Aggiungi il codice invito Discord nella configurazione del modulo e abilita il widget. In PrestaShop il modulo renderizza un pulsante front-office collegato a discord.gg con il codice invito salvato, posizione configurabile, stile, testo CTA, colore, dimensione, tooltip, animazione e margine.

Usa solo il codice invito, non l'URL completo. Il validator required-config si aspetta lettere, numeri, trattini e underscore, da 2 a 64 caratteri. Un codice invito mancante impedisce il rendering; un codice salvato non valido viene segnalato dall'avviso configurazione e può produrre un link Discord errato.

INVITE_CODE=AbCdEfG123 ENABLED=1 STYLE=icon POSITION=bottom-right CTA_TEXT=Join our Discord

All'installazione i default impostano già il widget come abilitato, basso-destra, stile icona, blu Discord #5865F2, dimensione 60px, margine 20px, tooltip abilitato, animazione pulse, mobile abilitato, tutte le pagine e nessun ritardo. Il pannello configurazione admin consiglia di creare un invito permanente e un canale supporto dedicato, perché il modulo manda gli acquirenti al flusso di ingresso server invece di gestire conversazioni Discord dentro PrestaShop.

Sì, il widget può essere limitato per tipo pagina. In PrestaShop il guard chat condiviso supporta tutte le pagine, pagine prodotto, pagine categoria o controller collegati al checkout, e controlla anche l'impostazione separata di visibilità mobile prima del rendering.

Il filtro pagina è salvato nell'impostazione condivisa PAGES. Il guard restituisce true per all, controlla php_self=product per pagine prodotto, php_self=category per pagine categoria e tratta cart, order, order-opc, orderopc e checkout come controller collegati al checkout.

Lo stesso guard richiede anche ENABLED e un INVITE_CODE non vuoto, e nasconde il widget su mobile quando SHOW_MOBILE è off. Questo significa che il targeting pagina non è uno snippet separato da incollare nel tema; fa parte della decisione di rendering del modulo prima che CSS e pulsante vengano emessi.

PAGES=product SHOW_MOBILE=1 DELAY=0

Sì, il modulo ha un'impostazione di ritardo per il pulsante storefront. In PrestaShop il template hook scrive un valore data-delay e un piccolo script nasconde il widget, poi lo mostra dopo i secondi configurati.

No, il modulo non invia testo precompilato dentro Discord. L'impostazione di connessione richiesta è un codice invito, non un token API utente/messaggio, e il template storefront renderizza un link a https://discord.gg/{invite_code}.

Il campo admin Pre-filled Message viene salvato per riferimento e il modulo può sostituire internamente {url} prima di assegnare dati al template, ma il template storefront attuale non emette quel messaggio né lo aggiunge all'URL invito Discord.

Questo è diverso dalle piattaforme chat che supportano parametri URL per una conversazione precompilata. I link invito Discord portano l'acquirente a un flusso di invito/accesso server, quindi la configurazione pratica è creare un link invito permanente e indirizzare i clienti a un canale supporto dopo l'ingresso.

La fonte conferma questa separazione. Il form connessione admin etichetta il campo come Pre-filled Message, ma la sua descrizione dice che non è usato per gli inviti Discord ed è salvato per riferimento. Nell'hook, il modulo sostituisce {url} dentro il messaggio salvato prima di assegnare dati Smarty, ma il template usa solo invite_code, posizione/stile/CTA/aspetto, tooltip, animazione e ritardo.

Per i merchant, la configurazione affidabile è l'invito stesso: crea un codice invito stabile, evita che scada e usa regole server/canale Discord per guidare i clienti dopo l'ingresso. Non fare affidamento su questo modulo per aprire un DM Discord diretto, postare in un canale o passare un messaggio checkout/prodotto a Discord.

No, è un modulo di navigazione lingua. Aiuta gli acquirenti a passare tra lingue che già gestisci e li indirizza a URL localizzati dove PrestaShop ha i dati. Qualità della traduzione, targeting paese e logica di geolocalizzazione visitatore restano fuori da questo modulo.

Il modulo legge le lingue PrestaShop attive per il negozio corrente con Language::getLanguages(true, shop_id). Se il negozio ha una sola lingua attiva, non restituisce alcun selettore. Per ogni lingua mappa l'ISO lingua a una flag SVG quando esiste, costruisce un URL lingua dagli URL alternative-language del front controller quando disponibili e ripiega su getLanguageLink() di PrestaShop.

• Navigazione: l'output desktop nasconde il selettore lingua desktop nativo e renderizza un dropdown bandiere in displayNav2; l'output mobile può renderizzare una select semplice in displayMobileLanguageSelector.
• Etichette: SHOW_LABEL controlla se il codice ISO corrente viene mostrato accanto alla bandiera, e SHOW_NAMES controlla se i nomi lingua completi vengono mostrati nel dropdown. I default sono label off e nomi on.
• Limiti: non traduce nomi/descrizioni prodotto, non sceglie lingue da geolocalizzazione, non reindirizza visitatori per paese e non crea URL localizzati mancanti.

C'è una pulizia URL extra per alias di pagine core e un hook di integrazione per percorsi filtro tradotti di MPR Filter Revolution, ma anche questo dipende da route/dati tradotti già esistenti. È uno switcher, non un motore di traduzione.

Registra displayHeader, displayOrderConfirmation, actionCustomerAccountAdd e actionValidateOrder.

No. Il template di conferma ordine e il server conversion builder usano l'evento Pinterest checkout per gli ordini completati, includendo valore ordine, quantità, valuta, ID ordine ed event ID.

CAPI_ENABLED deve essere attivo, il Pinterest ad account ID deve contenere solo cifre e l'access token non deve essere vuoto. Il batch limit deve essere tra 1 e 100.

Sì, quando una custom rule ha capi abilitato. Il front conversion bridge mappa i nomi evento browser noti e accetta anche nomi evento CAPI personalizzati configurati.

I valori predefiniti di installazione impostano ENABLED a 0 e USERNAME a una stringa vuota. L'hook di rendering esce in anticipo se il modulo non è abilitato o non esiste uno username.

No, apre il tuo profilo Snapchat tramite lo username configurato. Contenuti profilo e conversazioni restano dentro Snapchat stesso. Questo mantiene il modulo focalizzato sull'offrire agli acquirenti un percorso pulito per seguirti o contattarti senza aggiungere un feed social pesante alla pagina.

L'output storefront è un pulsante flottante renderizzato dall'hook displayBeforeBodyClosingTag. L'hook si ferma prima del rendering se il pulsante Snapchat non è abilitato, se il valore USERNAME è vuoto, se la visualizzazione mobile è disabilitata per un visitatore mobile o se il controller corrente è elencato in EXCLUDE_PAGES. Quando renderizza, la destinazione è costruita come https://www.snapchat.com/add/ più lo username URL-encoded.

Il template conferma che si tratta di un link normale, non di un embed Snapchat. Emette un tag <a> con l'URL configurato, target=_blank opzionale, testo tooltip, stile pulsante, animazione e messaggio grabber opzionale. Non c'è iframe, chiamata API Snapchat, renderer feed o codice che legga conversazioni o contenuti profilo da Snapchat.

Required for output: ENABLED=1
Required account value: USERNAME=yourbrand
Rendered link: https://www.snapchat.com/add/yourbrand

Per i merchant, questo significa che il modulo ha basso impatto: offre ai visitatori un percorso visibile verso la tua presenza Snapchat lasciando contenuti Snapchat, follow, messaggi e privacy account sotto l'app e il sito Snapchat.

La definizione di configurazione elenca small, medium e large, etichettati come 48px, 60px e 72px. La dimensione selezionata viene passata alla classe widget come mprchat-size-....

No. Questo modulo renderizza un link flottante a un profilo Snapchat. Snapchat Pixel e il tracking degli eventi pubblicitari sono gestiti da un modulo diverso in questo batch.

Quando le wishlist ospite sono abilitate, lo script front salva gli ID prodotto nel localStorage del browser e restituisce risposte in modalità ospite per le azioni di aggiunta e rimozione. Lo storage da loggati usa le tabelle database del modulo.

La configurazione JavaScript marca il cliente come loggato e l'azione di sincronizzazione può inviare gli elementi localStorage al server, così vengono aggiunti alla wishlist predefinita del cliente.

Le wishlist nel database hanno un token di 32 caratteri. La vista front può caricare i prodotti per token, e il template tratta il proprietario loggato in modo diverso da un visitatore che visualizza una wishlist condivisa.

Quando un cliente loggato salva un prodotto, il modulo memorizza il prezzo al momento dell'aggiunta. L'elenco prodotti confronta quel prezzo salvato con il prezzo attuale del prodotto e segnala un calo quando il prezzo attuale è più basso.

No. Questo modulo è principalmente un tracker automation Brevo e sync registrazione cliente, non una integrazione completa di eventi carrello/ordine/prodotto.

• Gestisce: displayBeforeBodyClosingTag carica lo script automation Brevo, chiama la funzione page-tracking e identifica il visitatore per email quando un cliente è loggato. actionCustomerAccountAdd può creare o aggiornare il nuovo cliente come contatto Brevo quando auto-subscribe è abilitato.
• Non gestisce: aggiornamenti carrello, payload product-view, eventi acquisto su conferma ordine, eventi abandoned-cart o eventi stato ordine. Il modulo non registra hook carrello, ordine o prodotto per queste azioni.

Se ti servono abbandono carrello, ricavi da acquisto o automazione del comportamento prodotto in Brevo, questo modulo richiederebbe hook evento aggiuntivi o un'integrazione separata che invii quegli eventi Brevo specifici.

La lista hook è il limite importante: il modulo registra solo displayBeforeBodyClosingTag e actionCustomerAccountAdd. Il template storefront crea window.sib, carica https://sibautomation.com/sa.js?key=..., mette in coda le funzioni standard Brevo e chiama window.sendinblue.page(). Se un cliente è loggato, chiama anche window.sendinblue.identify() con l'indirizzo email. In quel payload browser non vengono aggiunti ID prodotto, righe carrello, riferimenti ordine, totali o stati ordine.

Alla creazione account, il modulo posta all'endpoint contatti Brevo con l'email del cliente, FIRSTNAME, LASTNAME, updateEnabled=true e il LIST_ID configurato quando salvato. È utile per crescita lista e automazione base di ingresso, ma è separato dal tracciamento eventi ecommerce.

Registered hooks: displayBeforeBodyClosingTag, actionCustomerAccountAdd
Contact API: POST https://api.brevo.com/v3/contacts
Tracked browser event here: page view, plus logged-in email identify
Not present here: cart payload, purchase payload, abandoned cart event

Abilita il modulo, aggiungi una Brevo API key e mantieni abilitata la sincronizzazione automatica delle registrazioni. Quando PrestaShop crea un account cliente, l'hook actionCustomerAccountAdd invia email più attributi FIRSTNAME e LASTNAME a Brevo, e include il list ID configurato quando salvato.

Le impostazioni rilevanti sono ENABLED, API_KEY, LIST_ID e AUTO_SUBSCRIBE. All'installazione, il modulo parte con ENABLED=0, API key vuota, list ID vuoto, tracker client key vuota e AUTO_SUBSCRIBE=1. Quindi la configurazione abituale è: attiva Brevo, incolla la API key da Brevo, inserisci opzionalmente il list ID numerico per i nuovi contatti e lascia abilitato Auto-subscribe New Customers.

La sincronizzazione gira solo alla creazione di un nuovo account cliente perché il modulo ascolta actionCustomerAccountAdd. Prima controlla che il modulo sia attivo, che la API key esista, che auto-subscribe sia abilitato e che PrestaShop abbia fornito un oggetto newCustomer caricato. Se uno di questi controlli fallisce, ritorna senza inviare nulla a Brevo.

Quando invia, il modulo posta JSON a https://api.brevo.com/v3/contacts con timeout cURL di 10 secondi e verifica peer SSL abilitata. Imposta updateEnabled a true, quindi un contatto Brevo esistente può essere aggiornato invece di causare un errore da contatto duplicato. Questa versione della fonte non importa in bulk i clienti esistenti e non sincronizza modifiche profilo successive salvo che PrestaShop crei un nuovo account tramite quell'hook.

Required: ENABLED=1, API_KEY set, AUTO_SUBSCRIBE=1
Optional: LIST_ID=123
Sent fields: email, FIRSTNAME, LASTNAME, listIds when configured

Sì. L'hook storefront carica il tracker automation Brevo solo quando il modulo è abilitato, la Brevo API Key è configurata e la Client Key è configurata. Il campo Client Key nelle impostazioni del modulo è etichettato Client Key (Tracker), e l'hint sorgente indirizza i merchant a Brevo > Automation > Settings > Tracking Code.

Per confermare che il tracker è caricato, apri il sorgente storefront o gli strumenti sviluppatore del browser e cerca https://sibautomation.com/sa.js?key=... con script id sendinblue-js. Il template inizializza window.sib.client_key, mette in coda sendinblue.track, sendinblue.identify, sendinblue.trackLink e sendinblue.page, identifica i clienti loggati per email, poi chiama window.sendinblue.page().

Se non vedi quello script, controlla prima interruttore modulo abilitato, API Key e Client Key. L'hook restituisce una stringa vuota quando manca uno qualsiasi di questi prerequisiti.

Il requisito API key conta anche se il tracker browser usa la Client Key. In questo modulo, isActive() è condiviso dall'hook tracker e controlla sia ENABLED sia API_KEY; poi l'hook controlla separatamente CLIENT_KEY. Un negozio con solo la Client Key salvata quindi non emetterà comunque nulla finché non viene configurata anche la API key.

Required for tracker output:
ENABLED=1
API_KEY=xkeysib-...
CLIENT_KEY=Brevo automation tracker key

L'output tracker è limitato allo script automation Brevo, page tracking e identificazione email loggata. In questa versione della fonte non aggiunge contenuti carrello, totali ordine, metadati prodotto o eventi acquisto.

Sì, la sincronizzazione automatica delle registrazioni può essere disabilitata dalla configurazione del modulo. L'hook PrestaShop actionCustomerAccountAdd controlla lo switch AUTO_SUBSCRIBE prima di inviare un nuovo cliente a Brevo, quindi il modulo può restare installato mentre la sincronizzazione registrazioni è disattivata.

L'impostazione è etichettata Auto-subscribe New Customers nelle opzioni del modulo. Il suo default è abilitato su una nuova installazione, ma l'hook lo controlla ogni volta che PrestaShop crea un account cliente. Quando AUTO_SUBSCRIBE è off, l'hook esce prima di validare l'oggetto nuovo cliente o chiamare la Brevo contacts API.

Disabilitare questo switch ferma solo la sincronizzazione registrazione-contatto. Non disinstalla il modulo, non rimuove credenziali API salvate e non disabilita automaticamente il tracker automation storefront. Se ENABLED, API_KEY e CLIENT_KEY sono ancora configurati, l'hook tracker può ancora caricare lo script Brevo e chiamare la funzione page-tracking.

Inoltre non disiscrive o elimina contatti già creati in Brevo. Semplicemente impedisce a questo modulo di inviare future creazioni contatto da nuovi account finché lo switch resta off.

AUTO_SUBSCRIBE=1: new customer can be posted to Brevo contacts
AUTO_SUBSCRIBE=0: actionCustomerAccountAdd returns before syncContactToBrevo()

Puoi aggiungere Crisp chat a PrestaShop inserendo il tuo Crisp Website ID e abilitando il modulo. L'avviso di configurazione del modulo si aspetta il Website ID in formato UUID, ma il modulo richiede solo che il campo non sia vuoto; non impone il pattern UUID esatto al salvataggio o alla visualizzazione del widget. In pratica dovresti comunque incollare il vero Website ID in formato UUID da Crisp, perché un valore arbitrario non vuoto può essere salvato e renderizzato ma potrebbe non caricare un widget funzionante.

All'installazione, il modulo Crisp crea default chat con ENABLED=1, WEBSITE_ID vuoto, SHOW_MOBILE=1, PAGES=all, DELAY=0 e PASS_USER_DATA=1. Poiché il Website ID parte vuoto, il modulo può essere installato con successo ma il widget resta inattivo finché quell'ID non viene salvato.

L'avviso required-configuration si aspetta formato UUID, per esempio xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx. L'aiuto configurazione punta a Crisp sotto Settings > Website Settings > Setup instructions. Una volta salvato un valore non vuoto, lo storefront applica comunque le stesse regole di visualizzazione, quindi il widget rispetta lo switch enabled, un Website ID non vuoto, l'impostazione mobile e il targeting pagina.

Quando queste regole sono soddisfatte, il template imposta window.CRISP_WEBSITE_ID, opzionalmente inserisce dati email/nome del cliente loggato e aggiunge https://client.crisp.chat/l.js in modo asincrono nell'head della pagina.

Minimum setup:
Enable Crisp Chat = Yes
Website ID = UUID from Crisp
Show on Pages = All Pages, Product Pages, Category Pages or Checkout Pages

Sì, Crisp chat può essere limitata per tipo pagina PrestaShop. Il guard chat condiviso supporta tutte le pagine, pagine prodotto, pagine categoria o controller checkout, inclusi cart, order, order-opc, orderopc e checkout, prima di emettere lo script Crisp.

L'impostazione è il campo select condiviso Show on Pages. I valori salvati supportati sono all, product, category e checkout. Il default del modulo è all, quindi una nuova installazione con Website ID valido sarà idonea a mostrarsi su ogni pagina storefront salvo modifica del merchant.

La corrispondenza pagina usa il controller corrente PrestaShop php_self. La modalità solo prodotto corrisponde esattamente a product, solo categoria corrisponde esattamente a category, e checkout corrisponde a cart, order, order-opc, orderopc o checkout. Lo switch mobile viene controllato separatamente, quindi una pagina può corrispondere alla regola pagina e restare comunque nascosta su mobile se SHOW_MOBILE è off.

Show on Pages = all       -> every page
Show on Pages = product   -> product controller only
Show on Pages = category  -> category controller only
Show on Pages = checkout  -> cart/order checkout controllers

Se in PAGES è salvato un valore inatteso, il ramo default del guard condiviso consente la pagina invece di bloccarla. Per un targeting prevedibile, usa uno dei quattro valori esposti dal form.

Sì, ma solo quando il passaggio dati cliente è abilitato e l'acquirente è loggato. L'impostazione è lo switch Pass Customer Data nella configurazione del modulo Crisp; impostalo su No per impedire al modulo di inviare dati identità cliente loggato a Crisp.

• Quando PASS_USER_DATA è off, l'helper chat condiviso restituisce campi cliente vuoti.
• Quando è on e il cliente è loggato, l'helper restituisce l'email del cliente e nome più cognome del cliente.
• Il template Crisp li invia come user:email e user:nickname prima di caricare https://client.crisp.chat/l.js.

I visitatori anonimi ricevono comunque il widget Crisp quando Website ID e regole display lo consentono, ma nessuna email o nome cliente PrestaShop viene passato perché non c'è un oggetto cliente loggato.

Su una nuova installazione, PASS_USER_DATA ha come predefinito 1, quindi i merchant che non vogliono questo passaggio dati dovrebbero disattivare deliberatamente lo switch. L'helper espone al template solo due valori: customer_email e customer_name. Non include dati indirizzo, numeri telefono, contenuti carrello, storico ordini o ID cliente PrestaShop.

Anche l'hook Crisp deve prima soddisfare le normali regole di visualizzazione del modulo. Se il modulo è disabilitato, il Website ID manca, la visualizzazione mobile è bloccata o la regola pagina non corrisponde, il template non viene renderizzato e nessun dato cliente viene inviato a Crisp.

PASS_USER_DATA=1 + logged-in customer: email and first name + last name can be pushed
PASS_USER_DATA=0 or anonymous visitor: customer_email and customer_name stay empty

Sì, lo script Crisp può essere ritardato di un numero di secondi configurato. L'attuale template hook PrestaShop avvolge il loader Crisp in setTimeout quando il ritardo è superiore a zero; non attende scroll, click, touch o altra interazione utente.

L'impostazione salvata è DELAY, mostrata nel form condiviso come Fallback Delay (seconds). Nel modulo Crisp attuale, l'hook passa quel valore al template come intero. Se il valore è maggiore di zero, il template avvolge tutto il blocco di setup Crisp e append script in setTimeout(..., DELAY * 1000).

Un valore 0 significa che il template non aggiunge un wrapper timeout, quindi il setup Crisp gira subito quando l'output hook viene parsato. Anche se la descrizione del campo condiviso menziona prima interazione utente e fallback, questo template Crisp implementa solo il comportamento timer descritto sopra.

DELAY=0  -> no setTimeout wrapper; load immediately
DELAY=5  -> run Crisp setup after 5 seconds
DELAY=15 -> run Crisp setup after 15 seconds

Il ritardo non bypassa la normale catena di guard. Il modulo deve comunque essere abilitato, il Website ID deve essere presente, la visualizzazione mobile deve essere consentita per visitatori mobile e la regola targeting pagina deve corrispondere prima che qualsiasi script ritardato venga stampato.

Sì. Configura gli ID prodotto esclusi nell'impostazione lista prodotti del modulo, per esempio come lista separata da virgole. L'override rimuove i prodotti esclusi dal pacchetto passato al calcolo cart-rule di PrestaShop, quindi gli sconti monetari vengono calcolati solo sui prodotti idonei.

Excluded product IDs: 42,108,315
Cart: #42 $100 excluded + #77 $50 eligible
Voucher: 20% off products
Before exclusion: 20% of $150 = $30 discount
After exclusion: 20% of $50 = $10 discount; #42 stays at full price

La stessa lista di esclusione può essere combinata con esclusioni categoria e produttore perché il modulo unisce tutte e tre le fonti in un unico set di prodotti esclusi. Gli sconti percentuali si applicano solo ai prodotti idonei. Le riduzioni a importo fisso vengono ripartite tramite il pacchetto filtrato, mentre spedizione gratuita e comportamento regalo sono lasciati alla normale gestione cart-rule di PrestaShop.

L'impostazione lista prodotti è salvata come PRODUCTS. Il resolver legge il valore separato da virgole, converte ogni voce con intval, rimuove valori zero vuoti e poi unisce quegli ID con ID derivati da categorie e produttori. La lista finale viene messa in cache per la richiesta PHP corrente, evitando di ripetere le query categoria e produttore durante lo stesso calcolo carrello.

L'override CartRule cambia solo regole con una riduzione monetaria: reduction_percent maggiore di zero o reduction_amount maggiore di zero. Se il modulo non è abilitato, se la lista esclusioni configurata risolve vuota o se il pacchetto cart-rule corrente non contiene prodotti esclusi, delega invariato al calcolo parent di PrestaShop.

Poiché il filtro controlla id_product, l'esclusione si applica al prodotto nel suo insieme. Se un prodotto ha combinazioni, la fonte non distingue una combinazione attributi da un'altra in questo passaggio di esclusione.

Stored setting: PRODUCTS=42,108,315
Resolver output: [42,108,315,...category matches,...manufacturer matches]
Override input: package products
Override output: package products without excluded id_product values

Sì. Le esclusioni possono essere inserite come ID prodotto diretti, ID categoria e ID produttore. I campi configurazione admin sono liste separate da virgole, e il resolver li converte in una lista finale di ID prodotto prima del calcolo sconto.

PRODUCTS=12,15
CATEGORIES=3,7
MANUFACTURERS=1,4

Con quella configurazione, i prodotti 12 e 15 sono esclusi direttamente. Il modulo interroga anche category_product per ogni prodotto assegnato alle categorie 3 o 7, e interroga product per ogni prodotto il cui id_manufacturer è 1 o 4. Unisce quegli ID, rimuove duplicati con array_unique e mette in cache il risultato per la richiesta corrente.

L'override CartRule chiede poi al modulo quella lista prodotti risolta e filtra i prodotti esclusi dal pacchetto prima che lo sconto cart-rule parent venga calcolato. In termini merchant: i prodotti corrispondenti restano a prezzo pieno, mentre il resto del carrello può comunque ricevere lo sconto voucher.

La regola categoria si basa sugli ID categoria esatti salvati in CATEGORIES. La query fonte legge righe da category_product dove id_category è in quella lista; non percorre l'albero categoria in PHP. Se un negozio deve escludere anche tutte le sottocategorie, quegli ID sottocategoria dovrebbero essere inclusi, salvo che i prodotti siano assegnati direttamente anche alla categoria padre elencata.

La regola produttore si basa su product.id_manufacturer. Come per i prodotti diretti, l'esclusione finale è per id_product, quindi tutte le combinazioni di un prodotto corrispondente sono trattate come escluse. Le voci di testo non valide sono di fatto ridotte tramite casting a intero; valori vuoti e zero non contribuiscono ID prodotto utili.

Category source: ps_category_product.id_category IN saved category IDs
Manufacturer source: ps_product.id_manufacturer IN saved manufacturer IDs
Final discount filter: id_product not in resolved exclusion list

No, l'override punta alle riduzioni monetarie delle cart-rule, non al beneficio spedizione gratuita in sé. Se il modulo è disabilitato, non sono configurati prodotti esclusi o la regola carrello non ha riduzione percentuale o a importo fisso, l'override delega al normale calcolo CartRule di PrestaShop.

Esempio: un voucher offre 10% di sconto più spedizione gratuita, e il carrello contiene solo prodotti esclusi da questo modulo. Lo sconto prodotto diventa 0 perché ogni prodotto è escluso dalla riduzione monetaria, ma se la regola ha free_shipping e PrestaShop sta calcolando l'azione spedizione, l'override delega al calcolo spedizione parent così la parte spedizione gratuita può comunque applicarsi.

Per carrelli misti, il modulo filtra i prodotti esclusi prima del calcolo parent. Gli sconti percentuali si applicano solo ai prodotti idonei, e gli sconti a importo fisso sono calcolati da PrestaShop sul pacchetto filtrato.

Il fast path è importante per voucher solo spedizione gratuita. Quando una regola carrello non ha reduction_percent e non ha reduction_amount, l'override restituisce il risultato parent di PrestaShop senza filtrare il pacchetto. Questo significa che un voucher pura spedizione gratuita segue le normali condizioni voucher PrestaShop e non viene ridotto solo perché i prodotti sono nella lista esclusioni.

Quando tutti i prodotti sono esclusi e una regola combina uno sconto monetario con spedizione gratuita, l'override restituisce 0 per la parte monetaria salvo che il filtro corrente sia uno dei filtri action shipping/all di PrestaShop. Per quei filtri shipping/all chiama il calcolo parent con FILTER_ACTION_SHIPPING, che è la ragione a livello fonte per cui il beneficio spedizione può restare disponibile.

Un dettaglio pratico: l'avviso carrello opzionale è separato dalla matematica dello sconto. Il renderer avviso controlla se modulo e avviso sono abilitati, se il carrello ha regole carrello e se sono presenti prodotti esclusi. Non ispeziona se la regola carrello è monetaria o solo spedizione gratuita, quindi il messaggio può comunque essere informativo mentre PrestaShop gestisce normalmente la spedizione.

Sì, il modulo può mostrare un avviso carrello quando sono presenti prodotti esclusi. In PrestaShop l'avviso appare solo quando modulo e impostazione avviso sono abilitati, il carrello ha regole carrello e almeno un prodotto carrello corrisponde alla lista esclusioni.

La funzione avviso è abilitata di default all'installazione con SHOW_NOTICE=1. Il testo avviso multilingua predefinito è The following products are excluded from the applied discount:, e i merchant possono modificare NOTICE_TEXT dalle impostazioni modulo. Il modulo registra sia displayShoppingCart sia displayShoppingCartFooter; l'hook footer è mantenuto come alias di compatibilità per negozi che usano ancora il vecchio posizionamento hook.

Il renderer ha anche un guard duplicati. Una volta che un avviso è stato renderizzato durante la richiesta, $cartNoticeRendered impedisce allo stesso messaggio di apparire due volte se il tema esegue entrambi gli hook carrello.

Il modulo costruisce la lista nomi prodotto dai prodotti del carrello corrente il cui id_product appare nella lista esclusioni risolta. Se product_name non è disponibile ripiega su name, e poi su un'etichetta generica con numero prodotto. Il template effettua escape sia del testo avviso sia dei nomi prodotto prima dell'output.

Notice shown only if:
ENABLED=1
SHOW_NOTICE=1
cart has at least one cart rule
cart contains at least one resolved excluded product

Se non è applicato alcun voucher/cart rule, l'avviso è intenzionalmente nascosto anche se nel carrello ci sono prodotti esclusi. Questo mantiene il messaggio legato al momento in cui un cliente si aspetta uno sconto e potrebbe chiedersi perché alcuni articoli sono rimasti a prezzo pieno.

Il campo richiesto è il HubSpot Portal ID. L'avviso di configurazione obbligatoria del modulo resta attivo finché il campo è vuoto.

Il template HubSpot esaminato identifica i clienti connessi tramite e-mail quando pass-user-data è attivo. Non invia da PHP dati di visitatori anonimi.

Il trait chat condiviso supporta tutte le pagine, le pagine prodotto, le pagine categoria o le pagine legate al checkout, come cart, order, order-opc, orderopc e checkout.

No. Il codice usa un timeout configurato in millisecondi prima di renderizzare il widget. È un ritardo temporale, non un loader attivato dall'interazione.