Problem melden - Kundenfeedback zu Produktseiten, Meldungen zu defekten Links und falschen Preisen mit Back-Office-Dashboard

Ihre Kunden finden Ihre fehlerhaften Seiten vor Ihnen

Jeder Katalog veraltet mit der Zeit. Ein Lieferanten-Link stirbt, ein Preis stammt noch aus der letzten Saison, einer Beschreibung fehlt genau das eine Detail, das Käufer wirklich brauchen. Bemerken tun das Ihre Besucher — und wenn Sie ihnen keine Möglichkeit geben, es Ihnen zu sagen, gehen sie einfach.

Dieses Modul setzt einen dezenten Button Problem melden auf jede Produktseite. Ein Klick öffnet einen Dialog, der Besucher schreibt in einem Satz, was nicht stimmt, und die Meldung landet in Ihrem Back Office.

Vier Problemarten und ein Satz

Der Besucher wählt zwischen defektem Link, falschem Preis, fehlenden Angaben und Sonstiges — Sie entscheiden, welche der vier Sie anbieten — und schreibt eine kurze Beschreibung mit 10 bis 1000 Zeichen, mit einem Live-Zähler während der Eingabe.

Name und E-Mail-Adresse sind optional und werden nur Gästen angezeigt; angemeldete Kunden werden über ihr Konto identifiziert. Die E-Mail-Adresse dient genau einem Zweck: dem Melder mitzuteilen, dass Sie das Problem behoben haben.

Erst gespeichert, dann gemailt — und genau darum geht es

Die Meldung wird in Ihre Datenbank geschrieben, bevor überhaupt ein Mailversand versucht wird. Wenn Ihr Mailserver einen schlechten Tag hat, steht die Meldung trotzdem in Ihrer Liste. Der Fehler wird in Ihre Logs geschrieben, statt dem Besucher als Fehlermeldung angezeigt zu werden.

Diese Reihenfolge ist der Grund, warum es Version 4 gibt. Dazu weiter unten mehr.

Ein Back Office, das ein echter Arbeitsablauf ist

Meldungen laufen in einer Liste auf, die Sie abarbeiten können. Filtern Sie nach Status, Problemart, Kategorie, Zeitraum und im Freitext über Nachricht, Name und E-Mail-Adresse. Wählen Sie mehrere aus und setzen Sie sie in einem Schritt auf In Bearbeitung, Erledigt, Spam — oder löschen Sie sie.

Jede Zeile lässt sich aufklappen und zeigt die vollständige Nachricht, das Produkt — mit Links sowohl auf die Front-Office-Seite als auch auf den Editor —, den Melder, Zeitstempel, eine Statusauswahl und ein Notizfeld für Ihre Antwort. Meldungen durchlaufen die Status Offen, In Bearbeitung, Erledigt, Duplikat und Spam.

Der CSV-Export liefert Ihnen exakt das, was Ihre aktuellen Filter treffen, nicht die gesamte Tabelle.

Zahlen, die zeigen, wo die Probleme liegen

Ein Panel Auf einen Blick zählt, was offen ist, was diese Woche und diesen Monat eingegangen ist, was Sie erledigt haben und was Spam war — jeder Wert ist anklickbar und führt direkt in eine gefilterte Liste. Daneben stehen Ihre fünf am häufigsten gemeldeten Produkte, meist der schnellste Weg zu der Seite, die tatsächlich Aufmerksamkeit braucht.

Ein Widget auf der Dashboard-Startseite zeigt die Anzahl der wartenden Meldungen und blendet sich vollständig aus, wenn keine vorliegen.

Sagen Sie dem Melder, dass Sie es behoben haben

Wenn Sie eine Meldung auf Erledigt setzen, verschickt ein einziges Häkchen eine E-Mail an die Person, die sie eingereicht hat. Sie wird nur dann verschickt, wenn eine Adresse hinterlassen wurde, und Ihre Notiz geht mit in die Nachricht ein. Es kostet nichts und ist genau der Teil, an den sich Kunden erinnern.

Spam-Schutz, der echte Menschen nicht bestraft

Ein Honeypot-Feld, eine Mindestausfüllzeit und ein HMAC-signiertes, zeitlich begrenztes Token sind immer aktiv und brauchen keine Konfiguration. Das Token gilt zwei Stunden und ist an das Produkt gebunden, kann also nicht auf andere Seiten Ihres Katalogs übertragen werden.

Darüber hinaus: ein Stundenlimit pro Besucher und Produkt (Standard 1, mit 0 deaktivierbar) sowie zusätzlich eine feste Obergrenze von 10 Meldungen pro Stunde und Besucher. Die Duplikaterkennung legt dieselbe Meldung derselben Person zum selben Produkt innerhalb von 24 Stunden als Duplikat ab, statt Sie zweimal zu benachrichtigen — in der Liste stehen sie weiterhin alle.

