Segnala un problema - Segnalazioni dei clienti sulla scheda prodotto, link rotti e prezzi errati con pannello
Lascia che siano i clienti a dirti quando una scheda prodotto è sbagliata. Un discreto pulsante Segnala un problema apre una finestra in cui il visitatore sceglie il tipo — link rotto, prezzo errato, informazioni mancanti o altro — e lo descrive. Ogni segnalazione viene prima salvata nel tuo negozio e solo dopo inviata per email, così non perdi nulla se la posta non parte. Gestiscile da un pannello nel back office con filtri, azioni multiple ed esportazione CSV. Niente jQuery, nessun override. Per PrestaShop 1.7 fino a 9.
I tuoi clienti trovano le pagine rotte prima di te
Ogni catalogo si logora. Un link del fornitore smette di funzionare, un prezzo resta fermo alla stagione scorsa, una descrizione perde proprio il dettaglio che serve a chi compra. Chi se ne accorge sono i tuoi visitatori — e se non dai loro un modo per dirtelo, semplicemente se ne vanno.
Questo modulo mette un discreto pulsante Segnala un problema su ogni scheda prodotto. Un clic apre una finestra, il visitatore spiega in una frase che cosa non va, e la segnalazione arriva nel tuo back office.
Quattro tipi di problema e una frase
Il visitatore sceglie tra link rotto, prezzo errato, informazioni mancanti e altro — sei tu a decidere quali dei quattro proporre — e scrive una breve descrizione, tra 10 e 1000 caratteri, con un contatore che si aggiorna mentre digita.
Nome ed email sono facoltativi e vengono mostrati solo agli ospiti; i clienti registrati sono identificati dal loro account. L'indirizzo email serve a una cosa sola: avvisare chi ha segnalato che il problema è stato risolto.
Prima salvata, poi inviata per email — ed è tutto qui il punto
La segnalazione viene scritta nel tuo database prima che venga tentato qualsiasi invio. Se il tuo server di posta ha una giornata storta, la segnalazione resta comunque nella tua lista. L'errore finisce nei log invece che davanti agli occhi del visitatore.
È questo ordine la ragione per cui esiste la versione 4. Continua a leggere.
Un back office che è un vero flusso di lavoro
Le segnalazioni arrivano in un elenco che puoi smaltire con ordine. Filtra per stato, tipo di problema, categoria, intervallo di date e testo libero su messaggio, nome ed email. Selezionane più di una e segnala in lavorazione, risolta, come spam oppure eliminala in un'unica azione.
Ogni riga si espande e mostra il messaggio completo, il prodotto — con i link sia alla pagina in vetrina sia alla sua scheda in modifica — chi ha segnalato, le date, un selettore di stato e un campo note per la tua risposta. Le segnalazioni passano per aperta, in lavorazione, risolta, duplicata e spam.
L'esportazione in CSV ti restituisce esattamente ciò che i filtri stanno selezionando in quel momento, non l'intera tabella.
Numeri che ti dicono dove sono i problemi
Un pannello In sintesi conta ciò che è in attesa, ciò che è arrivato questa settimana e questo mese, ciò che hai risolto e ciò che era spam — e ogni cifra è cliccabile e porta direttamente all'elenco già filtrato. Accanto trovi i tuoi cinque prodotti più segnalati, che di solito è la strada più rapida verso la pagina che ha davvero bisogno di essere sistemata.
Un widget nella home della Dashboard mostra quante segnalazioni sono in attesa, e sparisce del tutto quando non ce n'è nessuna.
Avvisa chi ha segnalato che hai risolto
Quando imposti una segnalazione su Risolta, una casella da spuntare invia un'email a chi l'ha inviata. Parte solo se ha lasciato un indirizzo, e la tua nota entra nel messaggio. Non costa nulla ed è la parte che i clienti si ricordano.
Protezione antispam che non punisce le persone vere
Un campo trappola (honeypot), un tempo minimo di compilazione e un token firmato con HMAC e a scadenza sono sempre attivi e non richiedono alcuna configurazione. Il token dura due ore ed è legato al prodotto, quindi non può essere riutilizzato altrove nel catalogo.
Oltre a questo: un limite orario per visitatore e per prodotto (1 di default, 0 per disattivarlo) con sopra un tetto globale fisso di 10 segnalazioni all'ora per visitatore. La deduplicazione archivia come Duplicata la stessa persona che segnala lo stesso problema sullo stesso prodotto entro 24 ore, invece di avvisarti due volte — e restano comunque tutte nell'elenco.
Il reCAPTCHA v3 opzionale è disponibile ed è disattivato di default. Carica codice di Google sulle tue schede prodotto, quindi se lo attivi ricordati di menzionarlo nell'informativa privacy.
L'indirizzo IP di chi segnala non viene mai memorizzato
Il limite di frequenza deve pur riconoscere un visitatore che torna, perciò il modulo salva hash_hmac('sha256', $ip, _COOKIE_KEY_) — un hash con chiave basata sul segreto del tuo negozio — e mai l'indirizzo in sé.
È la chiave a fare la differenza. Uno SHA-256 senza chiave di un indirizzo IP si può invertire in pochi minuti calcolando l'hash di tutti e quattro i miliardi di indirizzi IPv4; con una chiave che conosce solo il tuo negozio, no. La suite di test del modulo lo verifica in modo esplicito.
Le segnalazioni vengono eliminate quando viene eliminato il loro prodotto, e tutte quante quando disinstalli. Se il modulo ufficiale GDPR psgdpr è installato e attivo, il suo blocco di consenso viene inserito automaticamente nel form.
La versione 4 ha riparato un modulo che non consegnava una segnalazione dalla 3.1.0
Vale la pena dirlo senza giri di parole, perché è la vera ragione per aggiornare.
Quando l'endpoint di invio è stato spostato in controllers/front/ nella 3.1.0, il percorso del template email accanto a esso non è stato aggiornato, e finiva così per puntare a una cartella che non esiste. Mail::Send() restituiva false, il modulo rispondeva die('0') — e siccome 0 è JSON valido, il front end lo interpretava ed eseguiva il gestore di successo.
Ogni negozio dalla 3.1.0 alla 3.2.2 buttava via le segnalazioni dei clienti mentre li ringraziava per averle inviate. Quattro versioni pubblicate, e siccome non veniva salvato nulla, non c'era nulla da recuperare. Ora i percorsi email si risolvono da _PS_MODULE_DIR_, e il salvataggio avviene prima dell'invio.
Ha anche chiuso un relay di posta aperto
La versione 3.x leggeva il destinatario delle notifiche da un campo nascosto nella pagina. Non veniva mai validato né confrontato con l'indirizzo del negozio, e finiva dritto in Mail::Send().
Qualsiasi visitatore anonimo poteva far spedire posta dal tuo negozio all'indirizzo che preferiva, con HTML non sanificato nel corpo, tutte le volte che voleva. A spese della tua reputazione come mittente. Ora il destinatario arriva dalla configurazione del modulo e da nessun'altra parte.
La secure_key che avrebbe dovuto impedirlo era md5(_COOKIE_KEY_ . 'reportbrokenlink') — costante per tutta la vita del negozio e stampata in ogni scheda prodotto. Letta una volta, riutilizzabile per sempre. Oggi è un token firmato con HMAC, a scadenza e legato al prodotto.
Anche quello che scrive il visitatore viene sanificato in uscita, non solo ripulito in entrata. PrestaShop sostituisce le variabili delle email con un semplice str_replace e non sanifica nulla, quindi una stringa non trattata permetterebbe a chi segnala di infilare un link di phishing in un'email che parte davvero dal tuo negozio.
Il front end si è liberato di jQuery 1.8.2 e di ogni altra dipendenza
La versione 3.x caricava jQuery 1.8.2 dalla CDN di Google su ogni scheda prodotto. Questo mandava l'IP di ogni visitatore a Google prima di qualsiasi consenso, serviva una libreria del 2012 con quattro avvisi di sicurezza pubblicati e sovrascriveva il jQuery del tuo tema per tutto ciò che veniva eseguito dopo.
Di tutto questo non è rimasto nulla. Il front end è JavaScript e CSS vanilla, senza dipendenze — un file piccolo per ciascuno, registrati solo sulle schede prodotto. Niente jQuery, niente Bootstrap.
Gli invii ora sono in POST. La versione 3.x li mandava in GET — per via di un'opzione post: "POST" che in jQuery non esiste, quindi usava silenziosamente il metodo di default — e questo finiva per mettere l'indirizzo email di chi segnalava nei log di accesso del tuo server web.
Accessibile perché è nato così
La finestra è una vera finestra di dialogo: il focus ci entra dentro, il tasto Tab resta intrappolato all'interno, Escape la chiude, e il focus torna al pulsante da cui sei partito. Gli errori vengono annunciati agli screen reader, gli indicatori di focus sono visibili, prefers-reduced-motion è rispettato e sotto i 480 px passa a schermo intero.
Inoltre, all'apertura viene spostata su <body>. Renderizzata dov'era, finiva dentro il <form> di aggiunta al carrello del tema — un form annidato che rompeva il layout e poteva inviare la cosa sbagliata.
Compatibilità
PrestaShop 1.7 fino a 9, PHP 7.2 - 8.3, e l'interfaccia del modulo in otto lingue: francese, inglese, italiano, olandese, polacco, spagnolo, tedesco e turco — quindi lavori in un back office in italiano.
Nessun override, nessuna modifica al core o al tema, niente jQuery. Cinque hook, una tabella nel database. La disinstallazione rimuove la tabella, tutte le segnalazioni salvate e tutte le impostazioni — quindi esporta prima in CSV se vuoi conservarle.
Domande frequenti
I miei clienti devono avere un account per segnalare qualcosa?
No, e conviene lasciare attive le segnalazioni degli ospiti: di solito sono proprio gli ospiti ad accorgersi di una pagina rotta. Se preferisci, con una sola impostazione puoi riservare il pulsante ai clienti registrati.
Dove compare il pulsante?
Sulle schede prodotto, accanto alle informazioni sul prodotto oppure sotto di esse — displayProductAdditionalInfo o displayFooterProduct (i due hook disponibili). Se il tuo tema ne nasconde uno, passa all'altro nelle impostazioni del modulo.
Cosa succede se il mio server di posta non funziona?
Non si perde nulla. La segnalazione viene salvata prima che venga tentato qualsiasi invio, l'errore finisce in Parametri avanzati → Log, e la segnalazione ti aspetta nell'elenco. È questa la differenza più grande rispetto alla versione 3.
Vengono memorizzati gli indirizzi IP di chi segnala?
No. Il limite di frequenza usa un hash SHA-256 con chiave basata sul segreto del tuo negozio, mai l'indirizzo in sé. Nome ed email sono facoltativi e vengono raccolti solo perché tu possa avvisare chi ha segnalato che il problema è risolto.
Un visitatore dice che il form gli ha risposto che era scaduto.
Il token firmato dura due ore, quindi chi ha lasciato aperta una scheda prodotto più a lungo vedrà questo messaggio. Basta ricaricare la pagina. I token sono legati al prodotto, ed è esattamente ciò che impedisce di riutilizzarli altrove nel tuo catalogo.
Perché alcune segnalazioni sono contrassegnate come Duplicate e non mi arrivano per email?
La deduplicazione è attiva di default: stessa persona, stesso prodotto, stesso tipo di problema entro 24 ore viene archiviata come duplicata invece di avvisarti due volte. Restano comunque tutte nell'elenco — filtra per stato Duplicata, oppure disattiva l'impostazione.
Posso portare le segnalazioni fuori da PrestaShop?
Sì. L'esportazione in CSV ti restituisce esattamente ciò che i filtri attuali selezionano. Le celle che iniziano con un carattere che un foglio di calcolo interpreterebbe come formula (=, +, -, @, tabulazione o ritorno a capo) vengono neutralizzate di proposito, così nessuno può infilare una formula di foglio di calcolo in un file che poi apri tu.
Servono jQuery o Bootstrap?
Né l'uno né l'altro. Il front end è JavaScript e CSS vanilla, un file piccolo per ciascuno, caricati solo sulle schede prodotto. Se stai cercando di capire perché un clic non fa nulla, controlla la console: spesso c'è un errore di codice estraneo nella pagina.
Cosa succede alle mie segnalazioni se disinstallo il modulo?
Vengono eliminate, insieme a tutte le impostazioni — ti viene chiesta prima una conferma. Esporta in CSV in anticipo se pensi che ti potranno servire.
-
CompatibilitàPrestashop 1.4
Prestashop 1.5
Prestashop 1.6
Prestashop 1.7
Prestashop 8
Prestashop 9 -
Traduzioni del Modulo DisponibiliFrancese
Inglese
Italiano
Olandese
Polacco
Spagnolo
Tedesco
Turco
MEG Venture
4 altri prodotti nella stessa categoria
| Versione | 4.0.0 |
|---|---|
| Ultimo aggiornamento | 2026-07-30 |
| Registro delle modifiche | - [2026-07-30] Backfill missing translation keys for issue reporting feature in multiple languages - [2026-07-25] Refactor report submission handling to use delegated event listeners and avoid nested forms - [2026-07-24] Add Turkish translations for report broken link module - [2026-07-23] Refactor code structure for improved readability and maintainability - [2026-07-23] Populate translation files with complete translatable strings - [2026-07-23] Populate translation files with complete translatable strings - [2026-07-23] Populate translation files with complete translatable strings - [2026-07-23] Add authentic translations for FR, DE, PL, NL, TR, IT, ES - [2026-07-23] Populate translation files with complete translatable strings - [2026-07-23] Populate translation files with complete translatable strings - [2026-07-23] Add missing translation files (fr, de, pl, nl, tr, it, es) - [2026-07-16] Refactor dashboard widget styling and update template for consistency with admin theme - [2026-07-15] Add report broken link module templates and functionality - [2026-07-15] Add README file for reportbrokenlink module - [2023-09-22] v3.2.2 - [2023-09-07] v3.2.1 - [2022-02-20] Update reportbrokenlink-extra.tpl - [2021-11-20] v3.2.0 - [2021-09-27] v3.1.0 - [2021-09-27] Initial commit |
• [2026-07-15] Add report broken link module templates and functionality
• [2026-07-15] Add README file for reportbrokenlink module
• [2023-09-22] v3.2.2
• [2023-09-07] v3.2.1
• [2022-02-20] Update reportbrokenlink-extra.tpl
• [2021-11-20] v3.2.0
• [2021-09-27] v3.1.0
• [2021-09-27] Initial commit
Commenti (1)
Non è stato possibile inviare il tuo giudizio sulla recensione
Segnala commento
Segnalazione inviata
Non è stato possibile inviare la tua segnalazione