Optionales reCAPTCHA v3 steht bereit und ist standardmäßig deaktiviert. Es lädt Google-Code auf Ihren Produktseiten, erwähnen Sie es also in Ihrer Datenschutzerklärung, wenn Sie es einschalten.

Die IP-Adresse des Melders wird nie gespeichert

Eine Ratenbegrenzung muss wiederkehrende Besucher erkennen, deshalb speichert das Modul hash_hmac('sha256', $ip, _COOKIE_KEY_) — einen mit dem eigenen Geheimnis Ihres Shops verschlüsselten Hash — und niemals die Adresse selbst.

Auf die Schlüsselung kommt es an. Ein ungeschlüsselter SHA-256-Hash einer IP-Adresse lässt sich in Minuten zurückrechnen, indem man alle vier Milliarden IPv4-Adressen durchhasht; mit einem Geheimnis geschlüsselt, das nur Ihr Shop kennt, geht das nicht. Die eigene Testsuite des Moduls prüft genau das explizit ab.

Meldungen werden gelöscht, wenn ihr Produkt gelöscht wird, und alle zusammen bei der Deinstallation. Ist das offizielle DSGVO-Modul psgdpr installiert und aktiviert, wird dessen Einwilligungsblock automatisch im Formular ausgegeben.

Version 4 hat ein Modul repariert, das seit 3.1.0 keine einzige Meldung mehr zugestellt hat

Das gehört klar gesagt, denn es ist der eigentliche Grund für ein Update.

Als der Endpunkt für die Übermittlung in 3.1.0 nach controllers/front/ umzog, wurde der danebenliegende Pfad zur Mailvorlage nicht mitgezogen — er zeigte auf ein Verzeichnis, das nicht existiert. Mail::Send() lieferte false zurück, das Modul antwortete mit die('0') — und weil 0 gültiges JSON ist, hat das Frontend es geparst und den Erfolgs-Handler ausgeführt.

Jeder Shop mit 3.1.0 bis 3.2.2 hat Kundenmeldungen verworfen und sich beim Melder dafür bedankt. Vier veröffentlichte Versionen lang, und gespeichert wurde nichts — es gab also auch nichts wiederherzustellen. Mailpfade werden jetzt aus _PS_MODULE_DIR_ aufgelöst, und gespeichert wird vor dem Versand.

Außerdem wurde ein offenes Mail-Relay geschlossen

Version 3.x las den Empfänger der Benachrichtigung aus einem versteckten Feld in der Seite. Er wurde nie validiert, nie mit der Adresse des Shops abgeglichen und dann direkt an Mail::Send() übergeben.

Jeder anonyme Besucher konnte Ihren Shop dazu bringen, Mails an eine beliebige Adresse seiner Wahl zu verschicken, mit nicht escaptem HTML im Text und so oft er wollte. Auf Kosten Ihrer Versandreputation. Der Empfänger kommt jetzt ausschließlich aus der Modulkonfiguration.

Der secure_key, der das eigentlich verhindern sollte, war md5(_COOKIE_KEY_ . 'reportbrokenlink') — für die gesamte Lebensdauer des Shops konstant und in jede Produktseite hineingeschrieben. Einmal ausgelesen, für immer wiederverwendbar. Heute ist es ein HMAC-signiertes, zeitlich begrenztes, produktgebundenes Token.

Besuchereingaben werden außerdem beim Ausgeben escaped, nicht nur beim Entgegennehmen gefiltert. PrestaShop ersetzt Mailvariablen mit einem schlichten str_replace und escapt dabei gar nichts — eine nicht escapte Zeichenkette würde es einem Melder erlauben, einen Phishing-Link in eine E-Mail zu setzen, die tatsächlich von Ihrem Shop stammt.

Das Frontend hat jQuery 1.8.2 und jede weitere Abhängigkeit verloren

Version 3.x lud jQuery 1.8.2 auf jeder Produktseite von Googles CDN. Das schickte die IP-Adresse jedes Besuchers vor jeder Einwilligung an Google, brachte eine Bibliothek von 2012 mit vier veröffentlichten Sicherheitshinweisen mit und überschrieb das jQuery Ihres Themes für alles, was danach lief.

Das ist alles verschwunden. Das Frontend ist abhängigkeitsfreies Vanilla JavaScript und CSS — je eine kleine Datei, ausschließlich auf Produktseiten registriert. Kein jQuery, kein Bootstrap.

Übermittelt wird jetzt per POST. Version 3.x verschickte die Daten per GET — über eine Option post: "POST", die es in jQuery gar nicht gibt, sodass stillschweigend die Voreinstellung griff — womit die E-Mail-Adresse jedes Melders in den Zugriffs-Logs Ihres Webservers landete.

Barrierefrei, weil von Anfang an so gebaut

Der Dialog ist ein echter Dialog: Der Fokus wandert hinein, Tab bleibt darin gefangen, Escape schließt ihn, und der Fokus kehrt auf den Button zurück, von dem Sie kamen. Fehler werden an Screenreader gemeldet, Fokusrahmen sind sichtbar, prefers-reduced-motion wird respektiert, und unter 480 px geht der Dialog in den Vollbildmodus.

Beim Öffnen wird er außerdem nach <body> verschoben. An Ort und Stelle gerendert saß er im <form> des Themes für den Warenkorb — ein verschachteltes Formular, das das Layout zerstörte und das Falsche abschicken konnte.

Kompatibilität

PrestaShop 1.7 bis 9, PHP 7.2 bis 8.3, in acht Sprachen: Deutsch, Englisch, Französisch, Italienisch, Niederländisch, Polnisch, Spanisch und Türkisch. Als deutschsprachiger Händler arbeiten Sie also in einem übersetzten Back Office.

Keine Overrides, keine Änderungen an Core oder Theme, kein jQuery. Fünf Hooks, eine Datenbanktabelle. Die Deinstallation entfernt die Tabelle, jede gespeicherte Meldung und alle Einstellungen — exportieren Sie also vorher nach CSV, wenn Sie sie behalten möchten.

Häufig gestellte Fragen

Brauchen meine Kunden ein Konto, um etwas zu melden?

Nein, und es empfiehlt sich, Meldungen von Gästen zuzulassen — Gäste sind meist diejenigen, denen eine fehlerhafte Seite auffällt. Wenn Sie möchten, beschränken Sie den Button mit einer einzigen Einstellung auf angemeldete Kunden.

Wo erscheint der Button?

Auf Produktseiten, entweder neben den Produktinformationen oder darunter — displayProductAdditionalInfo (neben den Produktinformationen) oder displayFooterProduct (im Fußbereich der Produktseite). Blendet Ihr Theme den einen aus, wechseln Sie in den Moduleinstellungen auf den anderen.

Was passiert, wenn mein Mailserver ausfällt?

Es geht nichts verloren. Die Meldung wird gespeichert, bevor überhaupt ein Mailversand versucht wird, der Fehler landet unter Erweiterte Einstellungen → Logs, und die Meldung wartet in Ihrer Liste. Das ist der größte Unterschied zu Version 3.

Werden die IP-Adressen der Melder gespeichert?

Nein. Die Ratenbegrenzung verwendet einen SHA-256-Hash, der mit dem eigenen Geheimnis Ihres Shops geschlüsselt ist, niemals die Adresse selbst. Name und E-Mail-Adresse sind optional und werden nur erhoben, damit Sie dem Melder mitteilen können, dass Sie das Problem behoben haben.

Ein Besucher sagt, das Formular habe ihm mitgeteilt, es sei abgelaufen.

Das signierte Token gilt zwei Stunden — wer eine Produktseite länger offen lässt, bekommt diese Meldung. Ein Neuladen der Seite behebt es. Tokens sind an das Produkt gebunden, und genau das verhindert, dass sie anderswo in Ihrem Katalog wiederverwendet werden.

Warum sind manche Meldungen als Duplikat markiert und werden mir nicht gemailt?

Die Duplikaterkennung ist standardmäßig aktiv: dieselbe Person, dasselbe Produkt, dieselbe Problemart innerhalb von 24 Stunden wird als Duplikat abgelegt, statt Sie zweimal zu benachrichtigen. In der Liste stehen sie weiterhin alle — filtern Sie nach dem Status Duplikat oder schalten Sie die Einstellung ab.

Kann ich die Meldungen aus PrestaShop herausbekommen?

Ja. Der CSV-Export liefert exakt das, was Ihre aktuellen Filter treffen. Zellen, die mit einem Zeichen beginnen, das eine Tabellenkalkulation als Formel liest — =, +, -, @, Tabulator oder Wagenrücklauf —, werden bewusst neutralisiert, damit niemand eine Tabellenkalkulations-Formel in eine Datei einschleusen kann, die Sie öffnen.

Braucht es jQuery oder Bootstrap?

Weder noch. Das Frontend ist Vanilla JavaScript und CSS, je eine kleine Datei, ausschließlich auf Produktseiten geladen. Wenn Sie einem Klick nachgehen, der nichts bewirkt, prüfen Sie Ihre Browser-Konsole auf einen unabhängigen Fehler eines anderen Skripts auf der Seite.

Was passiert bei der Deinstallation mit meinen Meldungen?

Sie werden gelöscht, zusammen mit allen Einstellungen — Sie werden vorher um Bestätigung gebeten. Exportieren Sie vorher nach CSV, falls Sie sie später noch brauchen könnten.