Das Modul rendert nur, wenn der Shop nicht im Katalogmodus ist und PrestaShop mehr als eine aktive Währung zurückgibt. Gibt es nur eine aktive Währung, gibt der Hook nichts zurück und es wird kein Selector angezeigt. Die Platzierung hängt außerdem davon ab, ob das Theme den displayNav2-Hook im Header- oder Navigationsbereich rendert.

Ja. Das Modul ist auf PrestaShop 1.7.7 und neuer ausgelegt und läuft unter 1.7.x, 8.x und 9.x mit PHP 7.1 oder höher. Es registriert sich auf den Startseiten-Hooks (displayHome / displayHomeIntro) und lässt sich zudem als Widget einbinden, sodass es ohne Core-Änderungen in unterstützten Themes funktioniert.

Ja. Das Modul registriert seinen eigenen Selektor im displayNav2-Hook und lädt ein Stylesheet, das PrestaShops nativen Desktop-Währungsselektor mit #_desktop_ps_currencyselector { display: none !important; } ausblendet. Der Kunde sieht den kompakten Symbol-Dropdown des Moduls statt des Standard-Währungsblocks.

Es deinstalliert oder bearbeitet PrestaShops natives Währungsmodul nicht. Es rendert einfach einen Ersatz-Dropdown im Header-/Navigation-Hook und versteckt den Standard-Desktop-Block per CSS. Das macht die Änderung reversibel: Deaktivieren oder deinstallieren Sie das Modul, und der native Selektor kann wieder erscheinen, vorausgesetzt das Theme rendert ihn noch.

Der Ersatz nutzt das Symbol der aktuellen Währung im Toggle, zeigt optional das ISO-Label daneben und listet aktive Währungen im Dropdown. Die Defaults sind SHOW_LABEL=0 und SHOW_NAMES=1, sodass der Toggle kompakt bleibt, während der Dropdown weiterhin vollständige Währungsnamen zeigt. Jede Option ist ein nofollow-Link, gebaut mit PrestaShops normalen Currency-Switch-Parametern.

Die Platzierung hängt weiterhin vom Theme ab. Wenn das Theme displayNav2 nicht im Header- oder Navigationsbereich aufruft, hat das Modul keinen Ort, an dem es den Selektor rendern kann, auch wenn die Assets geladen sind.

Es fügt den offiziellen Intercom Messenger zu Ihrem PrestaShop-Shop hinzu. Das Modul lädt den Intercom-Loader auf jeder Seite unmittelbar vor dem schließenden Body-Tag – Sie fügen Ihre Intercom-App-ID nur einmal ein, statt Theme-Templates zu bearbeiten. Das Widget lädt exakt wie der Original-Installations-Snippet von Intercom, sodass Posteingang, Produkttouren und automatisierte Nachrichten voll funktionieren.

Das Modul erstellt GA4-Ereignisse aus echten PrestaShop-Aktionen statt aus einem generischen Seitenaufruf-Tag. Es erfasst Produktansichten, das Hinzufügen zum Warenkorb und Mengenänderungen, den Checkout-Start, abgeschlossene Käufe, Suchanfragen im Shop, Kundenanmeldungen und neue Kontoerstellungen — jeweils mit den passenden GA4-E-Commerce-Parametern. Ein integrierter Ereignis-Builder ermöglicht außerdem eigene Ereignisse für shop-spezifische Interaktionen.

Das Modul rendert nur, wenn der Shop nicht im Katalogmodus ist und PrestaShop mehr als eine aktive Währung zurückgibt. Wenn es nur eine aktive Währung gibt, gibt der Hook nichts zurück, also wird kein Selektor angezeigt. Die Platzierung hängt außerdem davon ab, dass das Theme den displayNav2-Hook im Header- oder Navigationsbereich rendert.

Prüfen Sie zuerst diese Punkte:

• Catalog mode: Wenn Katalogmodus aktiv ist, gibt der Selektor absichtlich einen leeren String zurück.
• Currency count: Das Modul ruft PrestaShops aktive Währungsliste ab und versteckt sich, wenn diese Liste eine oder keine Währung enthält.
• Theme hook: Der Selektor wird nur über displayNav2 gerendert. Manche Custom Themes entfernen oder verschieben diesen Hook.
• Native block CSS: Das Modul versteckt #_desktop_ps_currencyselector. Wenn Sie nur nach dem alten Block suchen, ist er absichtlich verborgen, während dieses Modul aktiv ist.

Wenn der Selektor nach Aktivierung mehrerer Währungen weiterhin nicht erscheint, prüfen Sie die Seitenquelle auf mprcurrency-dropdown. Fehlt dieses Markup, rendert der Hook nicht oder das Modul ist früh zurückgekehrt. Existiert das Markup, aber Sie sehen es nicht, liegt das Problem an Theme-CSS oder Header-Layout, nicht an der Währungsverfügbarkeit.

Das Modul lädt eigenes CSS und JavaScript im Front Office. Das JavaScript öffnet und schließt nur den Dropdown; es erstellt das Selektor-Markup nicht. Ein fehlender Selektor ist also fast immer Katalogmodus, Single-Currency-Konfiguration, fehlender displayNav2-Hook oder Theme-Styling, das den gerenderten Block versteckt.

Melden Sie sich unter app.intercom.com in Ihrem Intercom-Konto an, öffnen Sie Einstellungen > Installation > Web und kopieren Sie die App-ID aus dem Installationscode. Fügen Sie sie in das App-ID-Feld des Moduls ein und speichern Sie. Solange keine App-ID eingetragen ist, bleibt das Widget inaktiv, sodass das Modul niemals ein fehlerhaftes oder leeres Skript ausgibt.

Ja, wenn Sie es aktivieren. Wenn Sie ein GA4-API-Secret konfigurieren, kann das Modul Käufe serverseitig über das Measurement Protocol als Fallback senden, sodass eine Bestellung in GA4 auch dann erfasst wird, wenn das gtag.js-Tag im Browser durch einen Adblocker blockiert oder auf einer fehlerhaften Seite verloren geht. Der Fallback läuft nur, wenn Sie ihn aktivieren und das API-Secret angeben.

Nein. Es nutzt die Währungen, die bereits in PrestaShop konfiguriert sind, und baut Switch-Links mit SubmitCurrency=1&id_currency=.... Es erstellt keine Währungen, bearbeitet keine Wechselkurse und berechnet keine Umrechnungen. Währungsverfügbarkeit, Kurse und Preisverhalten bleiben durch PrestaShops Währungskonfiguration behandelt.

Das Modul liest PrestaShops aktive Währungen, findet die aktuelle Währung aus dem Kundenkontext und rendert einen Link für jede verfügbare Währung. Ein Klick auf einen Link bittet PrestaShop, die ausgewählte Währung des Besuchers zu wechseln; danach behandelt PrestaShop Preisumrechnung, Rundung, Steueranzeige und Formatierung genau wie sonst.

Nutzen Sie PrestaShops eigene Währungseinstellungen für operative Änderungen: Währungen hinzufügen oder deaktivieren, Wechselkurse aktualisieren, Lokalisierung konfigurieren und entscheiden, wie Preise angezeigt werden sollen. Nutzen Sie dieses Modul für die Front-Office-Darstellung des Selektors: Symbol-only Toggle, optionaler ISO-Code im Toggle, optionale Namen im Dropdown, theme-aware Styling und kompakte Header-Fläche.

Eine hilfreiche Sichtweise: PrestaShop besitzt die Geldlogik; das Modul besitzt die Dropdown-UI. Wenn eine Währung im Selektor fehlt, korrigieren Sie zuerst ihren Active-/Available-Status in PrestaShop. Wenn Umrechnungswerte falsch sind, aktualisieren Sie Wechselkurse in PrestaShop statt in diesem Modul.

Ja. Wenn "Benutzerdaten übergeben" aktiviert ist, sendet das Modul E-Mail und Name des angemeldeten Kunden an intercomSettings, sodass Konversationen in Ihrem Intercom-Posteingang bereits zugeordnet ankommen. Gäste sehen den Messenger weiterhin, aber anonym – für nicht angemeldete Besucher werden keine personenbezogenen Daten übermittelt.

Das Modul unterstützt ein einwilligungsbewusstes Laden, sodass das Tracking den Einwilligungsstatus des Besuchers respektiert, und bietet eine datenschutzbewusste, gehashte User-ID statt roher Kennungen. Das Einwilligungsverhalten hängt von den aktivierten Optionen und der externen Einwilligungslösung (z. B. einer CMP) ab, die Sie anbinden. Für Ihre eigene Datenschutz- und Einwilligungskonfiguration bleiben Sie verantwortlich.

Ja. Der Slide-Text — Titel, Untertitel und Button-Beschriftung — wird pro Sprache gespeichert, sodass jede aktive Shop-Sprache eigenen Wortlaut zeigen kann, während Layout und Bilder gemeinsam genutzt werden. Die Übersetzungen pflegen Sie direkt im Modul-Backend.

Ja. Sie legen fest, ob der Messenger auf allen Seiten oder nur auf bestimmten erscheint, schalten die Anzeige auf Mobilgeräten ein oder aus und stellen eine Verzögerung in Sekunden ein, damit das Widget etwas nach der Seite lädt. So bleibt der Shop schnell und der Chat erscheint nur dort, wo er den Kunden wirklich hilft.

Ja. Das Modul enthält einen Ausschluss nach Mitarbeitern und IP-Adressen, sodass Besuche von angemeldeten Mitarbeitern oder von den aufgelisteten IP-Adressen nicht an GA4 gesendet werden. So bleiben interne Tests und Back-Office-Aktivitäten aus Ihren Analyseberichten heraus.

Nein. Banner Revolution zeigt lediglich die von Ihnen konfigurierten Banner, Texte und Call-to-Action-Links an. Es erfasst keine personenbezogenen Besucherdaten und setzt keine Tracking-Cookies, hat also über die von Ihnen verlinkten Seiten hinaus keine eigene DSGVO-Auswirkung.

Ein Diagnose-Panel im Back-Office validiert die GA4-Measurement-ID, bevor das Tracking startet, und prüft die Ereignisübermittlung mit Wiederholungslogik für das Measurement Protocol. Ein Ereignisprotokoll erfasst die vom Modul erstellten und gesendeten Ereignisse, sodass Sie den Dateneingang in GA4 bestätigen können, bevor Sie sich auf die Berichte verlassen.

Das Modul unterstützt PrestaShop 1.6 bis 9.x, einschließlich 8.x, und läuft mit PHP 7.2 und neuer. Die gesamte Konfiguration erfolgt im Back-Office, sodass keine Änderungen an Ihren Theme-Templates nötig sind.

Nein. Es bearbeitet keine Templates und überschreibt keine Theme-Dateien. Es arbeitet über PrestaShops Presenter-Hooks — actionPresentProduct und actionPresentProductListing ergänzen die Bilddaten, die Ihr Theme ohnehin rendert, um loading- und decoding-Werte — sowie über den Hook filterHtmlContent für WYSIWYG-Texte. Ihr Theme behält die volle Kontrolle über das Markup; das Modul liefert nur die Attribute. Nach einer Deinstallation werden die Attribute einfach nicht mehr hinzugefügt und am Theme bleibt nichts verändert.

Nein. Der schwebende LINE-Button wird über die PrestaShop-Hooks displayBeforeBodyClosingTag und displayHeader eingefügt, sodass Ihre Theme- und Template-Dateien nie bearbeitet oder überschrieben werden. Beim Deinstallieren verschwindet der Button rückstandslos.

Ja. Das Modul parst oder überschreibt das endgültig gerenderte HTML einer Seite nicht. Es reichert die Bilddaten auf der Presenter-Ebene an, bevor das Template läuft, und verarbeitet nur bestimmte WYSIWYG-Inhaltsfelder. Da es die Seitenausgabe nie berührt, lässt es sich sicher mit Full-Page-Cache, CCC und CDNs betreiben — es gibt keinen Ausgabepuffer, der invalidiert werden müsste, sodass gecachte Seiten gültig bleiben.

Das Widget öffnet Ihren LINE-Kontaktlink (https://line.me/ti/p/Ihre-LINE-ID) in einem neuen Tab, damit der Besucher in der LINE-App ein Gespräch beginnen kann. Es hängt keine vorausgefüllte oder gespeicherte Nachricht an den Link an, sondern übergibt den Kunden einfach an LINE.

Ja. Fügen Sie bei Bildern in WYSIWYG-Inhalten dem img-Tag die Ausschluss-CSS-Klasse (Standard no-autolazy) hinzu, und das Modul überspringt es. Das ist der empfohlene Weg, um Ihr Above-the-Fold-Hauptbild sofort zu laden, denn das Lazy Loading des größten sichtbaren Bildes kann den Largest Contentful Paint verschlechtern. Inline-Data-URI-Bilder und Bilder mit bereits vorhandenem loading-Attribut werden ebenfalls automatisch übersprungen.

Ja. Über die Seitenausrichtung zeigen Sie den Button auf jeder Seite oder beschränken ihn auf bestimmte Seiten, und ein separater Mobil-Schalter blendet ihn auf Smartphones aus. Eine Ladeverzögerung kann den Button zudem kurz zurückhalten, damit er beim Laden nicht mit der Seite konkurriert.

Es ist ein Browser-Hinweis, der ein Bild außerhalb des Haupt-Threads dekodieren lässt, sodass das Dekodieren eines großen Bildes das Scrollen oder Interagieren seltener blockiert. Es ergänzt loading="lazy". Das Modul fügt es standardmäßig hinzu, bietet aber einen einzelnen Schalter zum Deaktivieren, sodass nur loading="lazy" bleibt. Vorhandene decoding-Attribute werden nie überschrieben.

Produktbilder auf der Produktseite, Produktbilder in Kategorie- und Suchlisten sowie Bilder in WYSIWYG-Inhalten wie Produkt-, Kategorie-, CMS- und Herstellerbeschreibungen. Die ersten beiden werden über die Produkt-Presenter-Hooks verarbeitet, das letzte über den Inhaltsfilter-Hook. Es ist ein gezielter Geschwindigkeits-Helfer — es komprimiert, skaliert oder konvertiert keine Bilder, sondern fügt nur die loading- und decoding-Attribute hinzu.

Der geschlossene Header-Toggle zeigt immer das aktuelle Währungssymbol oder Zeichen, etwa $, €, £ oder den ISO-Code als Fallback. Wenn Show ISO label in toggle aktiviert ist, zeigt der Toggle außerdem den aktuellen ISO-Code neben dem Symbol. Das geöffnete Dropdown listet jede Währung immer mit Symbol/Zeichen auf, und wenn Show currency names in dropdown aktiviert ist, wird zusätzlich der vollständige Währungsname neben jedem Symbol angezeigt.

Der Toggle rendert keinen Hover-Tooltip. Währungsnamen werden in den Dropdown-Zeilen verwendet, einschließlich des Link-title-Attributs für jede Währungsoption.

Ja. Das Modul registriert seinen eigenen Selector im displayNav2-Hook und lädt ein Stylesheet, das den nativen PrestaShop-Desktop-Currency-Selector mit #_desktop_ps_currencyselector { display: none !important; } ausblendet. Der Kunde sieht statt des Standard-Währungsblocks das kompakte Symbol-Dropdown des Moduls.

Aktivieren Sie das Modul, fügen Sie Ihre ActiveCampaign Account ID ein und speichern Sie die Konfiguration. Die Account ID ist der numerische Wert, den ActiveCampaign unter Settings > Tracking > Site Tracking zeigt; sie wird als ACCOUNT_ID gespeichert, und das Modul rendert das Storefront-Script erst, wenn sowohl ENABLED als auch ACCOUNT_ID vorhanden sind.

• Öffnen Sie in PrestaShop die ActiveCampaign-Modulkonfiguration.
• Schalten Sie Enable ActiveCampaign ein.
• Fügen Sie die numerische Account ID ein, zum Beispiel 123456789.
• Besuchen Sie eine Storefront-Seite und bestätigen Sie, dass die Seitenquelle das ActiveCampaign Diffuser Script enthält.

Wenn aktiv, lädt der Hook displayBeforeBodyClosingTag ActiveCampaigns Diffuser Script, führt vgo('setAccount', ...) aus, aktiviert Default Tracking und ruft vgo('process') auf. Für eingeloggte Kunden kann es außerdem die E-Mail des Kunden mit vgo('setEmail', ...) übergeben.

Das Script wird direkt vor dem schließenden Body-Tag eingefügt, nicht im Page Head. Das ist nützlich beim Installationscheck: Suchen Sie in der gerenderten Seitenquelle nahe unten nach diffuser-cdn.app-us1.com/diffuser/diffuser.js, vgo('setAccount' und Ihrer Account ID. Wenn diese fehlen, ist entweder das Modul deaktiviert, die Account ID leer oder das Theme führt den displayBeforeBodyClosingTag-Hook nicht aus.

Die Konfiguration hat außerdem ein optionales EVENT_KEY-Feld, aber der aktuelle Storefront-Hook ist nur Site Tracking. Er sendet aus diesem Modulcodepfad keine Custom-ActiveCampaign-Event-Tracking-Calls. Nutzen Sie es, um das offizielle Site-Tracking-Snippet hinzuzufügen und eingeloggte Kunden per E-Mail zu identifizieren; bauen Sie Custom Event Automation separat, wenn Sie tieferes ActiveCampaign Event Tracking brauchen.

Denken Sie beim Datenschutz daran, dass dies ein Tracking-Script ist. Kombinieren Sie es mit Ihrem Consent-Setup, wenn Ihr Store Marketing- oder Analytics-Consent benötigt, bevor Third-Party-Tracking geladen wird, weil dieses Modul selbst kein Cookie-Consent-Gate implementiert.

Ja, eingeloggte PrestaShop-Kunden werden im ActiveCampaign-Tracking-Script per E-Mail identifiziert. Das Modul liest den aktuellen Kunden aus dem PrestaShop-Kontext und sendet die E-Mail nur, wenn der Kunde eingeloggt ist; anonyme Besucher werden ohne E-Mail-Wert getrackt.

Die Prüfung erfolgt im Storefront-Body-Closing-Hook. Tracking wird nur gerendert, wenn das Modul aktiviert ist und eine ActiveCampaign Account ID vorhanden ist. Der Hook weist dann drei Template-Werte zu: die Account ID, die Kunden-E-Mail und ein Boolean, der angibt, ob eine E-Mail gefunden wurde.

Im Template ist vgo('setEmail', ...) in eine Logged-in-Prüfung eingeschlossen, sodass Gäste keinen leeren E-Mail-Call bekommen. Jede getrackte Seite setzt weiterhin Account, aktiviert Default Page Tracking und ruft vgo('process') auf. Das bedeutet, ActiveCampaign kann bekannte Seitenbesuche mit der E-Mail des eingeloggten Kunden verbinden, während Gastbesuche anonym bleiben, bis ActiveCampaign sie über einen anderen Weg identifizieren kann.

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

Die erforderliche Einstellung ist die ActiveCampaign Account ID, außerdem muss das Modul aktiviert sein. Der Code prüft beides, bevor er das PrestaShop-Storefront-Script rendert; das Event-Key-Feld wird in der Konfiguration gespeichert, aber das aktuelle Tracking-Template verwendet es nicht.

Bei Installation ist ENABLED standardmäßig 0, ACCOUNT_ID standardmäßig ein leerer String und EVENT_KEY ebenfalls ein leerer String. Der Required-Configuration-Hinweis deklariert nur ACCOUNT_ID als erforderlich, und die Aktivierungsprüfung ist schlicht enabled plus nicht-leere Account ID.

Die Admin-Option bezeichnet die Account ID als numerische ID aus ActiveCampaign Site Tracking, aber dieser Source wendet vor dem Rendering keinen numerischen Validator an. Für eine saubere Einrichtung kopieren Sie die Account ID exakt aus ActiveCampaigns Site-Tracking-Einstellungen, aktivieren das Modul und prüfen dann die Seitenquelle auf das diffuser.js-Script und vgo('setAccount', ...).

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

Nein, dieses Modul sendet keine Produkt-, Warenkorb-, Bestell- oder Custom-ActiveCampaign-Ecommerce-Events. Sein PrestaShop-Code lädt nur Site Tracking, setzt den Account, identifiziert optional die E-Mail eines eingeloggten Kunden und ruft die ActiveCampaign-Page-Processing-Funktion auf.

Die gespeicherte Einstellung EVENT_KEY wird als optional für Custom Events beschrieben, aber das Storefront-Template referenziert sie nie. Es gibt keine Purchase-, Cart-, Product- oder Checkout-Event-Calls im Tracking-Template; die einzigen ActiveCampaign-Calls sind setAccount, setTrackByDefault, optional setEmail und process.

Für Händler ist das praktische Ergebnis Page-Visit-Tracking statt Ecommerce Tracking. Sie können damit ActiveCampaign getrackte Page Views sehen lassen und eingeloggte Kunden per E-Mail identifizieren, aber Order Value, Product IDs, Cart Contents und Line Items werden von diesem Modul nicht gesendet. Wenn Sie diese brauchen, erfordert das eine andere Integration oder neuen Code, der tatsächlich Product-, Cart- und Order-Events hookt.

PrestaShop-Module benötigen jeweils geplante Jobs (Feeds, Cleanups, Syncs), aber für jedes eine eigene Server-Cron-Zeile zu verdrahten ist fragil. Ein Cron Manager gibt Ihnen einen einzigen, token-geschützten Endpunkt, der sie alle ausführt. Mit Cron Manager stellt PrestaShop eine URL wie /module/mprcron/cron?token=… bereit (plus einen cron.php-Entry-Point für CLI- oder HTTP-Aufrufe mit Max-Task- und Kontextoptionen), die jede registrierte Aufgabe der Reihe nach ausführt. Richten Sie einen Server Cron — oder einen externen Dienst wie cron-job.org — auf diese URL in Ihrem gewählten Intervall, und verwalten Sie individuelle Zeitpläne, Aktivierungszustand und Laufhistorie aus dem Back Office statt über crontab. Halten Sie das Token geheim, damit Außenstehende es nicht auslösen können, und starten Sie je nach Zeitkritikalität Ihrer Aufgaben mit einem 5- bis 15-Minuten-Intervall. Zentralisiertes Logging macht auch einen fehlgeschlagenen Job leicht erkennbar.

Der generierte CLI-Befehl ist ein einzeiliger Crontab-Befehl mit dem gemeinsamen Token, zum Beispiel * * * * * php /path/to/modules/mprcron/cron.php --token=TOKEN --max-seconds=300. Der Entry Point verlangt ein Token, begrenzt max_tasks zwischen 1 und 100, begrenzt max_seconds zwischen 10 und 300 und verwendet standardmäßig 20 Aufgaben und 300 Sekunden. Das gemeinsame Token wird als 64-Zeichen-Hex-Wert generiert und mit hash_equals validiert.

Intern besitzt das gemeinsame Package zwei Tabellen: mpr_cron_task für registrierte Tasks und mpr_cron_log für Ausführungshistorie. Jeder Task speichert Modul, Task Key, Label, Callable oder Payload, Executor Type, Schedule, Enabled State, Next Run, Context, Priority und Timeout. Der Runner claimt einen Task, bevor er ihn ausführt, zeichnet completed, failed, skipped, timeout oder crashed States auf und schreibt eine Log-Zeile. Im CLI-Modus kann jeder Task, wenn das lokale cron.php isolierte Tasks unterstützt und proc_open verfügbar ist, in einem Subprozess laufen, sodass ein fataler Task den Rest des Batches nicht stoppt.

Ein guter FAQ-Bereich beantwortet Käuferfragen, bevor sie eine E-Mail senden, und erfasst Long-Tail-Suchtraffic. Um PrestaShop einen solchen Bereich hinzuzufügen, verwenden Sie FAQ Manager: Es erstellt einen öffentlichen FAQ Hub mit Kategorie-, Tag-, Such- und Fragerouten, zeigt einen Product FAQ Tab über displayProductExtraContent und kann kategoriebezogene FAQ-Inhalte als Left-Column-/Sidebar-Block über displayLeftColumn anzeigen. Sie speichern Fragen, Kategorien, Tags und Produkt- oder Kategoriezuweisungen, sodass dieselbe Antwort im Hub und auf jedem zugehörigen Produkt erscheinen kann. Kunden können eigene Fragen zur Moderation einreichen, und genehmigte Community-Antworten mit Helpful Votes ergänzen frische Inhalte. Für SEO geben Sie jeder indexierbaren Frage einen eindeutigen Title und eine Meta Description, halten Antworten wirklich hilfreich statt Einzeiler und verwenden FAQ Schema nur, wo es korrekt und weiterhin nützlich für Ihr Such-/Anzeigeziel ist.

Praktisch starten Sie im FAQ-Adminmenü: Erstellen Sie FAQ-Kategorien und fügen Sie dann Fragen mit mehrsprachigem Fragetext, Antwort-HTML, Friendly URL, Meta Title und Meta Description hinzu. Wenn die Friendly URL leer bleibt, generieren Kategorien einen Slug aus dem Kategorienamen und Fragen einen Slug aus dem Fragetext. Eine öffentliche Frage ist nur sichtbar, wenn sie aktiv ist, ihr Publish Date leer oder bereits vergangen ist und die aktuelle Kundengruppe erlaubt ist. Sie können außerdem ein Answer Reveal Date setzen, sodass die Frage existieren kann, bevor die Antwort angezeigt wird.

• Verwenden Sie Categories für öffentliche FAQ Hubs und für das Mapping von FAQ-Kategorien zu PrestaShop-Kategorien, wo Kontextblöcke auf Kategorieseiten nützlich sind.
• Verwenden Sie Questions für die echten FAQ-Einträge; weisen Sie Produkte direkt zu, wenn eine Frage in einem Product FAQ Tab erscheinen soll.
• Verwenden Sie Tags, um FAQ-Suche, Tag-Seiten und interne Entdeckung zu verbessern.
• Verwenden Sie Pending Questions und Additional Replies, um Besucher-Einreichungen zu moderieren, bevor sie öffentlich werden.

Für Produktseiten sollten Sie sich nicht auf breite Kategorie-Mappings verlassen, wenn Sie eine exakte Produkt-FAQ benötigen. Der Product Tab lädt Fragen aus der direkten Product-Question-Assignment-Tabelle und gibt nichts zurück, wenn diesem Produkt keine Frage zugewiesen ist. Fragen, die genau einem Produkt zugewiesen sind, können eine Antwort im initialen Produktseiten-HTML rendern; Fragen, die über mehrere Produkte geteilt werden, gelten als related/shared, und ihre Antworten werden erst beim Öffnen lazy-loaded. Dadurch werden große Troubleshooting-Artikel nicht in jede Produktseite injiziert, und störender Duplicate Content wird vermieden.

Kategorieseiten werden von diesem Modul nicht als Tab gerendert. Die Kategorieintegration ist ein Left-Column-/Sidebar-Block, der eine begrenzte Menge Fragen für die aktuelle Kategorie lädt und sie in die FAQ-Erfahrung verlinkt.

Die SEO-Steuerungen sind bewusst granular. FAQ Hub Indexing ist standardmäßig an, aber Kategorieseiten, Tag-Seiten und einzelne Frageseiten werden nicht indexiert, sofern nicht der jeweilige globale Schalter aktiviert ist und, bei Kategorien oder Fragen, die Entität selbst als indexierbar markiert ist. Suchseiten sind immer noindex. Meta Title- und Meta Description-Felder fallen auf sichtbaren Titel, Kategoriebeschreibung oder Answer Excerpt zurück, wenn sie leer bleiben, und Canonical URLs werden aus lokalisiertem FAQ Slug, Category Slug und Question Slug gebaut.

Schema ist ein Schalter, keine automatische Magie. Die Einstellung ist SCHEMA_ENABLED und standardmäßig 0; der Admin-Hinweis sagt, dass Google FAQ Rich Results im Mai 2026 deprecated hat. Behandeln Sie es daher als optionale Structured Data, nicht als garantierten Rich-Result-Trigger. Scheduled-Answer-Handling ist nicht in jedem Schema-Pfad des aktuellen Codes konsistent: Die Front-Question- und Category-JSON-LD-Builder prüfen answer_visible, aber die Module-Level-Header-QAPage-Ausgabe liest questionData['answer'] direkt, und der FAQ-Hub-Schema-Query-/Build-Pfad prüft date_response oder answer_visible nicht. Wenn Sie verzögerte Antworten nutzen, lassen Sie Schema deaktiviert oder fixen diese Pfade, bevor Sie sich darauf verlassen, dass Schema künftige Antwortinhalte verbirgt.

Der Besucher-Submission-Flow ist moderiert. Ask a Question ist standardmäßig aktiviert, validiert Name, E-Mail und Fragetext, begrenzt Fragetext auf 5000 Zeichen, nutzt ein Honeypot-Feld und speichert das Element in mprfaq_pending mit Pending-Status. Das Standard-Rate-Limit ist ASK_MAX_PENDING=2 ausstehende Fragen pro E-Mail und Top-Level-Produktkategorie; setzen Sie es nur auf 0, wenn Sie bewusst kein Pending-Question-Limit möchten. Wenn der Besucher von einer Produktseite fragt und keine FAQ-Kategorie geliefert wird, löst der Controller eine Kategorie aus dem Produktkontext auf.

Öffentliche Replies sind von der offiziellen Antwort getrennt. CA_ENABLED ist standardmäßig 0; wenn aktiviert, kann das Modul Login verlangen, validiert Autorendetails, begrenzt Reply-Text auf 5000 Zeichen und speichert die Reply als Pending. Genehmigte Additional Replies können als Community Answers erscheinen und gevotet werden. Helpful Votes sind auf eine Stimme pro IP je Frage oder Antwort begrenzt, mit einem PrestaShop-Cookie, das nur dazu dient, den UI-Zustand des Besuchers zu merken.

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

Für eine SEO-FAQ ist die praktische Regel: Halten Sie den Hub breit, machen Sie nur starke eigenständige Kategorie- oder Frageseiten indexierbar, weisen Sie Produktfragen direkt zu und lassen Sie kleine produktspezifische Antworten im Product Tab. So erhalten Kunden Antworten dort, wo sie sie brauchen, während der Index auf Seiten fokussiert bleibt, die eigenständig bestehen können.

Ja, Sie können nach IP, CIDR Range, Country Code oder User-Agent Pattern blockieren, einschließlich checkout-only Scope. Der PrestaShop Ban Manager prüft zuerst Whitelist-Einträge, dann aktive Ban-Regeln und wendet je nach aktuellem Request-Kontext full, checkout oder authentication Scope an.

Das Ban-Formular unterstützt eine einzelne IP, eine Wildcard-IP wie 192.168.1.*, eine IP Range wie 1.1.1.1-1.1.1.255, CIDR wie 192.168.1.0/24, einen Country ISO Code und ein User-Agent Pattern. User-Agent-Regeln können Plain Text sein, case-insensitive gematcht, oder eine Regex in Slashes.

Scope basiert auf dem aktuellen Controller. Checkout Scope gilt für order, orderopc, cart, supercheckout, onepagecheckout und checkout. Login/Auth Scope gilt für authentication, my-account, identity, registration und password. Full Bans werden vor scope-spezifischen Bans geprüft, sodass ein Full Ban den Besucher überall blockiert.

• Enablement: BAN_ENABLED wird standardmäßig enabled installiert.
• Temporary bans: Ein Ban kann date_expiry haben; abgelaufene aktive Bans werden beim Laden aktiver Bans deaktiviert.
• Message: Jeder Ban kann eine eigene Nachricht haben, andernfalls fällt das Modul auf die konfigurierte mehrsprachige Standardnachricht zurück.
• Multishop: Ban-Datensätze mit id_shop=0 gelten global, während shop-spezifische Bans nur im aktuellen Shop-Kontext gelten.

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

Mit der Zeit füllt sich eine PrestaShop-Datenbank mit Daten, die Sie nicht mehr benötigen: abgebrochene Warenkörbe, verwaiste Warenkorbzeilen, abgelaufene Specific Prices und Cart Rules, alte Connection- und Guest-Datensätze, Suchstatistiken, Mail- und 404-Logs, Page Views und geschlossene Kunden-Threads. Unkontrolliert verlangsamen diese Tabellen Abfragen und blähen Backups auf. Um sie sicher zu löschen, verwenden Sie Cleanup Revolution: Es gruppiert jede Bereinigung in benannte Tasks, zählt die betroffenen Zeilen vor der Löschung, unterstützt Dry-run-Previews standardmäßig und zeichnet echte Löschläufe in der Cleanup History auf. Starten Sie mit abgebrochenen Warenkörben älter als 30 Tage und alten Such-/Connection-Statistiken, prüfen Sie die Preview Counts und löschen Sie dann in Batches. Erstellen Sie immer zuerst ein Datenbankbackup. Für laufende Pflege planen Sie Tasks, statt sie manuell auszuführen; siehe unseren PrestaShop performance guide.

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

Die Standardkonfiguration ist bewusst konservativ: Dry Run ist standardmäßig aktiviert, Trash Mode ist aktiviert, abgebrochene Warenkörbe standardmäßig 30 Tage, viele Logs/Statistiken 90 Tage, geschlossene Kundenthreads 180 Tage, leere Accounts 365 Tage, und die Engine nutzt Batch Sizes je Task plus ein Total Limit von 50000. Ein Task ohne zu entfernende Zeilen wird vom Bulk Runner übersprungen, und echte Löschung erfolgt in Batches statt als ein riesiges Statement.

Ein Audit-Log-Detail ist wichtig: Dry-run-Ausführungen geben die betroffene Anzahl zurück, bevor MPRCleanupLog::record() aufgerufen wird. Dry-run-Previews werden daher nicht in die Cleanup History geschrieben. Echte Datenbank-Cleanup-Läufe werden mit dry_run = 0 protokolliert. Manuelle Aktionen im Back Office rufen DatabaseCleanupEngine::executeTask(..., $employeeID) oder DatabaseCleanupEngine::executeAll($dryRun, $employeeID) auf, daher verwenden sie den Standardwert trigger_type = manual und speichern die Mitarbeiter-ID, wenn eine verfügbar ist. Die geplante Datenbankbereinigung ruft MPRCleanupRevolution::cronDBCleanup() auf, wodurch DatabaseCleanupEngine::executeAll(false, null, 'cron') übergeben wird. Diese Protokolleinträge speichern daher trigger_type = cron ohne Mitarbeiter-ID.

Die Database Cleanup Engine enthält benannte Tasks für abgebrochene Warenkörbe, verwaiste Cart Products, Suchstatistiken, abgelaufene Specific Prices, abgelaufene Cart Rules mit Nullmenge, alte Logs, alte Connections, verwaiste Connection Rows, alte Guests, Mail Logs, 404 Logs, Page Views, geschlossene Customer Threads und Referrer Cache. Sie hat außerdem risikoreichere kommerzielle Cleanups wie Gastkonten ohne Bestellungen, verwaiste Adressen und alte registrierte Konten ohne Bestellungen oder aktuelle Warenkörbe. Die Cron-Defaults trennen Arbeit in Datenbankbereinigung, Dateibereinigung und Tabellenoptimierungsfenster, sodass Sie Wartung automatisieren können, ohne jede schwere Operation gleichzeitig laufen zu lassen.

Wenn Sie nur einen klaren Accept-or-deny-Cookie-Hinweis benötigen, ist ein leichtgewichtiges Banner die einfachste Implementierung. Lightweight Cookie Banner rendert das Banner über Footer-Level-Hooks, speichert die Wahl des Besuchers in einem Consent Cookie und lässt Sie Bannertext, Buttons, Farben, Position, Datenschutzerklärungslink und die Dauer der Einwilligung konfigurieren, bevor erneut gefragt wird (standardmäßig 365 Tage). Es ist bewusst minimal - keine schweren Scripts - und verlangsamt Ihren Shop daher nicht. Nutzen Sie es, wenn Ihre Tracking-Fläche klein ist und Sie Besucher hauptsächlich informieren und ihre Wahl speichern müssen. Wenn Sie außerdem Scripts bis zur Einwilligung blockieren, Consent Records loggen oder granulare Präferenzen je Kategorie anbieten müssen, ist eine full consent platform die passendere Wahl. Kombinieren Sie das Banner immer mit einer korrekten, aktuellen Cookie- und Datenschutzerklärung.

Das Modul ist standardmäßig aktiviert, Position bottom-left, Buttons nebeneinander, Dark Theme, COOKIE_EXPIRY von 365 Tagen, Google Consent Mode aktiviert und DEFAULT_CONSENT auf denied. Es kann als Full-width Top- oder Bottom-Bar, Corner Banner, Floating Bottom Banner oder Center Modal mit Overlay rendern. Die Besucherwahl wird im First-Party-Cookie mprcookie_consent mit entweder granted oder denied gespeichert; JavaScript schreibt es mit path=/, SameSite=Lax und Secure, wenn der Shop über HTTPS läuft.

Wenn Google Consent Mode aktiviert ist, injiziert der Header Hook das Default-Consent-Signal und lädt head-sichere Assets/Config; er rendert nicht das sichtbare Banner-Markup. Das Banner-Markup wird aus displayFooterAfter oder displayFooter gerendert, mit Guard, sodass es nur einmal ausgegeben wird, und das Front-Script sendet nach Accept oder Deny des Besuchers ein Consent Update. Das Modul kategorisiert keine Cookies, schreibt keine Third-Party-Scripts um und führt keine Consent-Log-Tabelle. Es warnt außerdem, wenn Cookies Revolution verfügbar ist, weil nur ein Cookie-Consent-Modul den Storefront gleichzeitig steuern sollte.

Für vollständige GDPR- und ePrivacy-Compliance brauchen Sie mehr als ein Banner: Käufer müssen Cookies nach Zweck akzeptieren oder ablehnen können. Cookies Revolution ergänzt PrestaShop um granulare Einwilligung mit den Standardkategorien — notwendig, funktional, Analytics und Marketing — und ein Präferenzpanel, in dem Besucher alles akzeptieren, optionale Kategorien ablehnen oder eine individuelle Auswahl speichern können; ihre Wahl wird in einem Consent Cookie gespeichert. Es kann außerdem passende Tracking Scripts bis zur Einwilligung blockieren, Tags so umschreiben, dass sie nur für erlaubte Kategorien laufen, und Consent Records mit gehashten Identifiers für Ihren Audit Trail loggen. Vorherige Einwilligung (keine vorangekreuzten optionalen Kästchen) und Widerruf genauso einfach wie Zustimmung sind gesetzliche Anforderungen — dies deckt beides ab. Kombinieren Sie es mit Google Consent Mode v2, damit Ihre Google Tags sich automatisch an die Wahl jedes Käufers anpassen.

Bei der Installation erstellt das Modul Tabellen für Kategorien, Cookies, Script Rules, Consent Logs, Scan Results und Design. Die angelegten Kategorien sind necessary, functional, analytics und marketing; necessary ist erforderlich und standardmäßig aktiviert, während die optionalen Kategorien standardmäßig aus sind, sofern Sie den Default Consent Mode nicht ändern. Der gespeicherte Browserzustand ist kompakt, zum Beispiel necessary:1|functional:0|analytics:0|marketing:0 in mprcr_consent, mit einem separaten mprcr_version-Cookie, das verwendet wird, wenn RECONSENT_ON_CHANGE aktiviert ist.

Script Blocking funktioniert in zwei Schichten. Bei der Serverausgabe schreibt das Modul passende externe Scripts zu type="text/plain" mit data-cookiecategory um und speichert die ursprüngliche Quelle in data-original-src; es kann außerdem passende Inline Scripts anhand von Script-Content-Regeln umschreiben. Browserseitig prüft ein MutationObserver dynamisch injizierte Scripts gegen dieselbe Regelliste und blockiert sie, wenn die passende Kategorie nicht gewährt ist. Wenn Consent gespeichert wird, aktualisiert das Modul Google Consent Mode, aktiviert erlaubte Scripts, löscht Cookies für widerrufene Kategorien, wo konfiguriert, dispatcht mprcr:consent und loggt die Entscheidung per AJAX, wenn Logging aktiviert ist, mit einem kurzen Throttle, um doppelte Log-Spam-Einträge zu vermeiden.

Ja, es kann einen cron-job.org Job erstellen oder synchronisieren, wenn es konfiguriert ist. Die PrestaShop-Admin-Konfiguration kann den cron-job.org API-Schluessel testen, externe Erreichbarkeit pruefen und den Remote-Job auf die tokenisierte Cron-Status- oder Ausfuehrungs-URL des Moduls richten.

Nutzen Sie den Cleanup-Arbeitsbereich, um unterstützte alte Datensätze aus PrestaShop zu entfernen. Das Modul zählt und löscht über 30 Tage alte Warenkörbe ohne Bestellung, alte Suchstatistiken, abgelaufene spezifische Preise, Logs, Verbindungen, verwaiste Gäste und Maildaten.

Das Modul verwaltet digitale Katalogeinträge für Module, Themes und Addons. In PrestaShop kann jedes digitale Produkt technischen Modulnamen, Branch, aktuelle Version, Kompatibilitätsfelder, Dokumentations-URL, Demo-URL, Repository-URL, Changelog, Supportmonate und Domainlimits speichern.

Käufer konvertieren besser, wenn sie sehen können, wann eine Bestellung ankommt. Um ein geschätztes Lieferdatum in PrestaShop anzuzeigen, verwenden Sie Estimated Delivery Date: Es addiert Ihre konfigurierten Bearbeitungstage zum aktuellen Datum und zeigt das Ergebnis auf der Produktseite über den displayProductAdditionalInfo-Block an. Sie können eine tägliche Cutoff-Stunde setzen (Bestellungen danach zählen ab dem nächsten Tag), Wochenenden ausschließen, sodass Samstag und Sonntag nicht gezählt werden und ein finales Wochenendergebnis auf Montag vorrollt, und das Datumsformat wählen, das Käufer sehen. Die Nachricht erscheint automatisch auf berechtigten Produktseiten und gibt eine konkrete Erwartung „kommt an bis“ statt eines vagen „wird bald versendet“. Halten Sie Ihre Bearbeitungszeit realistisch und stimmen Sie den Cutoff auf Ihren echten Versandablauf ab, damit das versprochene Datum dem entspricht, was Kunden erhalten — präzise Schätzungen reduzieren „wo ist meine Bestellung“-Tickets.

Die Install-Defaults sind ENABLED=1, PROCESSING_DAYS=1, CUTOFF_HOUR=14, EXCLUDE_WEEKENDS=1 und DATE_FORMAT=l, F j. Die Berechnung verwendet das aktuelle DateTime des Servers, liest die aktuelle Stunde als ganze 24-Stunden-Zahl und addiert einen zusätzlichen Bearbeitungstag, wenn die aktuelle Stunde größer oder gleich der Cutoff-Stunde ist. Dann geht sie Tag für Tag weiter, bis die konfigurierte Anzahl von Bearbeitungstagen gezählt ist, und überspringt Samstag und Sonntag, wenn Wochenendausschluss aktiviert ist.

Die Storefront-Nachricht erhält außerdem hours_left, was einfach die Ganzstunden-Differenz bis zum Cutoff ist, wenn die Bestellung noch vor dem Cutoff liegt. Dieses Modul prüft keine Lieferzeitspannen von Versanddienstleistern, Lagerstatus, Lagerkalender, Feiertage, Ziel-Postleitzahl oder produktspezifische Vorlaufzeiten. Es ist ein einfaches Produktseiten-Versprechen auf Basis shopweiter Bearbeitungsregeln und funktioniert daher am besten, wenn Ihr Katalog dasselbe Versandmuster teilt.

Das Meta (Facebook) Pixel trackt Käuferaktionen, damit Sie Anzeigenleistung messen und Retargeting Audiences bauen können. PrestaShop hat kein natives Pixel, daher fügen Sie es mit einem Tracking-Modul hinzu. Mit Facebook Pixel geben Sie Ihre Pixel ID ein und aktivieren Browser-Tracking; das Modul feuert dann die Standard-Ecommerce-Events — PageView, ViewContent, AddToCart, InitiateCheckout, Search, AddToWishlist, CompleteRegistration und Purchase — mit einzelnen Schaltern, damit Sie bestimmte Events ein- oder ausschalten können. Für genaue Conversions trotz Browser- und Ad-Blocker-Verlusten aktivieren Sie zusätzlich die serverseitige Conversions API, die Purchase Events mit passender Event ID an Meta sendet, sodass Browser- und Server-Hits dedupliziert werden. Verifizieren Sie alles im Test-Tool von Metas Events Manager, bevor Sie Kampagnen starten, und stellen Sie sicher, dass Pixel Firing Ihr Cookie-Consent-Banner respektiert, damit Tracking nur nach Marketing Consent läuft.

Das Modul installiert sich mit ausgeschaltetem ENABLED und leerer PIXEL_ID, sodass kein Browser-Tracking startet, bis Sie es konfigurieren. Pixel IDs werden als nur Ziffern validiert. Die meisten Standard-Event-Schalter sind standardmäßig an, sobald das Modul selbst aktiviert ist, während CAPI_ENABLED standardmäßig aus ist und eine Pixel ID plus CAPI_ACCESS_TOKEN erfordert. Die Standard-Graph-API-Version im Modul ist v25.0, und ein optionaler Test Event Code kann während der Validierung in Meta Events Manager gesendet werden.

Consent wird geprüft, bevor das Tracking-Template gerendert wird. Wenn Cookies Revolution aktiv ist, liest das Modul den marketing-Wert aus mprcr_consent; wenn Lightweight Cookie Banner aktiv ist, liest es mprcookie_consent; wenn keines aktiv ist und Consent-Respect aktiviert ist, behandelt das Modul Marketing Consent als verfügbar. Mitarbeiter-Browsing kann ebenfalls ausgeschlossen werden. AddToCart wird über das PrestaShop-updateCart-Event getrackt, wenn verfügbar, mit Click-Fallbacks für ältere Themes. Purchase wird auf Order Confirmation mit einer deterministischen Order Event ID ausgegeben, und wenn CAPI konfiguriert ist, wird derselbe Purchase über die gemeinsame Conversion Queue in die Warteschlange gestellt und verarbeitet, einschließlich einer alle 300 Sekunden geplanten Cron-Aufgabe für Retry/Processing.

Ja, MPR FAQ kann Kundenfragen zur Prüfung sammeln. In PrestaShop speichern Pending-Question-Datensätze Name, E-Mail, Frage, Produkt oder FAQ-Kategorie, Status, optionale Admin-Antwort und Zeitstempel vor der Veröffentlichung.

Die Darstellung im Storefront wird uber den Hook displayMprSubtitle gesteuert. Der Resolver kann die aktuelle Produkt-, Kategorie-, CMS-, Hersteller- oder Lieferantenseite erkennen, und Templates konnen bei Bedarf auch eine explizite Produkt-ID ubergeben.

Ja, whitelisted IPs werden vor Bans geprüft und vom Ban Matcher nie blockiert. Das PrestaShop-Modul unterstützt Whitelist-Einträge nach exakter IP oder CIDR Range, mit shop-aware Filtering, sodass shop-spezifische Whitelist-Datensätze nur im relevanten Shop-Kontext gelten.

Die Whitelist ist IP-basiert, nicht länder- oder user-agent-basiert. Im Admin-Formular geben Sie entweder ein IP-Adressfeld oder eine CIDR Range ein, nicht beides. Das IP-Adressfeld ist für eine einzelne IP oder Wildcard wie 192.168.1.* dokumentiert; das CIDR-Feld erwartet Notation wie 192.168.1.0/24.

Wenn ein Request geprüft wird, ruft isBanned() zuerst isWhitelisted() auf. Wenn die Besucher-IP zu einer Whitelist-Zeile passt, gibt die Funktion sofort false zurück, und kein Country-, User-Agent-, Exact-IP- oder CIDR-Ban wird angewendet. Das ist nützlich für Office-, Entwickler-, Zahlungsprovider- oder Monitoring-IPs, die nicht durch breite Länder- oder Range-Regeln ausgesperrt werden dürfen.

• Storage: Whitelist-Zeilen speichern IP Address, CIDR, Label, Employee ID, Shop ID und Creation Date.
• Shop handling: Wenn Multishop aktiv ist, lädt die Whitelist-Query Zeilen für den aktuellen Shop und globale id_shop=0-Zeilen.
• Gotcha: Eine Whitelist hilft nur, wenn das Modul dieselbe echte Besucher-IP erkennt, die Sie gespeichert haben. Wenn ein Proxy oder CDN die von PrestaShop gesehene IP verändert, whitelisten Sie die Adresse, die PrestaShop tatsächlich empfängt.

PrestaShop hat keinen eingebauten Blog. Um Artikel, Guides und SEO-Inhalte zu veröffentlichen, fügen Sie daher ein Blog-Modul hinzu. Blog Revolution erstellt einen vollständigen Blog in Ihrem Shop: Es registriert dedizierte Routen für Blog-Index, einzelne Beiträge, Kategorien, Tags, Autoren, Monatsarchive, Suche und RSS-Feed und fügt Blöcke für Homepage, Seitenspalten, Footer, Produktseiten und kategorieartige Listings hinzu, damit Ihre neuesten Beiträge im gesamten Shop sichtbar werden. Da der Blog Ihr Theme, Design und Sprachsetup teilt, übernehmen Artikel automatisch Ihr Branding und mehrsprachige URLs. Ein Blog ist eine der wirksamsten PrestaShop-SEO-Investitionen: Er zielt auf Informationssuchen ab, die Ihre Produkt- und Kategorieseiten nicht abdecken können, baut interne Links zu diesen Seiten auf und gewinnt Backlinks. Planen Sie zuerst eine Kategoriestruktur, veröffentlichen Sie dann konsequent und verlinken Sie jeden Beitrag mit den relevanten Produkten.

Im Code ist das nicht nur ein CMS-Seiten-Wrapper. Das Modul erstellt eigene Tabellen für Beiträge, Beitragsübersetzungen, Kategorien, Tags, Autoren, Kommentare, Post-Product-Links, View-/Like-Tracking, Bilder, Gruppenbeschränkungen und Slug-Redirects. Beiträge haben SEO-Felder wie Meta Title, Meta Description, Meta Keywords und Canonical URL pro Sprache, und das Modul kann Open Graph-Daten, RSS-Autodiscovery, hreflang-Links und Previous/Next-Pagination-Links aus dem Header Hook ausgeben.

Das Standard-URL-Präfix ist blog, sodass das generierte Routenset Pfade wie /blog, /blog/tag/{rewrite}, /blog/author/{slug}, /blog/archive/{year}/{month}, /blog/search und /blog/rss enthält. Die Defaults gehen außerdem von 12 Beiträgen pro Seite, einem dreispaltigen Grid, Kommentaren, Ratings, Excerpts, Autor-/Datum-/View-/Kommentar-Metadaten, Social Sharing, Schema, hreflang, Open Graph und aktiviertem RSS aus. Das gibt Ihnen eine vollständige Publishing-Oberfläche, aber Sie sollten dennoch redaktionelle Regeln definieren: welche Beiträge auf Produkte verlinken, welche Kategorien kommerziellen Begriffen zugeordnet werden und welche alten URLs redirecten sollten statt 404 zu liefern.

Canonical Tags teilen Google mit, welche Version einer Seite das Original ist, und verhindern Duplicate-Content-Probleme durch Filter, Pagination und nahezu identische Produkte. PrestaShop setzt Canonicals automatisch, bietet aber keine Möglichkeit, sie pro Seite zu überschreiben. Um für ein bestimmtes Produkt, eine Kategorie, CMS-Seite, einen Hersteller oder Lieferanten ein Custom Canonical zu setzen, verwenden Sie Product Canonical Manager: Erstellen Sie eine Regel für die Zielentität, geben Sie die URL ein, die Suchmaschinen als maßgeblich werten sollen, und speichern Sie bei Bedarf je Shopsprache einen anderen Wert. Greifen Sie dazu, wenn mehrere Produkte Varianten eines Masters sind, wenn eine CMS-Seite einen Blogartikel wiedergibt oder wenn eine Kampagnen-URL in die saubere Produktseite konsolidieren soll. Wie Canonicals, URLs, Schema und Sitemaps zusammenpassen, erklärt unser PrestaShop SEO guide.

Das Modul speichert Regeln in einer dedizierten Tabelle mprcanonical_rule und unterstützt die Entity Types product, category, cms, manufacturer und supplier. Jede Regel hat eine Action: override ersetzt ein bestehendes Canonical durch die Entity URL, add_missing fügt nur eines ein, wenn die Seite noch kein Canonical hat, und custom verwendet die mehrsprachige Custom URL, die auf der Regel gespeichert ist. Regeln können außerdem noindex und nofollow setzen.

Für Produktregeln kann der Resolver ein bestimmtes Produkt, alle Produkte, Produkte nach Kategorie, Hersteller oder Lieferant matchen und unterstützt Selector Exclusions. Wenn mehrere Regeln matchen, sortiert die Abfrage nach priority DESC, sodass die höher priorisierte Regel für die Canonical URL gewinnt, während noindex/nofollow-Flags akkumulieren können. Der Output Hook bearbeitet den fertigen HTML Head, sodass er bestehende Canonical Tags ersetzen, Robots Directives hinzufügen, hreflang-Links bei Aktivierung hinzufügen und generierte URLs mit konfiguriertem Parameter-Stripping, Kleinschreibung und optionalem Trailing-Slash-Handling normalisieren kann.

Ja, der Dry-run-Modus zeigt Cleanup-Ergebnisse vor dem Löschen an. Das Modul aktiviert Dry-run standardmäßig, nutzt aufgabenspezifische Batchgrößen und konfigurierbare Sicherheitslimits und protokolliert Verlauf, Auslöser, betroffene Zeilen, Dry-run-Status und Mitarbeiterkontext. So bleibt die Einrichtung an Moduleinstellungen und das Verhalten im PrestaShop-Frontend gebunden.

Ja, es unterstuetzt Google Consent Mode v2, wenn die Option aktiv ist. Das Modul schreibt vor den Tags einen Standard-Consent-Befehl und aktualisiert ad_storage, ad_user_data, ad_personalization und analytics_storage, nachdem der Kunde Cookies in PrestaShop akzeptiert oder ablehnt.

Ja, es kann passende Skripte blockieren, bis Zustimmung erteilt wurde. Bei aktiviertem Script-Blocking schreibt der Output-Hook passende Script-Tags zu type text/plain mit Kategorie-Metadaten um, und das Front-JavaScript stellt nur Skripte wieder her, deren Kategorie erlaubt ist.

Ja, das Modul bietet einen Back-Office-Arbeitsbereich fuer geplante Aufgaben. Es kann Tasks von Modulen mit gemeinsamem CronTrait auflisten, Testlaeufe starten, Tasks aktivieren oder deaktivieren, Zeitplaene bearbeiten, eigene Tasks loeschen, Logs einsehen und Massen-Frequenzaenderungen anwenden.

Ja, der Admin-Arbeitsbereich zeigt Zählungen, bevor Bereinigungen laufen. In PrestaShop enthält jede Aufgabe eine Count-Abfrage, und das Template zeigt Gesamtzahl sowie Einzelzahlen, damit der Händler eine Aufgabe oder alle Aktionen ausführen kann.

Das hängt davon ab, welchen Download Sie meinen:

• Ein lizenziertes Modul – ja. Lizenzierte Downloads sind an Ihren Shop gebunden; der Download-Controller prüft daher Lizenz-Inhaberschaft, Gültigkeit, verbleibende Download-Limits und ob der ausgewählte Shop der Lizenz zugewiesen ist, bevor er eine tokenisierte Download-URL ausstellt. Diese Bindung ist es, die eine bezahlte Lizenz bei ihrem Shop hält.
• Die kostenlose 30-Tage-Demo – nein. Die Angabe Ihrer E-Mail-Adresse und der Installations-Domain beim Download ist optional. Sie bringt Ihnen nur eines: Komfort später. Wenn Sie mit derselben E-Mail-Adresse kaufen, kann Ihr Shop die Aktivierung mit einem Klick anbieten. Lassen Sie die Angabe weg, fügen Sie stattdessen einfach einen Lizenzschlüssel ein.

Den gesamten Weg von der Testphase über die Aktivierung bis zum Support finden Sie unter So funktionieren Lizenzierung, Aktivierung & Support.

Flash Sales, saisonale Aktionen und zeitlich begrenzte Angebote funktionieren am besten, wenn sie automatisch starten und stoppen. Um zeitbasierte Rabatte in PrestaShop zu planen, verwenden Sie Smart Dynamic & Scheduled Discounts: Erstellen Sie Kampagnen mit Start- und Enddatum, und der Preis-Hook prüft aktives Zeitfenster, Produktscope, Kundengruppenzugriff und Nutzungslimits und wendet dann den besten berechtigten Rabatt auf den Produktpreis an, ohne manuelle Arbeit. Da der Rabatt zur Anzeige- und Checkout-Zeit berechnet wird, fallen Preise automatisch zurück, wenn das Zeitfenster schließt — Sie müssen nicht daran denken, einen Sale rückgängig zu machen. Nutzen Sie Kundengruppen-Scoping für member-only Deals und verlassen Sie sich auf die Best-Price-Logik, damit überlappende Kampagnen vorhersagbar bleiben. Zeigen Sie immer den Originalpreis neben dem Angebot, damit die Ersparnis sichtbar ist, und prüfen Sie, dass geplante Preise Ihre Mindestmargenregeln respektieren.

Das Kampagnenmodell unterstützt Kampagnentypen wie scheduled, recurring, flash sale, countdown, early bird und last chance, mit Discount Types percent, amount und fixed_price. Produktscope kann direkte Produkt-/Kombinationszuweisung, Kategorien mit optionalen Unterkategorien, Hersteller, Kundengruppen oder kein Scope sein; in letzterem Fall kann eine aktive Kampagne auf alle Produkte angewendet werden. Per-product Custom Discounts können den Kampagnenrabatt überschreiben, wenn die Produktzeile nicht den Default erbt.

Wiederkehrende Kampagnen fügen Schedule Rows mit täglichen, wöchentlichen, monatlichen oder benutzerdefinierten Fenstern, Start-/Endzeiten und einer Zeitzone hinzu. Nutzung wird pro Bestellung/Produkt/Kunde in mprdsd_campaign_usage verfolgt, und das Modul prüft Gesamtnutzungslimits, Limits pro Kunde und Mengenlimits pro Produkt, bevor ein Rabatt angewendet wird. Der Price Hook verwendet bewusst den aktuellen Preis, den PrestaShop übergibt, statt Product::getPrice() aufzurufen, weil das zurück in den Price Hook rekursieren würde. Er zieht dann den größten berechtigten Rabattbetrag vom aktuellen berechneten Preis ab und schreibt nie native Specific-Price-Zeilen. Deshalb verschwindet der Rabatt automatisch, wenn keine Kampagne aktiv ist.

Ja, das Modul kann Samstage und Sonntage überspringen, wenn der Wochenend-Ausschluss aktiv ist. Die PrestaShop-Berechnung zählt Wochenenden bei der Bearbeitungszeit nicht mit und verschiebt ein Enddatum am Wochenende auf Montag.

Ja, es unterstützt serverseitige Purchase-Events über die Meta Conversions API. In PrestaShop legt das Modul Kauf-Conversions in eine Queue, sendet sie an die konfigurierte Graph-API-Version und nutzt passende Event-IDs für Browser- und Server-Tracking.

Ja, zusätzliche freigegebene Antworten und Hilfreich-Votes werden unterstützt. In PrestaShop speichern Antwortdatensätze Autorentyp, Kunden- oder Mitarbeiterbezug, Status, Vote-Zähler und Inhalt, während Frage- und Antwortvotes separat nach Entität und IP erfasst werden.

Ja. Produkt-Untertitelregeln konnen alle Produkte, bestimmte Produkte, Produkte in Kategorien, Produkte nach Hersteller und Produkte nach Lieferant ansprechen. Ausschlussregeln konnen ausserdem einzelne Produkte oder Kategorie-Treffer aus einer breiteren Regel entfernen.

Ja, das Modul enthält einen automatischen Authentication-Ban-Pfad für fehlgeschlagene PrestaShop-Logins, aber er läuft nur, wenn der Failed-Login-Recorder des Moduls von der Authentication-Integration aufgerufen wird. Jeder aufgezeichnete Fehler speichert Besucher-IP, versuchte E-Mail, User Agent, Shop ID und Timestamp in mprceiipban_failed_logins.

Die zwei Einstellungen, die den Ban steuern, sind MPRCEIIPBAN_AUTOBAN_THRESHOLD und MPRCEIIPBAN_AUTOBAN_WINDOW. Die Installationsdefaults sind Threshold 0 und Window 60 Minuten, also ist Auto-Ban deaktiviert, bis ein positiver Threshold konfiguriert wird. Wenn die Zahl der Fehler von derselben IP innerhalb des konfigurierten Fensters den Threshold erreicht, fügt das Modul einen auth-Ban mit dem Reason Auto-banned: X failed login attempts in Y min und einem Ablauf eine Stunde in der Zukunft hinzu.

Ein auth-Ban ist enger als ein Full-Site-Ban: Er zielt auf authentication-related pages, während bestehende Full Bans weiterhin Vorrang haben. Da dieser Source Checkout Recorder und Ban-Logik enthält, aber keine konkrete Authentication-Override-Datei, prüfen Sie, dass Ihr installierter Build die Authentication-Integration enthält, bevor Sie sich darauf als einzigen Login-Schutz verlassen.

Der Threshold-Counter ist IP-basiert. Die fehlgeschlagene E-Mail wird zur Prüfung gespeichert, aber countRecentFailedLogins() zählt nur Zeilen mit derselben ip_address, die neuer als das konfigurierte Fenster sind; es zählt nicht getrennt pro versuchter E-Mail-Adresse. Der Auto-Ban-Check überspringt außerdem das Erstellen eines neuen temporären Auth-Bans, wenn die IP bereits unter einem Full Ban steht.

• To enable it: Setzen Sie AUTOBAN_THRESHOLD auf eine positive Zahl wie 5 und lassen oder ändern Sie AUTOBAN_WINDOW in Minuten.
• What is created: Eine aktive Zeile in mprceiipban_banned mit ban_type=auth, der Besucher-IP und einer einstündigen date_expiry.
• Cleanup: Failed-Login-Zeilen werden vom Purge-Pfad des Moduls abgedeckt, der die konfigurierten Log-Retention-Tage nutzt.

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

Fotobewertungen lassen Käufer echte Produktbilder an ihre Bewertungen anhängen. Das baut Vertrauen auf und ergänzt Ihre Produktseiten um einzigartige, keywordreiche Inhalte. PrestaShop hat keine eingebaute Image-Review-Funktion, daher fügen Sie sie mit einem Bewertungsmodul hinzu. Mit Reviews & Ratings aktivieren Sie Bild-Uploads in den Review-Einstellungen: Das Formular akzeptiert dann JPEG-, PNG- und WebP-Dateien, erzwingt Ihre maximale Dateigröße und Bildanzahl, verkleinert große Uploads automatisch, erzeugt Thumbnails und hängt die Bilder an den gespeicherten Review-Datensatz. Genehmigte Fotobewertungen werden neben dem Produkt angezeigt und speisen Star-Rating Rich Results. Setzen Sie ein sinnvolles Limit - zum Beispiel 3-5 Bilder pro Bewertung - und lassen Sie Moderation aktiviert, damit nur echte, thematisch passende Fotos live gehen. Kundenfotos reduzieren auch Retouren, weil sie vor dem Kauf realistische Erwartungen setzen.

In der lokalen Quelle lebt diese Funktion im Modul mprcomments. Bild-Uploads werden durch ALLOW_IMAGES aktiviert, mit Defaults von 3 Bildern pro Bewertung und 2 MB pro Bild. Das Produktbewertungs-Template verwendet ein Multiple-File-Input namens review_images[] und akzeptiert image/jpeg, image/png und image/webp. Der Uploader validiert MIME Type, Dateigröße und Bilddimensionen, verkleinert dann große Bilder auf maximal 1200 mal 1200 Pixel und erstellt 150 mal 150 Thumbnails.

Die Bewertung wird zuerst mit Status pending oder approved gespeichert, abhängig von den Moderationseinstellungen, und anschließend werden Bild-Uploads sofort gegen diese gespeicherte Review ID verarbeitet. Freigabe steuert öffentliche Sichtbarkeit, nicht Bildanhang. Normale Review-Validierung gilt zuerst: Der Bewertungsinhalt muss die Mindestlänge erfüllen, das Rating muss zwischen 1 und 5 liegen, Gäste werden blockiert, sofern nicht erlaubt, doppelte Kundenbewertungen werden geprüft, und Moderation kann die Bewertung pending lassen, statt sie sofort öffentlich zu machen. Structured Data basiert bewusst auf nativen Produktbewertungen; importierte Unternehmensbewertungen sind aus Product Schema ausgeschlossen, und der Schema Renderer begrenzt eingebettete Review Items, während er weiterhin Aggregate Rating ausgibt, wenn native Bewertungen existieren.

PrestaShop liefert eine feste Kontaktseite mit, was nicht ausreicht, wenn Sie Angebotsanfragen, B2B-Anfragen, Support Intake oder Event-Anmeldungen benötigen. Um eigene Formulare zu bauen, verwenden Sie Better Contact Form: Es speichert Formulare und ihre Felder in dedizierten Tabellen und rendert sie über einen Modul-Controller oder Hook, mit funktionierendem Submitted-Value-Handling für Text-, E-Mail-, Telefon-, Textarea-, Select-, Checkbox-, URL- und Number-Felder. Sie können mehrere Formulare für unterschiedliche Zwecke erstellen, sie auf jeder Seite platzieren und strukturierte Submissions statt Freitext-E-Mails sammeln. Halten Sie jedes Formular kurz, markieren Sie Pflichtfelder klar und ergänzen Sie Anti-Spam-Schutz. Für GDPR fügen Sie eine Consent-Checkbox und einen Link zu Ihrer Datenschutzerklärung hinzu, damit Anfragedaten rechtmäßig erhoben werden.

Das Template hat außerdem einen file-Input-Zweig, aber der aktuelle Submission Processor liest Feldwerte über Tools::getValue() und behandelt $_FILES nicht. Das bedeutet, File Fields können gerendert werden, aber hochgeladene Dateien werden in der aktuellen Implementierung nicht als Submitted Field Values persistiert. Verlassen Sie sich nicht auf File Upload Collection, sofern kein File Handling ergänzt wird.

Formulare, Felder, Submissions und einzelne Submission Values werden in getrennten Tabellen gespeichert, sodass eine Anfrage sowohl eine Summary Row als auch strukturierte Felddaten behält. Der Renderer kann ein bestimmtes Formular oder das aktive Standardformular wählen, gibt nichts zurück, wenn ein Formular inaktiv ist oder keine Felder hat, und füllt Name/E-Mail eingeloggter Kunden vor, wenn verfügbar.

Submission Processing prüft, ob der Submit Button gepostet wurde, führt Pflichtfeldprüfungen, Typvalidierung, Select-Option-Validierung, optionale PrestaShop-Validierungsmethoden, GDPR-Checkbox-Erzwingung, Spam-Erkennung und Datenbankpersistenz durch. Der versteckte _mpr_ft-Wert ist kein CSRF Token; er ist ein Base64-Zeitstempel, der von der Timing-Anti-Spam-Prüfung verwendet wird. Honeypot- und Time-Check-Anti-Spam sind standardmäßig aktiviert, mit einer Standard-Mindest-Submit-Zeit von 3 Sekunden. Spam-Submissions werden trotzdem mit is_spam und spam_reason gespeichert, aber Admin-/Kunden-E-Mails werden nur für Nicht-Spam-Submissions gesendet. Das gibt Ihnen einen Audit Trail, ohne offensichtlichen Bot-Traffic Benachrichtigungen auslösen zu lassen.

Ja, Einwilligungen koennen protokolliert werden, wenn Logging aktiviert ist. Der PrestaShop-AJAX-Controller speichert Consent-Map, Quelle und Consent-Version, waehrend das Log-Modell Besucher-, IP- und User-Agent-Kennungen hasht, statt sie im Klartext zu speichern.

Sie koennen Criteo OneTag zu PrestaShop hinzufuegen, indem Sie eine numerische Criteo Partner ID konfigurieren und Browser-Tracking aktivieren. Das Modul baut dann OneTag-Events im Header fuer unterstuetzte E-Commerce-Seiten und bleibt inaktiv, wenn die Partner ID fehlt oder ungueltig ist.

Ja, eigene Cron-Aufgaben koennen im Task-Controller hinzugefuegt werden. Das PrestaShop-Adminformular validiert Besitzer-Modul, Zeitplan, Kontext und Executor-Typ und unterstuetzt URL-, Callable- und Command-Tasks, wobei Commands auf Cron- oder explizite Admin-Test-Kontexte begrenzt sind.

In PrestaShop ist die H1 der Kategorieseite der Kategoriename. Wenn Sie die Überschrift für SEO ändern, ändern sich normalerweise auch Menülables und Breadcrumbs — was Sie meistens nicht möchten. Die Lösung ist, die H1 unabhängig zu überschreiben. Mit Custom Category H1 speichern Sie pro Kategorie einen separaten H1-Wert, und das Modul tauscht ihn über PrestaShop-Hooks in die Kategorieseite ein, während der Name des Category-Objekts (und damit Navigation und Breadcrumbs) unverändert bleibt. So können Sie eine keywordreiche Überschrift wie "Waterproof Shower Trays for Wet Rooms" ansprechen, während das Menü weiterhin kurz "Shower Trays" liest. Beachten Sie, dass Root-Kategorien bewusst ausgeschlossen sind, weil sie keine normale Storefront-Kategorieseite rendern, auf der eine käufersichtbare H1 gelten würde. Verwenden Sie eine klare, eindeutige H1 pro Kategorie und halten Sie sie mit dem Title Tag dieser Seite abgestimmt — siehe unseren PrestaShop SEO guide.

Das Modul speichert Overrides in dedizierten Tabellen für Override Rows, Sprachwerte und Kategoriezuweisungen. Die Defaults sind aktiviert, zeigen das Kategorie-Edit-Feld, ersetzen den Kategorieseitennamen im gefilterten Kategorieinhalt, wenden denselben Wert auf Product-Listing-Labels an, fallen auf die Standardsprache zurück, fallen von einem shopspezifischen Wert auf einen All-Shops-Wert zurück, entfernen HTML-Tags und normalisieren Whitespace. Parent-Category-Fallback existiert, ist aber standardmäßig deaktiviert, um doppelte Überschriften über Child-Kategorien zu vermeiden.

Für Bulk-SEO-Arbeit kann ein Override mehreren Kategorien zugewiesen werden. Wenn ein Händler später eine Kategorie direkt bearbeitet und diese Kategorie zu einem Shared Override gehört, trennt der Code diese eine Kategorie ab und erstellt einen category-local Override, während der Shared Override für die anderen bestehen bleibt. Der H1-Wert kann Platzhalter wie {category_name}, {nb_products}, {page}, {page_label}, {shop_name} und {lang} verwenden. Pagination kann außerdem automatisch ein Page Label anhängen, wenn aktiviert. Das Modul ändert die gerenderten Kategoriedaten; es benennt den gespeicherten PrestaShop-Kategoriedatensatz nicht um.

Sie koennen Besucher-IP und Geraeteinformationen mit diesem PrestaShop-Modul erfassen, wenn die Sammlung aktiviert ist. Es speichert Kunden- oder Gast-ID, Shop-ID, IP-Adresse, Laenderdaten, analysierte Geraetedetails sowie optionale User-Agent-, Betriebssystem-, Browser- und Bildschirmaufloesungsfelder.

Kunden können Projektgalerien über den Front-Office-Einreichungsablauf des Moduls senden. In PrestaShop speichert die Showcase-Funktion Projekte, mehrsprachige Titel und Beschreibungen, Bilder, Kategorien und Moderationsstatus mit Standardlimits von 20 Bildern und 5 MB je Bild.

Das Modul bleibt installiert, aber hookDisplayHeader() gibt nichts zurück, da isActive() die Brand ID voraussetzt. Der Hinweis zur erforderlichen Konfiguration informiert Ihr Team zudem darüber, dass das Tracking inaktiv bleibt, bis die Brand ID hinterlegt wird.

Nein. Das Modul prüft, ob mprcheckoutrevolution installiert und aktiviert ist. Wenn es aktiv ist, überlässt dieses Modul ihm die Oberfläche zur Bestellbearbeitung, anstatt die Hooks für die Bestellbearbeitung selbst zu verarbeiten.

Der Generator prüft das Referenzprotokoll des Moduls, die native Tabelle orders sowie die Referenzen in order_payment. Er probiert bis zu 10 Kandidaten aus, bevor er einen Fehler protokolliert und aufgibt.

Das Formular bietet Komma, Semikolon, Tabulator und Pipe als Trennzeichen. Der Controller löst die Option tab in ein echtes Tabulatorzeichen auf, bevor er die CSV streamt.

Das Schema enthält Tabellen für Teams, Team-Mitarbeiter, Team-Status-Zuordnungen, Workflow-Status und Übersetzungen, Bestellhistorie, Bestellkommentare, Erinnerungen, Benachrichtigungen und Mitarbeiterpräferenzen für Benachrichtigungen.

Es registriert displayHeader, displayOrderConfirmation, actionValidateOrder und actionCustomerAccountAdd. Diese Hooks rendern Browser-Tracking und stellen Conversion-Daten zu Bestellungen oder Registrierungen in die Warteschlange.

Nein. Der Erkennungscode prüft, ob die Produktreferenz mit mpr-pack- beginnt. Pack-Inhalte werden anschließend aus der moduleigenen Tabelle mpr_pack_content gelesen.

Der Hook prüft actionDispatcherBefore und behandelt nur Dispatcher::FC_FRONT und Dispatcher::FC_MODULE. Back Office-Dispatches werden ignoriert.

hookPaymentOptions() benötigt ein aktives Modul, aktivierte Konfiguration, einen eingeloggten Kunden, mindestens ein aktives Zahlungsziel, das den Kundengruppen zugewiesen ist, und ausreichend Kredit für die aktuelle Warenkorbsumme.

Der Resolver sortiert aktive Treffer nach Prioritat. Im Einzelmodus gibt er den Untertitel mit der hochsten Prioritat zuruck; im Alle-Modus gibt er die sortierte Liste zuruck, damit das Template mehr als einen Untertitel ausgeben kann.

Es erkennt das Besucherland in einer festen Fallback-Reihenfolge. Das Modul liest zuerst Cloudflares HTTP_CF_IPCOUNTRY-Header, wenn er existiert und nicht XX ist. Wenn dieser nicht verfügbar ist, versucht es PrestaShop GeoIP über GeoIp::getCountryByAddr($ip) und konvertiert den zurückgegebenen Ländernamen wieder zu einem ISO-Code. Wenn GeoIP nicht verfügbar ist, prüft es zuletzt das PrestaShop-Kontext-Cookie 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.

Das bedeutet: Länder-Bans hängen vom Signal ab, das für diesen Request verfügbar ist. Wenn Sie sich auf Cloudflare-Ländererkennung verlassen, stellen Sie sicher, dass Shop-Traffic tatsächlich über Cloudflare bei PrestaShop ankommt, damit der Header vorhanden ist.

Die für GeoIP genutzte Besucher-IP kommt aus Tools::getRemoteAddr(), wenn PrestaShop sie liefert. Das Modul hat eine Fallback-Kette für HTTP_CF_CONNECTING_IP, HTTP_X_REAL_IP, den ersten Wert aus HTTP_X_FORWARDED_FOR und dann REMOTE_ADDR. Das ist wichtig, weil GeoIP-Qualität von der echten Client-IP abhängt, nicht von der IP eines Zwischen-Proxys.

Ein Länder-Ban matcht nur, wenn der aktuelle Request einen nicht-leeren Country Code hat. Wenn Cloudflare XX sendet, GeoIP fehlt, die Country-Name-Lookup das GeoIP-Ergebnis nicht auf einen ISO-Code mappen kann und das Cookie fehlt, feuern country-only Regeln für diesen Request nicht. VPNs, Proxies und CDN-Konfiguration können außerdem dazu führen, dass das erkannte Land vom physischen Standort des Käufers abweicht.

Nein. S2S_ENABLED ist standardmäßig false. Das Readiness-Panel behandelt S2S ausdrücklich als optional, und Browser-Pixel-Tracking kann mit gültiger Marketer ID und aktiviertem Browser-Tracking laufen.

Ja, das Modul enthält Import- und Exportwerkzeuge für Bloginhalte im PrestaShop Back Office. Der PrestaShop-Admin-Controller kann WordPress WXR XML inklusive optionaler Kommentare importieren und Blogdaten über den BlogExporter Service als XML oder JSON exportieren.

Der eigene Checkout-Controller leitet Kunden zur nativen PrestaShop-Bestellseite zurück, wenn der One Page Checkout deaktiviert ist. So erzwingt das Modul seinen Checkout-Fluss nicht, wenn die Einstellung one_page_checkout_enabled in der Konfiguration ausgeschaltet ist. So bleibt die Einrichtung an Moduleinstellungen und das Verhalten im PrestaShop-Frontend gebunden.

Das Banner erscheint erneut, wenn das Consent-Cookie fehlt oder abgelaufen ist. Im PrestaShop-Frontend liest das JavaScript mprcookie_consent und blendet das Banner fuer wiederkehrende Kunden aus; die konfigurierte Ablaufzeit steuert die Speicherdauer, standardmaessig 365 Tage.

Ja, das Modul hat einen Schalter fuer mobile Anzeige. Bevor das Crisp-Widget gerendert wird, prueft der PrestaShop-Guard die Einstellung SHOW_MOBILE und den aktuellen Geraetekontext; ist mobile Anzeige deaktiviert und der Kontext mobil, wird kein Crisp-Skript ausgegeben.

Der Front Controller akzeptiert einen Eventnamen und JSON-Parameter, lehnt Payloads über 8192 Zeichen ab, behält höchstens 50 normalisierte Schlüssel pro Ebene, begrenzt die Verschachtelungstiefe und kürzt String-Werte auf 512 Zeichen.

Nein, Datei-Uploads werden vom aktuellen Einsende-Code nicht verarbeitet. Die Admin-Feldliste enthaelt zwar einen Datei-Input, aber der Prozessor liest Werte mit Tools::getValue und verarbeitet weder das PHP-Files-Array noch Speicherpfade oder E-Mail-Anhaenge.

Ja, das Modul enthaelt einen Storefront-Cookie-Scanner. Er kann eine PrestaShop-URL crawlen, Set-Cookie-Header und inline document.cookie-Zuweisungen pruefen, neu gefundene nicht kategorisierte Cookies speichern und Kategorien fuer bekannte Muster wie Analyse, Marketing und funktionale Cookies vorschlagen.

Ja, Haendler koennen eigene Trigger-Regeln fuer unterstuetzte Criteo-Events definieren. Die PrestaShop-Konfiguration akzeptiert validierte JSON-Regeln mit Klick-, URL-, Controller- oder DOM-Event-Triggern und normalisiert Eventnamen auf das von Criteo unterstuetzte OneTag-Vokabular.

Nein, die Deinstallation entfernt die gemeinsamen Cron-Tabellen nicht. Der PrestaShop-Uninstall-Pfad entfernt das Admin-Menue des Moduls und deregistriert eigene Tasks, behaelt die Cron-Tabellen aber bewusst, weil andere MPR-Module dieselbe Scheduled-Task-Infrastruktur nutzen koennen.

Nein, Root-Kategorien werden von der Speicherlogik fuer Overrides abgelehnt. Der PrestaShop-Admin-Controller prueft, dass ausgewaehlte Kategorien Storefront-Kategorien sind, weil Root-Kategorien keine normalen Storefront-Kategorieseiten rendern, auf denen ein sichtbarer H1-Override greifen wuerde.

Ja, es kann User-Agent-Muster als Sperrziele abgleichen. Im PrestaShop-Admin kann eine Sperrregel Klartext fuer eine nicht case-sensitive Contains-Pruefung oder eine Regex in Schraegstrichen nutzen und diese Regel mit IP-, CIDR- oder Laenderfiltern kombinieren.

Ja. Der Validator akzeptiert Ziffern, die durch Kommas oder Leerraum getrennt sind, bis zu den konfigurierten Längenregeln; so können mehrere numerische IDs im Feld Marketer ID gespeichert werden.

Das Diagnosepanel enthält eine Aktion Retry failed events. Sie ruft den gemeinsamen Queue-Reset für dieses Modul und den Provider outbrain auf und setzt fehlgeschlagene Events wieder auf den Status pending.

Das Modul speichert Produkt-IDs im Browser-Cookie mprrecent_ids des Besuchers. Das Cookie wird mit Pfad /, 30 Tagen Laufzeit und SameSite=Lax geschrieben.

Nein. Der AJAX-Controller erstellt fur jede angeforderte ID ein Product-Objekt und uberspringt Eintrage, die nicht geladen oder nicht aktiv sind, bevor Produktkartendaten zuruckgegeben werden.

Die AJAX-Antwort enthalt den Namen jedes Produkts, die Produkt-URL, die Coverbild-URL mit home_default und einen formatierten Preis. Das Front-Script rendert diese Werte als kompakte Produktkarten.

Es ist kein Konto erforderlich, und die Source-Beschreibung sagt, dass es für Gäste, eingeloggte Kunden und wiederkehrende Besucher funktioniert. Es merkt sich aktuelle Produktseiten in einem Browser-Cookie, statt eine PrestaShop-User-History-Tabelle zu füllen. Sie sollten Cookie-Nutzung trotzdem in Ihren Datenschutz- oder Cookie-Informationen beschreiben, wo die rechtlichen Anforderungen Ihres Stores das verlangen.

Das Storefront-Script nutzt ein Cookie namens mprrecent_ids. Auf Produktseiten setzt es die aktuelle Product ID an den Anfang der Liste, entfernt Duplikate, begrenzt die Liste auf das konfigurierte Maximum und schreibt das Cookie für 30 Tage mit SameSite=Lax. Der Installationsdefault ist MAX_PRODUCTS=8, und der Standard-Display-Hook ist displayFooterProduct.

Wenn das Widget gerendert wird, liest der Browser das Cookie und postet die Product-ID-Liste an den Modul-AJAX-Controller. Der Controller bereinigt die IDs mit intval, entfernt leere Werte, begrenzt den Request auf 20 IDs und gibt nur aktive Produkte zurück. Die Antwort enthält Product ID, Name, URL, Cover Image und formatierten Preis, damit das Widget die Recent-Products-Liste zeichnen kann.

Das Modul baut also kein serverseitiges Browsing-Profil, das an ein Kundenkonto gebunden ist. Der Server erhält während des AJAX-Lookups trotzdem die aktuellen Product IDs, und die IDs werden im Browser-Cookie des Besuchers gespeichert. Aus Sicht eines Datenschutzhinweises bleibt die Funktion daher cookie-basiertes Tracking.

Geben Sie die AdRoll Advertiser ID aus adroll_adv_id ein, geben Sie die Pixel ID aus adroll_pix_id ein, aktivieren Sie Browser Tracking und wählen Sie die Events, die Sie senden möchten. Beide IDs dürfen nur Buchstaben, Zahlen, Unterstriche oder Bindestriche enthalten, und Tracking bleibt inaktiv, bis die IDs gültig und das Modul aktiviert ist.

• Required setup: Advertiser ID, Pixel ID und Browser Tracking enabled.
• Page journey events: Page View, Product View, Checkout Start und Search.
• Interaction events: Add to Cart, Add to Wishlist, Signup und konfigurierte Custom Browser Events.
• Purchase event: wird auf Order Confirmation gesendet, wenn Purchase Tracking aktiviert ist.

Das Modul ist eine Browser-Pixel-Integration. Seine eigene Demo-Metadata markiert AdRoll server-side purchase als unavailable, weil öffentlicher AdRoll-S2S-Zugang in diesem Modul nicht als stabiler Token-/Endpoint-Flow bereitgestellt wird.

Bei Installation ist Browser Tracking selbst standardmäßig deaktiviert, während die Standard-Event-Toggles standardmäßig aktiviert sind. So kann ein Händler zuerst IDs konfigurieren und Tracking dann aktivieren, wenn alles bereit ist. Employee Exclusion und Marketing-Consent Respect sind beide standardmäßig aktiviert, sodass Back-Office-Mitarbeiter, die die Storefront ansehen, und Besucher ohne unterstützten Marketing-Consent unterdrückt werden können, bevor Events gesendet werden.

Der Header Hook bereitet die AdRoll Queue vor, setzt window.adroll_adv_id, window.adroll_pix_id und window.adroll_version='2.0' und lädt dann https://s.adroll.com/j/roundtrip.js. Header Events werden serverseitig für Page View, Product View, Checkout Start, Search und Signup gebaut, während Add-to-cart- und Wishlist-Events in JavaScript an PrestaShop-Events oder übliche Button-Selektoren gebunden werden.

Custom Browser Events sind optional und standardmäßig deaktiviert. Wenn aktiviert, muss JSON ein Array oder ein Objekt mit einem events-Array sein. Eventnamen sind auf Buchstaben, Zahlen, Unterstriche und Bindestriche begrenzt, mit 64 Zeichen Limit, und dieses Modul begrenzt Custom Events auf 15 verschiedene Eventnamen. Unterstützte Trigger sind click, url, controller und event.

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

Ja, Purchase Tracking sendet Bestellwert und Währung von der PrestaShop-Order-Confirmation-Seite. Das Modul baut außerdem Item Count, Order Reference, Product IDs, Names, Categories, Prices und Quantities und sendet das Purchase Event über den Browser Pixel, wenn Purchase Tracking aktiviert ist.

Der Order-Confirmation-Hook prüft zuerst das normale Tracking Gate: Das Modul muss aktiv sein, die IDs müssen gültig sein, Employee Exclusion darf den Request nicht blockieren, Marketing Consent muss bestehen, wenn aktiviert, und TRACK_PURCHASE muss an sein. Dann akzeptiert er entweder order oder objOrder aus den PrestaShop-Hook-Parametern und baut den Purchase Payload aus dieser geladenen Bestellung.

Das Value Mapping ist ausdrücklich. Common Conversion Data wird in AdRoll-artige Parameter konvertiert: value wird conversion_value, currency wird adroll_currency, num_items bleibt Item Count, order_id wird auf die PrestaShop Order Reference gesetzt, und Product Data wird product_id, content_ids und ein products-Array mit Item ID, Name, Price und Quantity, wo verfügbar.

Das Event bleibt browserseitig. Das Template ruft window.mpradrollTrack('purchase', params, 'Order confirmation') auf, wenn das Header-Script vorhanden ist, oder fällt auf window.__adroll.track/window.adroll.track zurück. Wenn AdRolls Legacy-Funktion record_user existiert, ruft das Template auch diese auf, aber das Modul sendet keinen Server-to-Server-Purchase-Request.

Ja. Wenn MPRADROLLPIXEL_RESPECT_CONSENT aktiviert ist, prüft das Modul unterstützte Cookie-Consent-Module, bevor es AdRoll Tracking rendert oder auslöst. Mit mprcookiesrevolution ist Marketing Consent nur granted, wenn das mprcr_consent-Cookie marketing:1 enthält. Mit mprcookiebanner ist Consent granted, wenn mprcookie_consent=granted. Wenn das relevante Cookie fehlt, fällt das Modul auf den DEFAULT_CONSENT-Wert dieses Consent-Moduls zurück.

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

Wenn kein unterstütztes Consent-Modul aktiv ist, blockiert die Consent-Prüfung Tracking nicht. Employee Exclusion kann Tracking weiterhin separat unterdrücken, wenn MPRADROLLPIXEL_EXCLUDE_EMPLOYEES aktiviert ist.

Die Installationsdefaults sind privacy-orientiert: RESPECT_CONSENT=1 und EXCLUDE_EMPLOYEES=1. Die serverseitige Methode canTrack() gibt false zurück, wenn das Modul inaktiv ist, ein gültiger Employee Context im Front Office browst oder Marketing Consent nach den unterstützten Consent-Modul-Prüfungen nicht granted ist.

Das Browser-Template führt ebenfalls eine Consent-Prüfung aus, bevor AdRoll geladen wird. Wenn ein unterstütztes Consent-Modul aktiv ist, prüft es window.MPRCR.isGranted('marketing'), wenn verfügbar, dann dieselben zwei Cookies. Wenn diese clientseitige Prüfung fehlschlägt, kehrt das Script zurück, bevor roundtrip.js geladen oder queued Events gefeuert werden. Ein praktischer Gotcha ist, dass die clientseitige Prüfung den serverseitigen DEFAULT_CONSENT-Wert nicht kennt. Ein Setup, das sich auf default granted Consent ohne Consent Cookie verlässt, sollte daher im Browser getestet werden.

Nein, dieses Modul sendet AdRoll Events über den Browser Pixel, nicht über eine öffentliche serverseitige API. Der PrestaShop-Code enthält einen Demo-Hinweis, dass AdRoll S2S support-gated Beta ist; produktiv lädt das Modul roundtrip.js und sendet nur Browser Events.

Verwenden Sie dieses Modul, um separate Display Names für PrestaShop-CMS-Seiten zu setzen. Es speichert einen Display Name pro id_cms, Sprache und Shop in seiner eigenen mprcmsnames-Tabelle, sodass der native CMS-Datensatz und sein SEO-meta_title in der CMS-Tabelle nicht umgeschrieben werden.

• Beispiel: Lassen Sie den CMS-Seiten-Meta-Title für SEO als Terms and Conditions | My Shop.
• Öffnen Sie den CMS Display Names-Bildschirm des Moduls und finden Sie diese CMS-Seitenzeile nach ID und bestehendem Meta Title.
• Geben Sie einen kürzeren Display Name wie Terms im Display Name-Feld ein und speichern Sie.
• Im Front Office bekommt die CMS-Seitenüberschrift den Display Name über filterCmsContent, und CMS-Links, die zu PrestaShops cms-page-link-Pattern passen, werden im finalen HTML ersetzt.
• Wenn Sie das Display-Name-Feld leeren, löscht das Modul seine Custom-Zeile für diese CMS-Seite und der Shop fällt auf den ursprünglichen CMS-meta_title zurück.

Die praktische Trennung lautet also: Nutzen Sie den nativen CMS Title für Search Snippets und Browser-Title-Verhalten, und nutzen Sie dieses Modul für kürzere Seitenüberschriften, Footer-Links und Menülabels, die Käufer tatsächlich scannen.

Das Modul hat zwei Front-Office-Pfade. Erstens ändert filterCmsContent das CMS-Objekt, das an das Seitentemplate übergeben wird, indem es meta_title durch den gespeicherten Display Name für aktuelle Sprache und Shop ersetzt. Zweitens bearbeitet actionOutputHTMLBefore das finale HTML für passende CMS-Links, bevor die Antwort gesendet wird.

Der Source-Kommentar ist ausdrücklich, dass das echte HTML-<title>-Tag unberührt bleibt, weil PrestaShop es über Meta::getMetaTags() mit seinem eigenen SQL-Pfad baut. Deshalb kann dieses Modul sichtbare Namen kürzen, ohne den von PrestaShop gespeicherten CMS-SEO-Title zu überschreiben.

Theme-Markup ist weiterhin wichtig. Link-Relabeling läuft nur auf Anchors, die zum erwarteten CMS-Link-Pattern des Moduls passen, mit CMS Page ID in link-cms-page-{id}-... und dem exakten cms-page-link-Class-Attribut in der von der Regex erwarteten Reihenfolge. Wenn ein Theme CMS-Menüs mit anderem Markup oder verschachteltem HTML innerhalb des Anchor-Texts baut, kann die Überschrift weiterhin geändert werden, aber der Linktext möglicherweise nicht ersetzt werden.

Nein, es schreibt das HTML-title-Tag nicht um. Das Modul ist bewusst auf sichtbaren CMS-Inhalt und gerenderten CMS-Linktext begrenzt, sodass PrestaShop weiterhin den ursprünglichen CMS Meta Title für Page Head und Search Snippets verwenden kann.

Der Source-Kommentar sagt, dass das <title>-Tag durch PrestaShops Meta::getMetaTags()-Pfad gebaut wird und unberührt bleibt. Das Modul aktualisiert die native CMS-Tabelle nicht, hängt sich nicht in Meta-Tag-Generierung ein und schreibt keinen neuen SEO Title zurück nach PrestaShop.

Was es ändern kann, ist das CMS-Objekt, das durch filterCmsContent läuft. Wenn das Seitentemplate den meta_title dieses gefilterten CMS-Objekts als sichtbare Überschrift nutzt, sehen Käufer den kürzeren Display Name auf der Seite. Separat kann actionOutputHTMLBefore passenden CMS-Linktext im finalen HTML ersetzen. Das sind Änderungen an sichtbarem Inhalt, keine Head-Tag-Änderungen.

Für SEO-Arbeit bearbeiten Sie weiterhin den echten CMS Meta Title in der nativen PrestaShop-CMS-Seite. Nutzen Sie dieses Modul, wenn der SEO Title zu lang für Menüs, Footer, Breadcrumbs oder On-page-Headings ist.

Es benennt CMS-Links um, die PrestaShops erwartetem CMS-Link-Markup entsprechen. Der Output-Hook sucht nach einem Anchor, dessen id mit link-cms-page-{id}- beginnt und dessen Klasse cms-page-link ist, und ersetzt dann den reinen Linktext durch den gespeicherten Display Name für aktuelle Sprache und Shop.

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

Dieses Pattern ist wichtig für angepasste Themes: Wenn der CMS-Link eine andere Klasse hat, keine link-cms-page-...-ID hat, die Klasse vor der ID im vom Modul anvisierten Markup erscheint oder das Label aus verschachteltem HTML statt Plain Text gebaut ist, matcht die Output-Ersetzung möglicherweise nicht.

Die Regex ist bewusst eng. Sie erwartet das id-Attribut vor class="cms-page-link" und erfasst Plain Text zwischen öffnendem und schließendem Anchor-Tag. Ein Link mit mehreren Klassen wie class="footer-link cms-page-link", ein Span innerhalb des Anchors oder eine komplett eigene Menükomponente kann außerhalb dieses Patterns liegen.

Die Ersetzung tut außerdem im Back Office nichts und kehrt früh zurück, wenn es keine Display Names für aktuelle Sprache und Shop gibt. Wenn der CMS-Footer oder das Menü Ihres Themes nicht umbenannt wird, prüfen Sie zuerst das generierte Anchor-Markup; oft besteht die Lösung darin, das Template das native PrestaShop-CMS-Link-ID- und Class-Pattern ausgeben zu lassen.

Ja, Display Names werden pro CMS-Seite, Sprache und Shop gespeichert. Die Modultabelle nutzt id_cms, id_lang und id_shop als Key, und das Speichern eines leeren Werts entfernt dieses gespeicherte Label, sodass PrestaShop auf den nativen CMS Title zurückfällt.

Der Front-Office-Lookup ist ebenfalls sprach- und shopspezifisch. Er lädt Zeilen aus mprcmsnames, bei denen id_lang der aktuellen Kontextsprache und id_shop dem aktuellen Kontextshop entspricht. Es gibt keinen breiten id_shop=0-Fallback in diesem Lookup. Ein für einen Shop gespeicherter Display Name wird also nicht automatisch von einem anderen Shop wiederverwendet.

Beim Speichern iteriert das Modul durch CMS-Seiten und Sprachen, ersetzt Zeilen, wenn ein Wert gepostet wurde, und löscht Zeilen, wenn der übermittelte Wert leer ist. Deshalb ist das Leeren eines Felds ein echter Reset, nicht nur ein leeres Custom Label.

Ein Implementierungsdetail in dieser Source-Version sollte geprüft werden: Die gerenderte Konfigurationstabelle zeigt den Default-Language-Input für jede CMS-Seite. Datenbank und Save-Logik unterstützen id_lang, aber das sichtbare Formular in diesem Checkout rendert keine separaten Eingabespalten für jede Sprache. Wenn Sie Display Names in Nicht-Default-Sprachen brauchen, bestätigen Sie, dass der installierte Build diese Inputs bereitstellt, oder ergänzen Sie sie, bevor Sie sich auf mehrsprachige Bearbeitung über das Standardformular verlassen.

Ja, das Modul generiert automatisch ein Passwort für unterstützte Registrierungs- und Checkout-Formulare. In PrestaShop zielt es auf übliche Customer-, Authentication- und Checkout-Passwortfelder und füllt password, passwd, confirmation und password_confirmation Inputs, wenn der konfigurierte Page Scope passt.

Die Installationsdefaults aktivieren das Modul, wenden es auf Registration und Checkout an, verstecken Passwortfelder, generieren ein 12-Zeichen-Passwort und enthalten Großbuchstaben, Zahlen und Sonderzeichen. Die anwendbaren Controller sind authentication, registration und identity für Registration, plus order, orderopc und order-opc für Checkout.

Auf PrestaShop 1.7+ registriert das Modul seine Front-CSS- und JavaScript-Dateien über actionFrontControllerSetMedia. Auf PrestaShop 1.6 lädt es die Assets aus displayHeader. Derselbe Header-Hook injiziert die Passwort-Einstellungen in window.mprcustomerpassword_config, damit das JavaScript sie nutzt.

Das Front Script findet benannte Felder wie password, passwd, confirmation und password_confirmation und scannt außerdem übliche Registration-/Authentication-Formulare nach jedem type=password-Input. Es generiert ein Passwort pro Seite, füllt alle passenden Felder mit demselben Wert, setzt autocomplete=new-password und fügt dem Formular einen versteckten mprcustpass_auto=1-Marker hinzu.

• Hidden mode: Der Passwortfeld-Wrapper wird versteckt und mit aria-hidden markiert.
• Optional mode in code: Das Feld wird mit dem generierten Wert und einer Info-Nachricht angezeigt, aber das Script setzt das Feld auf readonly.
• Dynamic checkout forms: Ein MutationObserver verarbeitet neu eingefügte Passwortfelder erneut, und das Script schützt generierte Werte beim Submit und mit einer periodischen Prüfung.

Ja, es kann das generierte Passwort per E-Mail senden, wenn der E-Mail-Modus auf send password steht. Der PrestaShop-Account-Add-Hook sendet diese E-Mail nur, wenn das übermittelte Formular den Auto-Generation-Marker des Moduls enthält, sodass normale Kundenkonten nicht versehentlich verarbeitet werden.

Der Standard für EMAIL_MODE ist send_password. Wenn actionCustomerAccountAdd läuft, prüft das Modul zuerst, dass es aktiviert ist, und dann auf mprcustpass_auto im übermittelten Formular. Dieser Marker wird vom JavaScript erst hinzugefügt, nachdem es Passwortfelder gefüllt hat. Der E-Mail-Pfad ist also an modul-generierte Passwörter gebunden.

Für die Passwort-E-Mail liest das Modul das übermittelte Passwort zuerst aus password und fällt für ältere PrestaShop-Formulare auf passwd zurück. Wenn keiner der beiden Werte zur Hook-Zeit vorhanden ist, kehrt es ohne Senden zurück. Wenn es sendet, verwendet es das Mail-Template mprcustomerpassword_account und übergibt Vorname, Nachname, E-Mail, generiertes Passwort, Shop-Name und Shop-URL des Kunden.

Es gibt zwei wichtige Alternativen. Mit EMAIL_MODE=silent beendet der Hook sich, ohne eine Passwort-E-Mail zu senden. Mit EMAIL_MODE=setup_link sendet er einen Reset-/Setup-Link statt des generierten Passworts. Händler, die keine Passwörter per E-Mail versenden möchten, sollten Setup-Link- oder Silent-Modus statt des Standard-Send-Password-Modus verwenden.

Ja, das Modul kann einen Setup-Link statt des generierten Passworts senden. Im PrestaShop-Setup-Link-Modus erstellt es ein Reset Token, speichert eine 24-Stunden-Gültigkeit auf dem Kundendatensatz oder Legacy-Feldern und sendet dem Kunden einen Link zur Passwortseite.

Dieser Pfad wird mit EMAIL_MODE=setup_link gewählt. Derselbe Account-Add-Hook und der mprcustpass_auto-Marker gelten weiterhin, sodass die Setup-E-Mail nur für Konten gesendet wird, bei denen das Front Script des Moduls Passwortfelder generiert und übermittelt hat.

Auf neueren PrestaShop-Customer-Objekten, die reset_password_token bereitstellen, erstellt das Modul ein Token aus random_bytes(32), macht es URL-freundlich durch Ersetzen unsicherer Base64-Zeichen, speichert es in reset_password_token, setzt reset_password_validity auf 24 Stunden in der Zukunft, aktualisiert den Kunden und baut eine Passwortseiten-URL mit token, id_customer und reset_token.

Für den Legacy-Pfad erstellt das Modul ein MD5-Token, aktualisiert die customer-Tabellenfelder reset_password_token und reset_password_validity direkt mit einem 24-Stunden-Gültigkeitsfenster und baut die Passwortseiten-URL mit token und id_customer. Die E-Mail nutzt das Template mprcustomerpassword_setup mit {setup_link}, Kundenidentitätswerten, Shop-Name und Shop-URL.

Das generierte Passwort wird weiterhin verwendet, damit PrestaShop das Konto während Checkout oder Registrierung erstellen kann. Der Unterschied ist, was der Kunde anschließend erhält: Setup-Link-Modus sendet einen Link zum Auswählen eines Passworts, während Send-Password-Modus das generierte Passwort selbst sendet.

Nein, der optionale Modus zeigt das generierte Passwort, macht das Feld im aktuellen Skript aber schreibgeschützt. In PrestaShop blendet der versteckte Modus den Passwortbereich aus, während der optionale Modus den Wert mit Hinweis sichtbar lässt.

Sie fügen einen Facebook Page Access Token und eine Page ID hinzu und aktivieren dann den Feed. In PrestaShop ruft das Modul Beiträge aus der Facebook Graph API ab und kann sie in Home-, Footer-, Left-Column- oder Right-Column-Hooks rendern.

Das Verbindungsformular erwartet Page Access Token und Page ID. Die Admin-Hilfe verweist Händler auf eine Facebook Developer App mit Pages API Access und den Berechtigungen pages_read_engagement und pages_read_user_content. Page Name ist optional und wird für den Feed Header verwendet, wenn angegeben.

• Der Standard-Display-Hook ist displayHome, aber das Modul unterstützt außerdem displayFooterBefore, displayFooter, displayLeftColumn und displayRightColumn.
• Die Standard-Post-Anzahl ist 6, das Standardlayout ist ein 3-column grid, und der Shared Feed Cache ist standardmäßig 3600 Sekunden.
• Wenn Access Token oder Page ID fehlen, gibt der Facebook-API-Fetch keine Beiträge zurück, sodass der Front-Office-Block nichts rendern kann.

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

Wenn konfiguriert, ruft das Modul Facebook Graph API v21.0 für die Page Posts auf, speichert den normalisierten Feed im Cache und rendert nur in dem Hook, der in den Moduleinstellungen ausgewählt ist.

Ja, es kann Beitragstext, Medien, Datum, Reactions, Shares, Comments und Author-Informationen anzeigen. In PrestaShop werden diese Anzeigeoptionen getrennt konfiguriert, und geteilte Beiträge können ausgeschlossen werden, wenn die Einstellung EXCLUDE_SHARED aktiviert ist.

Die relevanten Schalter sind separate Einstellungen wie SHOW_TEXT, SHOW_MEDIA, SHOW_DATE, SHOW_REACTIONS, SHOW_SHARES, SHOW_COMMENTS und SHOW_AUTHOR. Text ist standardmäßig aktiviert und wird mit Ellipse gekürzt, wenn er TEXT_LENGTH überschreitet, standardmäßig 200 Zeichen.

• Medien werden zuerst aus Facebook Attachments und Subattachments gezogen, mit full_picture als Fallback.
• Reaction-, Comment- und Share Counts kommen aus den Summary Fields, die Facebook zurückgibt. Die angezeigten Counts hängen also davon ab, was die API Response enthält.
• Wenn EXCLUDE_SHARED aktiviert ist, werden Beiträge mit status_type gleich shared_story übersprungen.
• Beiträge ohne Message Text und ohne Bild werden vor dem Rendering übersprungen.

Das ist wichtig, weil ein Händler einen kompakten Social-Proof-Block nur mit Bildern und Engagement Counts oder einen umfassenderen Editorial Feed mit Captions, Dates und Page Attribution bauen kann.

Freigegebene Projekte unterstützen Community-Votes und verschachtelte Kommentare. Vote- und Aufrufzahlen werden pro Projekt gespeichert und zeigen Ihnen einfach, welche Kundenarbeiten am besten ankommen.

Ja. Das Modul cached den Facebook Feed in einer JSON-Datei namens mprfb_feed_cache.json. Der Cache speichert einen cached_at-Zeitstempel und die abgerufenen posts und verwendet diese Posts wieder, bis die konfigurierte Dauer abläuft.

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

Die Standard-Cache-Dauer im Shared Feed Trait beträgt 3600 Sekunden. Das Konfigurationsformular des Moduls bietet übliche Dauerwerte wie 30 Minuten, 1 Stunde, 2 Stunden, 6 Stunden, 12 Stunden und 24 Stunden. Admin Refresh und Clear-Cache-Aktionen entfernen beide die Cache-Datei, sodass der nächste Feed-Request wieder zur Facebook-Quelle gezwungen wird, statt veraltete gecachte Posts auszuliefern.

Der Cache ist request-unabhängig, sodass normale Käufer nicht bei jedem Seitenaufruf einen Facebook-API-Call auslösen. Wenn die Cache-Datei fehlt, leer ist, ungültiges JSON enthält oder älter als die konfigurierte Dauer ist, behandelt der Shared Feed Trait sie als abgelaufen und ruft erneut ab. Das Speichern feed-bezogener Konfiguration leert ebenfalls den Feed Cache, was verhindert, dass Layout- oder Count-Änderungen mit alten Post-Daten gemischt werden.

Für beschäftigte Stores ist das der wichtigste Schutz gegen langsame Seitenaufrufe und unnötigen API-Druck. Für Kampagnenstarts nutzen Sie nach dem Posten auf Facebook die Admin-Refresh-Aktion, wenn der Storefront-Block neuen Inhalt sofort aufnehmen soll, statt auf das nächste Cache-Ablaufen zu warten.

Ja, es kann Blogbeiträge auf Facebook veröffentlichen, aber der Autopublish-Workflow ist um MPR-Blog-Revolution-Beiträge gebaut, nicht um jedes mögliche Drittanbieter-Blogmodul. Das Facebook-Modul nutzt den Shared Social Publisher Trait, hört auf PrestaShop Object Add und Update Hooks, prüft, dass Auto-Publish aktiviert ist, prüft auf ein Blog-Revolution- oder Post-artiges Objekt und fährt nur fort, wenn das Objekt status = 1 hat.

Duplicate Prevention wird in der Tabelle mpr_social_publish gespeichert. Vor dem Senden prüft das Modul, ob mprfacebookpostsintegration bereits Object Type blog_post mit dieser Post ID auf Plattform facebook veröffentlicht hat. Erfolgreiche Sends werden mit Platform Post ID, Platform URL, Caption, Media URLs und Status published aufgezeichnet, sodass spätere Add- oder Update-Hooks denselben Beitrag überspringen, statt ihn erneut zu senden.

Captions kommen aus dem Auto-Publish-Template des Facebook-Moduls. Unterstützte Platzhalter sind {title}, {excerpt}, {url} und {shop_name}. Wenn der Blogbeitrag ein Featured Image hat, baut der Publisher seine Media URL aus img/mprblogrevolution/posts/. Wenn Facebook-Zugangsdaten fehlen, der Publisher nicht konfiguriert ist oder eine erforderliche Plattformbedingung nicht erfüllt ist, kehrt der Auto-Publish-Pfad ohne Posting zurück.

Der Facebook-spezifische Publisher ist nur konfiguriert, wenn sowohl PAGE_ID als auch ACCESS_TOKEN existieren. Er nutzt Facebook Graph API v21.0, unterstützt Text Posts, Link Posts und Photo/Image Posts im implementierten publish()-Pfad, erlaubt ein Media Item pro Send und hat ein Zeichenlimit von 63206. Ein media-only Image Post wird über den Page Photos Endpoint gesendet, während Link- oder Text Posts den Page Feed Endpoint nutzen.

Obwohl getSupportedMediaTypes() aktuell video auflistet, lädt der implementierte Publisher keine Videos hoch und ruft keinen Videos Endpoint auf. Behandeln Sie Video Publishing als unsupported, solange kein echter Video-Publishing-Pfad hinzugefügt wird.

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

Das Modul überspringt außerdem seinen eigenen Publisher-Pfad, wenn die breitere mprsocialrevolution-Übernahme für Facebook aktiv ist, damit zwei Social-Module nicht versuchen, denselben Blogbeitrag gleichzeitig zu veröffentlichen.

Das Modul fügt eigene Seiten für Galerie, Kategorie, Projekt, Einreichung und einen Kundenbereich „meine Projekte“ hinzu, jeweils mit eigener SEO-freundlicher URL. Ausgewählte freigegebene Projekte lassen sich zusätzlich in bestimmten Shop-Bereichen anzeigen.

Alle Galerietexte – Kategorien, Projekte und Kommentare – werden pro Sprache gespeichert, sodass die Galerie vollständig mehrsprachig ist. Das Modul läuft auf PrestaShop 1.6.1 bis 9.x.

Ja, jedes Feed Profile kann eigene Sprache, Währung, Zielländer und Labels tragen. Das ist nützlich, wenn ein Store in mehrere Märkte mit unterschiedlicher Katalogsprache oder Werbestruktur verkauft. Klare Feed-Trennung hilft Managern außerdem zu verstehen, welcher Markt Umsatz bringt und welcher Aufmerksamkeit braucht.

Im Feed-Modell speichert jedes Profil id_lang, id_currency, id_shop, target_country, feed_label, content_language und sync_mode. Ein neuer Feed fällt im aktuellen Source auf französische Einstellungen zurück: target_country=FR, feed_label=FR und content_language=fr.

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

• target_country wird auf Uppercase normalisiert und kann ein Zwei-Buchstaben-Ländercode oder eine kommaseparierte Liste sein.
• feed_label wird auf Uppercase normalisiert und muss zu Googles Merchant-API-Label-Form passen: Großbuchstaben, Zahlen und Bindestriche, bis 20 Zeichen.
• content_language wird auf Lowercase normalisiert und muss für API Product Input ein Zwei-Buchstaben-Sprachcode sein.
• Für API Sync sind getrennte Feed Profiles meist sauberer, wenn jeder Markt ein eigenes Label, eine eigene Währung oder Sprache braucht.

Der Front Feed Controller liefert einen bestimmten Feed nach ID oder Dateiname mit Token aus, nutzt eine Cache TTL von standardmäßig 3600 Sekunden und kann mit generate=1 regenerieren. So kann ein PrestaShop-Shop getrennte Merchant Feeds pflegen, ohne Länder, Sprachen oder Kampagnenlabels zu mischen.

Nein, die Source-Beschreibung sagt, dass PrestaShops interne numerische Werte darunter unverändert bleiben. Das Modul passt die Nummern an, die auf Rechnungen, Lieferscheinen und Gutschriften angezeigt werden. Wenn Sie die Bestellreferenzen selbst anpassen müssen, empfiehlt die Source das separate Produkt Custom Order Numbering.

Das Rechnungsmodul bestätigt diese Trennung im Code: hookActionSetInvoice generiert und loggt die formatierte Rechnungsreferenz, lässt PrestaShops gespeicherte Rechnungsnummer aber absichtlich numerisch/nativ. Der angezeigte formatierte String wird später über actionInvoiceNumberFormatted geliefert, und Delivery-Note-Generierung speichert den numerischen Counter-Wert 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}

Generierte Werte werden in mprinvoicenumber_number mit Document Type, Order-, Invoice- oder Slip-IDs, Counter Value, Pattern und Formatted Number aufgezeichnet. So erhalten Sie benutzerdefinierte kunden sichtbare Dokumente, ohne Order IDs oder zufällige Order References zu ändern; diese werden von mprordernumber behandelt.

Das Modul gibt über displayProductListReviews einen Indikator aus. Sein JavaScript findet die umgebende Produktminiatur und fügt ein Bundle-Badge in den Bildbereich ein.

Der Tab listet konfigurierte enthaltene Produkte in einem Grid auf. Jede Karte kann Produktbild, Produktname, formatierten Preis oder FREE bei Nullpreis und einen Link zum enthaltenen Produkt anzeigen.

Es enthält einen Dispatcher-Helper für reine Rewrite-Routen. Wenn einer Route eine ID fehlt, kann er passende Kategorie-, Produkt-, CMS- oder Hersteller-Slugs auflösen und Request-Parameter entsprechend aktualisieren.

Ja. Das Adminformular speichert das Enabled-Flag, und jeder Front-Hook kehrt früh zurück, wenn isFeatureEnabled() false ist.

Der serverseitige Pfad erfordert, dass CAPI aktiviert und ein Reddit Access Token konfiguriert ist. Die Events Testing ID ist optional und wird nur verwendet, wenn sie vorhanden ist.

Nein, die Quelle beschreibt Browser-Events und serverseitige Events, die mit gemeinsamen Conversion-IDs parallel laufen. Der serverseitige Pfad kann Lücken reduzieren, wenn Browser-Tracking blockiert wird, während das Browser-Pixel weiterhin clientseitiges Verhalten erfasst. Sorgfältig kombiniert geben beide Reddit vollständigere Signale als nur ein eingefügtes Pixel.

Das Browser-Tracking wird in den Header- und Bestellbestätigungs-Hooks vorbereitet. Das Modul kann Events wie PageVisit, ViewContent, Search, SignUp, InitiateCheckout, Add-to-cart-Bridge-Events und Purchase ausgeben. Wenn die Conversions API aktiviert ist, werden passende Events serverseitig mit derselben Identität in die Warteschlange gestellt: Browser-Parameter verwenden conversionId, während die API-Nutzlast conversion_id in den Event-Metadaten speichert.

• Für Browser-Tracking ist eine Reddit Pixel ID erforderlich.
• Die Conversions API benötigt zusätzlich ein Zugriffstoken, und das Modul sendet für das konfigurierte Pixel an den Conversion-Endpunkt von Reddit.
• Mitarbeiterausschluss und Marketing-Consent-Prüfungen laufen über canTrack(), bevor Front-Office-Tracking vorbereitet wird.
• Das Standard-Batch-Limit der CAPI-Warteschlange ist 20, während Front-Bridge- und Kaufpfade kleine Batches sofort verarbeiten.

Die praktische Einrichtung besteht darin, das Browser-Pixel für normale clientseitige Events aktiv zu lassen und die Conversions API als ergänzendes serverseitiges Signal zu verwenden, nicht als Ersatz.

Das Modul mappt die meisten Standardaktionen direkt, wahrend InitiateCheckout im serverseitigen Mapping als Reddit Custom Event namens InitiateCheckout gesendet wird.

Ja. Die Konfiguration enthalt Mitarbeiterausschluss, und die Tracking-Sperre pruft ihn, bevor die Front-Pixel-Ausgabe erstellt oder Ereignisse uber den Modul-Tracking-Pfad zugelassen werden.

Die verfuegbare Hook-Liste umfasst displayHome, displayFooterCategory, displayLeftColumn, displayRightColumn, displayFooterBefore, displayFooterProduct, displayProductAdditionalInfo, displayOrderConfirmation2 und displayCrossSellingShoppingCart.

Ja, die Quellbeschreibung umfasst kuratierte Produktsammlungen ebenso wie dynamische Widgets. Manuell ausgewählte Sammlungen sind nützlich für Kampagnen, redaktionelles Merchandising und margenorientierte Promotion. Dynamische Quellen sind nützlich, wenn Bestseller, neue Produkte oder wieder verfügbare Artikel mit weniger manueller Arbeit aktuell bleiben sollen.

Kuratierte Sammlungen werden getrennt von Widgets gespeichert. Die Collection-Product-Tabelle speichert id_collection, id_product und position, und setProducts() schreibt diese Liste in der vom Admin gespeicherten Reihenfolge neu. Ein Widget kann dann den Widget-Typ collection verwenden und auf die gewählte Sammlung zeigen.

• Collection-Typen umfassen curated, staff_picks, seasonal und spotlight.
• Öffentliche Collection-Abfragen geben aktive Shop-Produkte zurück und behalten die gespeicherte Collection-Product-Reihenfolge bei.
• Wenn das Widget Bilder benötigt, filtert der Provider Produkte ohne nutzbares Bild heraus.
• Automatische Widget-Typen mit implementierten Product Providern umfassen bestsellers, new, sale, featured, trending, back_in_stock und cart_recommendations.
• recently_viewed ist im Modell als Widget-Typ/Label aufgeführt, aber getProducts() hat dafür noch keinen Provider-Fall. Daher sollte es nicht als funktionale automatische Liste präsentiert werden, bis diese Implementierung ergänzt ist.

Das bedeutet, dass Sie für einen Homepage- oder Produktseitenblock eine Kampagnenkollektion manuell auswählen und gleichzeitig an anderer Stelle im selben PrestaShop-Shop implementierte dynamische Blöcke nutzen können.

Ja. Das Widget-Modell speichert hide_products_without_images, und Produktabfragen bzw. die Provider-Zusammenstellung verwenden dieses Flag, um fuer viele Widget-Quellen ein Shop-Coverbild zu verlangen.

Das Modul hoert auf actionUpdateQuantity. Wenn die Menge eines Produkts von null oder weniger auf einen positiven Wert steigt, fuegt es eine Zeile in mprshowcaserevolution_stock_change ein, die die Produktquelle fuer wieder verfuegbare Produkte nutzen kann.

Installieren und aktivieren Sie das Modul, um auf PrestaShop-Produktseiten einen Ask a question-Button hinzuzufügen. Er wird über den Hook displayProductAdditionalInfo gerendert, öffnet ein modales Formular neben den Produktinformationen und übernimmt Produktname, Referenz und Produkt-ID in die Anfrage.

Bei der Installation speichert das Modul ENABLED=1, setzt RECIPIENT_EMAIL aus PS_SHOP_EMAIL und verwendet [Product Question] als Standard-Präfix für den Betreff. Der Hook weist dem Smarty-Template Produktname, Produktreferenz, Produkt-ID, AJAX-URL und einen versteckten Token-Wert zu.

• Front Hook: displayProductAdditionalInfo.
• AJAX-Endpunkt: module/mpraskaboutproduct/ask.
• Admin-Einstellungen: Aktivierungsschalter, Empfänger-E-Mail und Betreff-Präfix.

Das Ergebnis ist ein produktspezifisches Anfrageformular auf der Produktseite, sodass der Händler die Nachricht mit Produktkontext erhält statt als allgemeine Kontaktanfrage.

Ja, Kunden senden die Produktanfrage direkt aus dem modalen Fenster im Storefront. Der PrestaShop Front Controller empfängt Absendername, Absender-E-Mail, Nachricht, Produktname und Produkt-ID per AJAX und gibt anschließend eine JSON-Erfolgs- oder Fehlermeldung zurück, ohne dass der Kunde ein E-Mail-Programm öffnen muss.

Das Template sendet eine FormData-Anfrage an den Front Controller des Moduls und aktualisiert das modale Fenster mit der JSON-Antwort. Bei Erfolg wird das Formular zurückgesetzt und der Kunde sieht die Erfolgsmeldung; bei Validierungs- oder Mailfehlern zeigt dasselbe Modal den zurückgegebenen Fehler.

• Die Anfrage gilt als ungültig, wenn der erwartete sender_email-Submit-Marker fehlt.
• Der Controller sendet an den konfigurierten Modulempfänger oder fällt auf die Shop-E-Mail zurück.
• Wenn das Mail-Template question des Moduls existiert, wird es verwendet; andernfalls fällt der Code auf das PrestaShop-Core-Template contact zurück.

So bleibt die Anfrage im PrestaShop-Storefront-Workflow, und Produktname sowie Produkt-ID bleiben im E-Mail-Inhalt erhalten.

Es validiert die Anfrage im AJAX Front Controller, bevor die E-Mail gesendet wird. Eine Anfrage muss sender_email übermitteln, und die Pflichtfelder sind sender_name, sender_email und message. Die E-Mail wird mit PrestaShops Validate::isEmail() geprüft, und die Nachricht mit 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

• Ein fehlender sender_email-Submit-Marker gibt {"success":false,"message":"Invalid request."} zurück.
• Leerer Name, leere E-Mail oder leere Nachricht gibt {"success":false,"message":"All fields are required."} zurück.
• Eine ungültige E-Mail gibt {"success":false,"message":"Invalid email address."} zurück.
• Unsicheres Nachrichten-HTML gibt {"success":false,"message":"Invalid message content."} zurück.

Wenn die Validierung erfolgreich ist, sendet das Modul die Anfrage an die konfigurierte Empfänger-E-Mail und fällt auf die Shop-E-Mail zurück, wenn kein Modulempfänger gesetzt ist.

Nach der Validierung baut der Controller den E-Mail-Betreff aus dem konfigurierten Betreff-Präfix plus dem übermittelten Produktnamen. Die Nachricht wird escaped und mit nl2br() für das E-Mail-Template umgewandelt. Produktname und Produkt-ID werden in die Mail-Variablen aufgenommen, sodass Mitarbeiter den Artikel identifizieren können, ohne den Kunden erneut nach Details fragen zu müssen.

Das Modal enthält ein verstecktes Token-Feld, aber der aktuelle Controller-Pfad validiert Anfragefelder und Nachrichteninhalt, statt dieses Token zu prüfen. Wenn stärkerer Anti-Spam-Schutz erforderlich ist, ergänzen Sie ihn rund um das Front-Formular, statt davon auszugehen, dass dieser Controller eine CSRF-Token-Prüfung durchführt.

Ja, mit dem Modul können Sie Empfänger-E-Mail und Betreff-Präfix für Produktfragen festlegen. Wenn kein Empfänger konfiguriert ist, fällt der PrestaShop Front Controller auf die Shop-E-Mail-Adresse zurück und sendet die Nachricht mit enthaltenem Produktkontext.

Die Konfigurationsklasse stellt RECIPIENT_EMAIL und SUBJECT_PREFIX bereit. Während der Installation wird RECIPIENT_EMAIL aus PS_SHOP_EMAIL initialisiert, und SUBJECT_PREFIX ist standardmäßig [Product Question]. Im Front Controller wird ein leerer Empfänger durch Configuration::get('PS_SHOP_EMAIL') ersetzt.

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

Das ist nützlich, wenn Produktfragen statt an die allgemeine PrestaShop-Kontaktadresse an ein Sales-Postfach, ein technisches Team oder einen Lieferanten-Desk gehen sollen.

Ja. Bewertungen werden geprüft, bevor sie gespeichert werden, und fehlgeschlagene Prüfungen geben einen Validierungsfehler zurück, statt die Bewertung stillschweigend anzunehmen. Die Quelle enthält diese Schutzmechanismen:

• Same-IP-Rate-Limit: Wenn MIN_TIME_BETWEEN größer als null ist, prüft das Modul, ob dieselbe IP innerhalb der konfigurierten Sekundenzahl in diesem Shop bereits eine andere Bewertung gepostet hat.
• reCAPTCHA: Wenn aktiviert, verifiziert das Modul das übermittelte Token bei Google. Es unterstützt v2 und v3; v3 verwendet einen Score-Schwellenwert von 0.5. Ein fehlendes Token lässt die Prüfung fehlschlagen, während ein fehlender Secret Key oder ein Netzwerkproblem bei der Verifizierung als nicht blockierend behandelt wird.
• Link- und Tag-Prüfungen: Inhalte mit mehr als zwei URLs werden abgelehnt, und offensichtliches eingebettetes HTML wie <script>, <iframe>, <object>, <embed> und <form> wird blockiert.

Der Mindestzeit-Schutz ist eine Prüfung des Zeitabstands zwischen Bewertungen für dieselbe IP, kein Formular-Ladetimer. Um reCAPTCHA als aktiven Schutz zu nutzen, aktivieren Sie es und konfigurieren Site Key und Secret Key in den Moduleinstellungen.

Der breitere Einreichungsablauf ergänzt weitere praktische Schutzmaßnahmen. Bewertungen benötigen einen gültigen Entity Type, eine Entity ID, Inhalt mit mindestens 10 Zeichen und eine Bewertung von 1 bis 5. Gastbewertungen sind standardmäßig deaktiviert, und eingeloggte Kunden werden daran gehindert, dieselbe Entität zweimal zu bewerten, sofern die vorherige Bewertung nicht als Spam markiert wurde.

• MODERATION ist standardmäßig 1, daher werden neue Bewertungen als pending gespeichert, sofern Moderation nicht deaktiviert ist.
• MIN_TIME_BETWEEN ist standardmäßig 30 Sekunden.
• Bei Produktbewertungen durch eingeloggte Kunden kann das Modul eine Bewertung als verifizierten Kauf markieren, wenn es eine gültige Bestellung findet, die dieses Produkt enthält.
• Foto-Uploads sind, wenn aktiviert, auf JPEG, PNG und WebP beschränkt, mit Standardlimits von 3 Bildern und 2 MB pro Bild.

Es ist dennoch kein Betrugserkennungssystem. Der Code bietet Rate Limiting, reCAPTCHA, Inhaltsprüfungen, Duplikatvermeidung, Verified-Purchase-Markierung und Moderation. Händler sollten Moderation daher aktiviert lassen, wenn Bewertungsqualität wichtig ist.

Ja, Bewertungen sind nicht auf Produktseiten beschränkt. Das Modul enthält Entity-Handling für Produkt-, Kategorie-, CMS- und Shop-Bewertungen sowie eine öffentliche Bewertungsroute. Jeder Anzeigebereich wird per Konfiguration gesteuert und über PrestaShop-Front-Office-Hooks oder Controller gerendert.

Das Datenmodell speichert Bewertungen mit entity_type und entity_id, und der Submission Service akzeptiert product, category, cms und store als gültige Entity Types. Die Einstellungsseite hat separate Schalter für PRODUCT_REVIEWS, CATEGORY_REVIEWS, CMS_REVIEWS und STORE_REVIEWS; in den aktuellen Defaults sind nur Produktbewertungen standardmäßig aktiviert.

Die automatische Produktseitenintegration ist der vollständigste Pfad im geprüften Code: Produktbewertungen werden über displayProductExtraContent gerendert, Listensterne über displayProductListReviews und das Produktbewertungs-Badge über Produktseiten-Hooks. Die öffentliche Bewertungsseite ist als /reviews verfügbar und kann genehmigte Bewertungen nach type=product, category, cms oder store filtern.

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

Für Kategorie-, CMS- und Shop-Platzierungen sollten Sie die Front-Office-Platzierung sorgfältig planen. Die Quelle unterstützt diese Bewertungsdatensätze und den Reviews Hub, aber Produktseiten haben in den geprüften Dateien die stärkste eingebaute Hook-Abdeckung.

Ja, Erinnerungen können erstellt werden, nachdem eine Bestellung den konfigurierten Lieferstatus erreicht hat. Der PrestaShop-Bestellstatus-Hook plant Erinnerungen nur, wenn die Erinnerungsfunktion aktiviert ist, und das Modul speichert Erinnerungszeilen mit Bestell-, Kunden-, Verzögerungs- und Bewertungsstatusdaten.

Genauer gesagt lauscht der geprüfte Hook auf actionOrderStatusPostUpdate und prüft, ob der neue PrestaShop-Bestellstatus sein delivery-Flag gesetzt hat. Wenn REMINDERS_ENABLED aktiv ist, lädt er die Bestellprodukte und erstellt über ReviewReminder::createForOrder() eine Erinnerungszeile pro Produkt.

• REMINDERS_ENABLED ist standardmäßig 0.
• REMINDER_DELAY_DAYS ist standardmäßig 7.
• Doppelte Zeilen für dieselbe Bestellung und dasselbe Produkt werden übersprungen.
• Produkte, die dieser Kunde bereits bewertet hat, werden übersprungen.
• Jede Erinnerungszeile speichert ein 64-Zeichen-Token und einen Status wie pending, sent oder reviewed.

Das Modell enthält außerdem Helper, um ausstehende Erinnerungen nach der konfigurierten Verzögerung zu finden, Erinnerungen als gesendet zu markieren, sie als bewertet zu markieren und eine Erinnerung per Token zu laden. In den geprüften Dateien habe ich die Planung und das Datenmodell gefunden, aber keinen vollständigen E-Mail-sendenden Cron-Flow, der diese Helper-Methoden aufruft.

Ja, das Modul enthält externe Review Manager für Google Business Profile und Trustpilot. Wenn die erforderlichen API-Zugangsdaten konfiguriert sind, können externe Bewertungen in lokale External-Review-Tabellen synchronisiert und anschließend gemäß den PrestaShop-Moduleinstellungen angezeigt oder aggregiert werden.

Die External-Review-Tabelle speichert Quelle, Source Review ID, Autor, Titel, Inhalt, Bewertung, Source URL, Veröffentlichungsdatum, Sprache, optionale Produkt-ID, Shop-ID, rohe API-Daten und Sync-Zeitstempel. Ein Unique Key auf source plus source_review_id verhindert doppelte Importe, wenn dieselbe Bewertung erneut abgerufen wird.

• Trustpilot-Sync erfordert EXT_TRUSTPILOT_ENABLED, einen API Key und eine Business Unit ID. Der Provider hat außerdem einen CSV-Import-Fallback für Trustpilot-Exporte.
• Google Business Profile-Sync erfordert EXT_GOOGLE_ENABLED, Service-Account-JSON mit client_email und private_key sowie Account ID und Location ID.
• Der Cron Controller läuft unter /module/mprcomments/cron?token=EXT_CRON_TOKEN&action=sync und gibt Sync-Ergebnisse je Quelle als JSON zurück.
• Externe Unternehmensbewertungen können auf Produktseiten angezeigt, standardmäßig lazy-loaded und optional in Produktbewertungs-Badges mitgezählt werden, wenn externe Aggregation aktiviert ist.

Aus SEO-Sicherheitsgründen verwendet der Schema Renderer native Produktbewertungen für Product Structured Data. Importierte Unternehmensbewertungen können Käufern angezeigt werden, aber die Source-Kommentare halten sie ausdrücklich aus dem Product Review Markup heraus, sofern der Händler keine nativen Produktbewertungen hat.

Nein, eingereichte Projekte werden standardmäßig nicht automatisch veröffentlicht. In PrestaShop ist die Einstellung auto_approve standardmäßig 0, sodass neue Projekte als pending gespeichert werden und öffentliche Galerieabfragen den genehmigten Projektstatus verwenden, bevor sie angezeigt werden.

Der Submit Controller ist kundenauthentifiziert und erfordert ein gültiges Security Token, bevor ein Projekt erstellt wird. Er validiert den Projekttitel, verlangt mindestens ein hochgeladenes Bild und erzwingt das konfigurierte Bildanzahl-Limit, bevor das Projekt gespeichert wird. Die Standard-Bildeinstellungen sind max_images=20 und max_image_size_mb=5.

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

• Wenn auto_approve deaktiviert bleibt, wird der Kunde nach dem Absenden zu My Projects weitergeleitet und das Projekt wartet auf Moderation.
• Wenn auto_approve aktiviert ist, speichert derselbe Submit Flow das neue Projekt mit Status approved.
• Die Projekt-Adminliste unterstützt Bulk-Aktionen zum Genehmigen, Ablehnen, Hervorheben und Löschen.
• Der öffentliche Project Controller gibt für nicht genehmigte Projekte einen 404 zurück, sofern keine gültige Admin-Preview-Session besteht.

Für die meisten Shops ist es sicherer, Auto-Approval deaktiviert zu lassen, weil kundenseitig eingereichte Titel, Beschreibungen und Fotos geprüft werden, bevor sie im öffentlichen Showcase erscheinen.

Ja, Admins können Showcase-Bildern Produkt-Pins hinzufügen. In PrestaShop speichert jeder Pin x- und y-Bildkoordinaten, ein Label und geordnete Fallback-Produkt-IDs und löst dann ein aktives, vorrätiges Produkt für die öffentliche Projektanzeige auf.

Der Admin-Pin-Controller fügt Pins per JSON-AJAX hinzu, aktualisiert, löscht und lädt sie. Koordinaten müssen zwischen 0 und 100 liegen und werden auf zwei Dezimalstellen gerundet. Product-Fallback-IDs werden normalisiert, dedupliziert und als JSON gespeichert; die erste ID wird zusätzlich in das Legacy-Feld id_product geschrieben.

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

• Die Admin-Produktsuche gibt aktive Produkte nach Name, Referenz oder Produkt-ID zurück, begrenzt auf 20 Ergebnisse.
• Auf der öffentlichen Projektseite werden Pins mit Produkt-URL, Cover-Bild und formatiertem Preis angereichert.
• Der Front-AJAX-Pin-Endpunkt kann außerdem das Product-Miniature-Template des Themes rendern, wenn verfügbar.
• Wenn alle Fallback-Produkte inaktiv sind, bleibt der Pin positioniert, löst aber kein Produkt auf.

Damit kann ein Händler ein Kundengaleriebild in ein kaufbares Lookbook verwandeln und zugleich eine Fallback-Liste für ausverkaufte oder deaktivierte Produkte behalten.

Ja, doppelte Votes desselben Kunden für ein Projekt werden verhindert. In PrestaShop besitzt die Vote-Tabelle einen eindeutigen Schlüssel aus Projekt und Kunde, und das Vote-Modell aktualisiert den bestehenden Eintrag statt eine zweite Zeile anzulegen.

Ja. Eine Customer Showcase-Projektseite außerhalb der Preview kann JSON-LD ausgeben, wenn der Project Controller genügend Daten zum Erstellen hat. Der Controller sammelt Projekttitel, eine aufgelöste Page Meta Description, die kanonische Projekt-URL, große Showcase-Bild-URLs und Kategoriename. Anschließend gibt das Front-Template das JSON in einem application/ld+json-Script aus, wenn project_schema_json nicht leer ist.

{"@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"}

Der vom Modul verwendete Schema-Typ ist ImageGallery, beschreibt also die Kundenprojektgalerie, statt ein separates Produkt-, Service- oder Review-Schema zu beanspruchen.

Der Controller überspringt Schema bewusst im Preview-Modus: Preview-Seiten erhalten einen leeren project_schema_json-Wert, und der Preview Helper setzt noindex-Handling. Auf normalen Projektseiten werden große Bild-URLs aus img/showcase/large/ mit der Shop-SSL-Domain und Base URI gebaut, sodass die strukturierten Daten auf absolute Bild-URLs zeigen statt auf Thumbnail- oder Medium-Dateien, die an anderer Stelle auf der Seite verwendet werden.

• Quelle der Beschreibung: Das JSON-LD nutzt die aufgelöste Page Meta Description. Das ist die gespeicherte Projekt-Meta-Description, wenn eine vorhanden ist; andernfalls generiert der Controller eine titelbasierte Customer-Showcase-Beschreibung. Die bereinigte und gekürzte Projektbeschreibung ist nur ein letzter Fallback innerhalb von buildProjectSchema(), falls die aufgelöste Meta Description weiterhin leer ist.
• Optionale Felder: image wird nur eingebunden, wenn Projektbilder existieren, und about nur, wenn das Projekt einen Kategorienamen hat.
• Ausgabesicherheit: Das JSON wird mit json_encode(..., JSON_UNESCAPED_SLASHES | JSON_UNESCAPED_UNICODE) erzeugt und fällt bei Bedarf auf Tools::jsonEncode() zurück. Danach gibt Smarty dieses vorbereitete JSON ungefiltert innerhalb des JSON-LD-Scripts aus.

Nein. Das Modul implementiert nur den PrestaShop-seitigen Google Customer Reviews-Code; es enthält keinen Code, der einen Shop in Google Merchant Center anmelden, genehmigen oder berechtigt machen kann. Sie benötigen das für den Shop in Merchant Center verfügbare Google Customer Reviews-Programm, eine numerische Merchant ID und Bestelldaten, die Google für das Survey Opt-in akzeptiert.

Was das Modul steuern kann, ist die Storefront-Implementierung, nachdem diese Voraussetzungen erfüllt sind: Es speichert die Merchant ID, lädt Googles Survey Opt-in auf der Bestellbestätigungsseite, sendet Bestell-ID, Kunden-E-Mail, Lieferland, geschätztes Lieferdatum und Produkt-GTIN-Werte aus der Bestellung und rendert das Rating Badge an der konfigurierten Badge-Position.

Survey-Zustellung, Programmgenehmigung, Verkäuferbewertungsberechnung und die Anzeige von Bewertungen in Google-Eigenschaften bleiben unter Googles Kontrolle. Das Modul kann Opt-in- und Badge-Code ausgeben, aber es kann den Shop nicht genehmigen oder Google zwingen, Bewertungen anzuzeigen.

Bei der Installation startet das Modul deaktiviert mit leerer MERCHANT_ID, einer Standard-Badge-Position von BOTTOM_RIGHT und Badge-Sprache en. Der Storefront-Guard verlangt sowohl ENABLED als auch eine nicht leere Merchant ID, sodass ein installiertes, aber nicht konfiguriertes Modul weder Opt-in- noch Badge-Code ausgibt.

• Order confirmation opt-in: Der Hook läuft nur für eine geladene Bestellung, verwendet die Kunden-E-Mail der Bestellung, liest das Lieferland aus der Lieferadresse, nutzt ein einfaches geschätztes Lieferdatum von heute plus sieben Tage und übergibt ean13 jedes bestellten Produkts als GTIN-Wert.
• Badge: Der Body-Closing-Hook rendert Googles Rating Badge mit der konfigurierten Merchant ID und einer der unterstützten Positionen, etwa BOTTOM_RIGHT, BOTTOM_LEFT oder INLINE.
• Limit: Wenn Produkte keinen EAN13-Wert haben, sendet das Modul den Produkteintrag trotzdem mit leerer GTIN; ob Google diese Produktdaten akzeptiert oder verwendet, wird außerhalb von PrestaShop entschieden.

Nicht automatisch. Das Modul bietet Vorschau und Verlauf, aber die Quelle enthält keinen Ein-Klick-Rollback, der jedes Produkt auf seinen vorherigen Preis zurücksetzt. Bevor Sie ein Massenupdate anwenden, nutzen Sie die Vorschau, um betroffene Produkt-IDs, aktuellen Preis, berechneten neuen Preis und Differenz zu prüfen.

• Vor dem Anwenden: Exportieren oder sichern Sie die betroffenen Produkt-IDs und das Preisfeld, das Sie ändern, besonders bei einem breiten Scope wie allen Produkten, einer Kategorie oder einem Hersteller.
• Nach dem Anwenden: Das Modul schreibt einen Logeintrag mit Formel, Scope, Preisfeld, betroffener Anzahl, Mitarbeiter und Datum.
• Wenn Sie rückgängig machen müssen: Nutzen Sie das Log, um den Lauf zu identifizieren, und stellen Sie anschließend aus Ihrem Backup/Export wieder her. Die inverse Formel anzuwenden kann riskant sein, weil Rundung, spätere Preisänderungen und Änderungen am Produktscope die Rückrechnung von den ursprünglichen Werten abweichen lassen können.

Führen Sie bei risikoreichen Änderungen die Vorschau aus, exportieren Sie dieselbe Produktmenge und wenden Sie das Update in einer ruhigen Zeit an, damit Korrekturen aus bekannten Ausgangswerten erfolgen können.

Die Vorschau und das echte Update verwenden denselben Calculation Helper, sodass die Zahlen in der Vorschau auf denselben Formelaktionen basieren, die später angewendet werden: increase_percent, decrease_percent, increase_fixed und decrease_fixed. Prozentuale und feste Senkungen werden bei null begrenzt, und berechnete Preise werden vor dem Schreiben auf sechs Dezimalstellen gerundet.

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

Beim Anwenden aktualisiert das Modul sowohl product als auch product_shop für das ausgewählte Feld und unterstützt nur price oder wholesale_price. Der Scope Picker kann alle aktiven Produkte oder aktive Produkte in einer ausgewählten Kategorie, bei einem Hersteller oder bei einem Lieferanten ansprechen; inaktive Produkte werden von den Scope-Abfragen nicht ausgewählt.

Der Hook erlaubt URLs, die module/mprpasswordprotect oder module-mprpasswordprotect enthalten, und kehrt ebenfalls zurück, wenn der Parameter module des Requests dem Modulnamen entspricht.

Die Konfigurationsklasse stellt über das OptionsManager-Formular Schalter für Passwortschutz aktivieren, Passwort, Nachricht, Mitarbeiter-/Wartungs-Bypass und noindex bereit.

Ja. Die Installation erstellt eine nicht konfigurierbare Meta-Seite für module-mprpasswordprotect-gate mit dem Titel Password Required und dem URL-Rewrite password.

Der Gate-Controller setzt ein Fehlerflag und rendert dasselbe Passwort-Template erneut, das die übersetzte Nachricht Incorrect password. Please try again. anzeigt.

Nein. Der Resend-Controller sendet die neu aufgebaute Bestellbestatigungs-E-Mail und protokolliert eine private Nachricht, ruft aber keine Logik zur Anderung des Bestellstatus auf.

Vor dem Senden verlangt der AJAX Controller eine Bestell-ID und ein Modul-Token, validiert beides, lädt Bestellung und Kunde und ruft dann PrestaShops Standard-Mail::Send() mit dem Template order_conf aus _PS_MAIL_DIR_ und der ursprünglichen Shop-ID der Bestellung auf.

• Produkte: Es baut sowohl HTML- als auch Plain-Text-Produktzeilen aus $order->getProducts() neu auf, einschließlich Produktname, optionale Referenz, Menge, Stückpreis inklusive Steuer und Gesamtpreis inklusive Steuer.
• Adressen: Liefer- und Rechnungsblöcke werden mit AddressFormat::generateAddress() erzeugt, mit einem Fallback aus Firma, Name, Straße, Postleitzahl und Stadt, falls die Adressformatierung fehlschlägt.
• Audit Trail: Nach erfolgreichem erneuten Versand fügt es eine private Bestellnachricht hinzu und schreibt einen PrestaShop-Logeintrag; wenn das Mail-Senden fehlschlägt, gibt es einen JSON-Fehler zurück, statt den Bestellstatus zu ändern.

Das Modul sendet PrestaShops Standard-Template order_conf uber Mail::Send, nachdem Produktzeilen, Adressen, Summen, Versanddienst und Zahlungswerte aus der Bestellung neu aufgebaut wurden.

Nach erfolgreichem Versand erstellt das Modul eine private Bestellnachricht, die festhalt, dass die Bestatigung erneut gesendet wurde, inklusive Empfanger-E-Mail und Zeitstempel.

Das Modul muss aktiviert sein und PHONE_NUMBER muss gesetzt werden. Der Validator der Pflichtkonfiguration erwartet nur Ziffern und ein optionales fuehrendes Pluszeichen, zum Beispiel +1234567890.

Ja. Das gemeinsame Chat-Trait unterstuetzt ueber die Einstellung PAGES Seitenfilter fuer all, product, category und checkout.

Nein. Das gerenderte Template erstellt einen normalen Link zu Signal und verwendet lokales Modul-CSS sowie Inline-SVG fuer den Button. Im Hook-Template gibt es keinen externen Signal-JavaScript-Loader.

Wenn DELAY groesser als null ist, versteckt das Template das Widget zunaechst und zeigt es per Timeout nach der konfigurierten Anzahl von Sekunden an.

Das Modul speichert die Anzeigeauswahl des Besuchers im leichten mpr_tax_display-Cookie und bereitet früh im Front Controller PrestaShops Gruppen-Cache für Preisanzeige vor, damit Produktpreisberechnungen für diese Anfrage inklusive oder exklusive Steuer gerendert werden. Es aktualisiert keine Warenkörbe, Bestellungen, Steuerregeln, Rechnungen oder Kundengruppen in der Datenbank.

Auf Produkt-/Listing-Seiten injiziert es außerdem versteckte .mpr-tax-prices-Daten mit vorformatierten Preisen inklusive und exklusive Steuer, sodass JavaScript sichtbare Preise sofort austauschen kann. Wenn eine Seite keine injizierten Produktpreisdaten hat, etwa manche Warenkorb- oder Checkout-Seiten, speichert das Script die Präferenz und lädt neu, damit PrestaShop die Seite im gewählten Anzeigemodus rendert.

Checkout-Summe und Steuerbetrag werden weiterhin von PrestaShop aus Warenkorb, Adresse, Steuerregeln und normalem Checkout-Flow berechnet. Dieses Modul beeinflusst Anzeigepräferenz und Preislabels, nicht die steuerliche Berechnung.

Aktivieren Sie das Modul, um im PrestaShop-Storefront einen fixierten Back-to-top-Button zu rendern. Der Code gibt den Button aus Footer-/Body-Closing-Hooks aus, verhindert doppelte Ausgabe, wenn beide Hooks verfügbar sind, und enthält das benötigte CSS und JavaScript für den Button.

Nach der Installation sind die Defaults aktiviert: Anzeige nach 300 Pixeln, Stil circle und Position right. Das Modul registriert displayFooter, displayFooterAfter und displayBeforeBodyClosingTag; welcher unterstützte Hook von Ihrem Theme zuerst gerendert wird, gibt den Button aus, und spätere Hook-Aufrufe geben einen leeren String zurück, weil buttonRendered bereits gesetzt ist.

Das Template erstellt einen einzelnen fixierten Button mit ID mprb2t-btn, zugänglichem Label/Title, einem Inline-Up-Arrow-SVG sowie Inline-CSS/JavaScript. Es gibt in diesem Modul keine Produkt-, Kategorie- oder Seitenregel. Durch Aktivieren wird der Button daher überall verfügbar, wo das Theme einen dieser Footer-/Body-Closing-Hooks ausführt.

Ja, Sie können die Scroll-Distanz festlegen, bevor der Button erscheint. Die PrestaShop-Konfiguration speichert einen Show After-Wert in Pixeln, und das Storefront-JavaScript vergleicht diesen Schwellenwert mit window.pageYOffset, bevor es die sichtbare Button-Klasse hinzufügt oder entfernt.

Der Standard-Schwellenwert ist 300 Pixel, und das Admin-Feld wird als SHOW_AFTER gespeichert. Der Wert wird Smarty als mprb2t_show_after zugewiesen und wird im Template zur JavaScript-Variable threshold.

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

Der Scroll Listener wird passiv registriert, und toggleBtn() läuft auch einmal direkt nach dem Laden des Scripts. Dadurch ist der Button-Zustand korrekt, auch wenn ein Käufer über einen Anker auf einer Seite landet oder zu einer gescrollten Position zurückkehrt.

Ja, das Modul unterstützt die in seiner Konfiguration vorhandenen Styling-Optionen: runde oder quadratische Form und linke oder rechte Bildschirmposition. Das PrestaShop-Template wendet diese Werte auf Inline-CSS an; der Code enthält keinen Color Picker und keine Regeln für Seitentargeting.

Die installierten Defaults sind STYLE=circle und POSITION=right. Im Template schreibt POSITION=left left: 30px; jeder andere konfigurierte Wert folgt dem rechten Zweig und schreibt right: 30px. Für die Form schreibt STYLE=circle border-radius: 50%, während die quadratische Option einen kleinen Radius von 6px nutzt.

• Feste Abmessungen: Der Button ist 48 mal 48 Pixel groß, am unteren Viewport fixiert und nutzt z-index: 9999.
• Eingebaute Farben: Das Template verwendet einen dunklen Hintergrund, weiße Icon-Farbe und einen dunkleren Hover-Zustand. Diese Werte sind im aktuellen Template hart codiert.
• Praktische Grenze: In der Konfigurationsklasse gibt es keine Einstellung für Icon-Auswahl, Position je Gerät, Animationsdauer oder benutzerdefinierte Farben.

Ja, ein Klick auf den Button scrollt die Seite sanft zurück nach oben. Das PrestaShop-Storefront-Script lauscht auf den Button-Klick, verhindert die Standardaktion und ruft window.scrollTo mit top auf 0 und behavior auf smooth auf.

Der Click Handler ist klein und direkt: Er ist an den erzeugten mprb2t-btn-Button gebunden, ruft e.preventDefault() auf und weist den Browser dann an, mit nativem Smooth Scrolling nach oben zu scrollen.

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

Da das Modul das native scrollTo-Verhalten des Browsers statt einer eigenen Animationsschleife verwendet, bleibt es leichtgewichtig und speichert keinen Scroll-Zustand. Der Button wird erst sichtbar, nachdem der konfigurierte Schwellenwert überschritten ist; ein Klick lädt die Seite nicht neu und ändert die URL nicht.

Verwenden Sie MPR Compare, um PrestaShop eine clientseitige Vergleichsliste hinzuzufügen. Ausgewählte Produkt-IDs werden im Browser-localStorage unter dem Key mprcompare gespeichert, während das Modul Produktdetails nur per AJAX abfragt, wenn die Vergleichsseite oder schwebende Thumbnails Daten benötigen.

Der eigene Header-Kommentar des Moduls beschreibt das Design als null Datenbankspeicherung und null Cookies für die Interaktion auf Listing-Seiten. Produktlisten- und Produktseiten-Hooks geben statische Buttons mit einem data-id-product-Attribut aus; das Browser-Script fügt diese IDs zu localStorage hinzu oder entfernt sie und aktualisiert Button-Zustand, Zähler und Floating Bar lokal.

Der Server wird nur beteiligt, wenn echte Produktdaten benötigt werden. Die Vergleichsseite liest die IDs aus localStorage und postet sie an den Front Controller actions mit action=getProducts, während schwebende Thumbnails action=getProductImage aufrufen. Das Leeren der Vergleichsliste speichert einfach ein leeres Array zurück in localStorage.

Die Vergleichstabelle kann Produktname, URL, Cover-Bild, aktuellen Preis, alten Preis, Kurzbeschreibung, Referenz, Hersteller, Gewicht, Lagerstatus, Merkmale, Zustand und EAN13 anzeigen, wenn diese Werte vorhanden sind. Der AJAX Controller überspringt inaktive PrestaShop-Produkte.

Die Daten stammen aus geladenen Product-Objekten in der aktuellen Sprache und im aktuellen Shop. Preise werden aus Product::getPriceStatic() mit aktivierter Steuer formatiert; der alte Preis wird nur zurückgegeben, wenn der Preis ohne Reduktion höher ist als der aktuelle Preis. Cover-Bilder verwenden medium_default für die Vergleichstabelle und cart_default für den Floating-Thumbnail-Endpunkt.

• Merkmale: Der Controller ruft getFrontFeatures() auf und gibt jedes Feature-Name/Wert-Paar zurück, während das Front-Script eindeutige Feature-Namen zu Vergleichszeilen gruppiert.
• Verfügbarkeit: Der Lagerstatus wird aus Product::getQuantity($idProduct) > 0 zurückgegeben, ist also ein einfacher In-stock/Out-of-stock-Indikator.
• Fehlende Daten: Optionale Felder wie Hersteller, Referenz, Gewicht, EAN13 und alter Preis sind leer oder werden in der Tabelle ausgelassen, wenn PrestaShop keinen Wert dafür hat.

Ja, die maximale Vergleichsgröße ist konfigurierbar. Die Einstellung MAX_ITEMS ist bei der Installation standardmäßig vier, das Front-Script lehnt weitere Artikel ab, sobald das Limit erreicht ist, und der AJAX-Produktendpunkt kürzt eingehende IDs auf dasselbe konfigurierte Maximum.

Bei der Installation wird MAX_ITEMS mit dem Wert 4 erstellt; der Admin Controller speichert ihn mit einem Minimum von 1. Dieser Wert wird im Browser in mprCompareConfig.maxItems gesendet und außerdem dem Template der Vergleichsseite als maxItems zugewiesen.

var max = config.maxItems || 4;

Die Duplikatvermeidung erfolgt ebenfalls clientseitig: Wenn das Produkt bereits in localStorage ist, kehrt die Add-Funktion zurück, ohne es erneut hinzuzufügen. Der AJAX-Endpunkt kürzt die angeforderte ID-Liste trotzdem auf das konfigurierte Maximum, sodass eine manuell bearbeitete Anfrage die Vergleichsseite nicht mehr Produkte laden lassen kann als erlaubt.

Ja, es fügt Vergleichssteuerungen über PrestaShop-Hooks hinzu. Das Modul rendert Buttons auf Produktlisten und Produktseiten, einen Navigationszähler und eine optionale schwebende Vergleichsleiste mit Produkt-Thumbnails, Entfernen-Steuerungen und einem Link zur Vergleichsseite.

Für PrestaShop 1.7 und neuer registriert das Modul Media-, Produktseiten-, Navigations- und Body-Closing-Hooks; für ältere 1.6-Themes nutzt es die Legacy-Hooks für Header, Produktbutton, Navigation und Footer. Produktlisten-Buttons sind statische Links mit js-mprcompare-toggle, Produktseiten-Steuerungen sind Buttons, und beide verwenden denselben data-id-product-Wert für den JavaScript-Listenmanager.

Die Floating Bar wird von der Einstellung SHOW_FLOATING gesteuert, die standardmäßig aktiviert ist. Wenn ausgewählte Produkte vorhanden sind, zeigt das Script die Leiste, lädt Thumbnail-Daten per AJAX, wenn sie noch nicht gecacht sind, rendert Entfernen-Buttons für einzelne Produkte und hält Header-Zähler und Floating-Zähler mit der Anzahl der IDs in localStorage synchron.

Kunden können Feature Requests aus dem Produktseiten-Tab einreichen, wenn das Modul und die Produktanzeige aktiviert sind. In PrestaShop validiert der AJAX Controller Token, Produkt, Titel, Beschreibung und Gastidentitätsfelder und begrenzt anschließend Einreichungen nach Produkt und IP.

Der Produkt-Tab wird nur hinzugefügt, wenn ENABLED und SHOW_ON_PRODUCT aktiv sind und das Modul die Produkt-ID auflösen kann. Der Tab startet als Zusammenfassung/Lazy-Liste. Danach fordert das Front-Script die erste Seite von Einträgen an, sobald der Tab sichtbar wird, und nutzt dabei den konfigurierten Wert REQUESTS_PER_PAGE, der standardmäßig 10 ist.

• Sicherheit: Schreibaktionen erfordern ein CSRF-Token aus Tools::getToken(false). JavaScript holt ein Token mit action=getToken, wenn das initiale Tab-Markup nicht bereits eines enthält.
• Validierung: Der Titel muss mindestens 5 Zeichen haben, die Beschreibung mindestens 10 Zeichen, Gäste müssen einen Namen und eine gültige E-Mail angeben, und eingeloggte Kunden verwenden automatisch ihren Kontonamen und ihre E-Mail.
• Rate Limit: Der Controller erlaubt höchstens 3 Einreichungen für dasselbe Produkt und dieselbe IP-Adresse während des vorherigen Tages.
• Gespeicherte Daten: Der Request speichert Produkt, Kunden- oder Gastidentität, bereinigten Beschreibungstext, Shop, Sprache, IP-Adresse, Status, Zeitstempel und einen initialen Vote Count von 1.

Ja, Requests können Kundenlogin und Admin-Freigabe verlangen. In PrestaShop blockiert REQUIRE_LOGIN Gast-Einreichungen, REQUIRE_APPROVAL speichert neue Requests als submitted, und öffentliche Listen verbergen submitted-Elemente vor Nicht-Einreichern, bis sie in einen öffentlichen Status wechseln.

Die Defaults sind händlerfreundlich: REQUIRE_LOGIN ist aus, aber REQUIRE_APPROVAL ist an. Bei aktivierter Freigabe speichert der Controller neue Elemente als submitted; ohne Freigabe starten neue Elemente als under_review.

Sichtbarkeit wird im Modell gehandhabt, nicht nur im Template. Normale Produktlisten schließen sowohl declined als auch submitted aus und fügen submitted-Elemente nur dann wieder hinzu, wenn der aktuelle Betrachter anhand von Kunden-ID oder IP-Adresse zum Einreicher passt. Die indexierbare öffentliche Roadmap-Abfrage schließt submitted und declined ebenfalls aus, sodass ausstehende Ideen nicht zu öffentlichem SEO-Content werden.

Für den Einreicher kann JavaScript einen Pending-Hinweis anzeigen: Your request is pending review and only visible to you. Das macht den Freigabe-Workflow klar, ohne ungeprüfte Requests anderen Käufern zu zeigen.

Ja, Voting kann aktiviert werden, und Gast-Voting kann erlaubt oder blockiert werden. In PrestaShop toggelt der Vote-Endpunkt eine Stimme pro Request, verwendet Kunden-ID oder IP-basiertes Tracking und gibt eine Login-Anforderung zurück, wenn Gast-Voting deaktiviert ist.

Voting ist standardmäßig aktiv, während Gast-Voting standardmäßig aus ist. Wenn Gast-Voting deaktiviert ist und der Besucher nicht eingeloggt ist, enthält die AJAX-Antwort require_login, und das Front-Script leitet zum Sign-in-Link weiter, wenn einer vorhanden ist.

Die Vote-Speicherung erfolgt in einer separaten Tabelle mprfeaturerequest_vote. Eingeloggte Wähler werden über id_customer zugeordnet; Gäste, wenn erlaubt, über die IP-Adresse. Ein erneuter Aufruf des Endpunkts toggelt die Stimme aus, indem die bestehende Zeile gelöscht wird, während eine neue Stimme eine Zeile einfügt und den zurückgegebenen voted-Zustand auf true setzt.

Nach jedem Toggle berechnet das Modul den Request-Zähler neu, indem es vote_count mit einem Datenbankupdate erhöht oder verringert, das GREATEST(0, ...) verwendet. Dadurch kann die angezeigte Anzahl nicht unter null fallen. Neu eingereichte Requests erhalten außerdem automatisch eine eigene Request-Stimme, weshalb die Anfangszahl bei 1 startet.

Ja, der zentrale Roadmap-Hub kann indexierbar sein, wenn das Feature Requests-Modul aktiviert ist, die Roadmap-Seite aktiviert ist und die Einstellung INDEX_ROADMAP_PAGE die Indexierung erlaubt. Detailseiten, produktspezifische Roadmap-Seiten und AJAX-Endpunkte werden bewusst aus dem Index ausgeschlossen.

• Saubere URL des Roadmap-Hubs, zum Beispiel /feature-requests: Der Seitentyp roadmap verwendet die SEO-Richtlinie des Moduls. Wenn die Indexierung aktiviert ist, ergibt robots index, follow.
• Roadmap-Hub mit unterstützten Filter-/Sortierparametern, zum Beispiel /feature-requests?status=planned: Der Controller leitet diese per 301 (status, sort, view, search, page) zurück zum kanonischen Hub /feature-requests, sodass Duplikate nie indexiert werden. Jeder andere, nicht weitergeleitete Query-String wird mit noindex, follow gerendert.
• Produktspezifische Seite, zum Beispiel /feature-requests/module/my-product: Der Seitentyp module ist als nicht indexierbar konfiguriert, daher ergibt robots noindex, follow.
• Detailseite einer Anfrage, zum Beispiel /feature-requests/some-request: Der Seitentyp detail ist als nicht indexierbar konfiguriert, daher ergibt robots noindex, follow. Detail-404-Antworten senden außerdem X-Robots-Tag: noindex, nofollow, noarchive.
• AJAX-Endpunkt, zum Beispiel module/mprfeaturerequest/ajax: Der Controller sendet X-Robots-Tag: noindex, nofollow, noarchive.

Der Sitemap-Hook folgt derselben Logik: Er hängt die URL des Roadmap-Hubs nur an, wenn das Modul, die Roadmap-Anzeige, die Sitemap-Aufnahme und die SEO-Richtlinie es gemeinsam erlauben.

Der Codepfad ist auf das Rendern des JivoChat-Widgets aus displayBeforeBodyClosingTag beschränkt. Er prüft, ob das Modul aktiviert ist, ob eine WIDGET_ID existiert, ob die aktuelle Seite zum konfigurierten Seitenfilter passt und ob mobile Anzeige erlaubt ist, wenn der Besucher mobil ist.

Beim Rendern injiziert das Template das externe JivoChat-Script von //code.jivosite.com/widget/{widget_id}, optional nach der konfigurierten Verzögerung. Wenn PASS_USER_DATA aktiviert ist und der Kunde eingeloggt ist, definiert es jivo_onLoadCallback() und ruft jivo_api.setContactInfo() mit Namen und E-Mail des Kunden auf.

In dieser Quelle gibt es keine Modultabelle, kein Modell und keinen Controller für Chat-Nachrichten oder Transkripte. Das Entfernen oder Deaktivieren des PrestaShop-Moduls stoppt die Einbettung des Widgets, exportiert, löscht oder verwaltet aber keine Gesprächsverläufe, die von JivoChat gehalten werden.

hookPaymentOptions() zeigt Pay by Invoice nur, wenn jede Berechtigungsprüfung erfolgreich ist. Das Modul muss aktiv sein, die Moduleinstellung muss aktiviert sein, der Warenkorb muss einem eingeloggten Kunden gehören, und das Kundenobjekt muss korrekt geladen werden.

• Kundenprüfung: Gast-Warenkörbe und ungültige Kundendatensätze geben keine Zahlungsoption zurück.
• Gruppenprüfung: Der Kunde muss mindestens einer Gruppe angehören, die einer aktiven Zahlungsbedingung zugewiesen ist.
• Bedingungsprüfung: Nur aktive Bedingungen, die über mpr_payment_term_group verknüpft sind, werden zurückgegeben, sortiert nach Position und Tagen.
• Kreditprüfung: Das Modul nimmt das höchste Kreditlimit aus den Kundengruppen; 0 bedeutet unbegrenzt. Andernfalls müssen unbezahlte aufgeschobene Bestellungen plus aktueller Warenkorbwert innerhalb des Limits bleiben.
• Validierungsprüfung: Der Front Validation Controller wiederholt die Bedingungs- und Kreditprüfung, bevor er die Bestellung erstellt, sodass eine veraltete Checkout-Option die Regeln nicht umgehen kann.

Wenn eine Prüfung fehlschlägt, gibt das Modul eine leere Zahlungsoptionsliste zurück, und PrestaShop bietet Pay by Invoice für diesen Warenkorb einfach nicht an.

Die verfügbaren Bedingungen werden aus den Kundengruppen des aktuellen Warenkorbs berechnet. Der Service fragt aktive Bedingungen ab, die über mpr_payment_term_group verknüpft sind, verwendet die aktuelle Sprache für Name und Beschreibung der Bedingung und sortiert das Ergebnis nach position und danach days. Bei der Installation erstellte Standardbedingungen umfassen Due on Receipt sowie Net 15, Net 30, Net 60 und Net 90.

Das Checkout-Template rendert dann jede verfügbare Bedingung als Radio-Option, wobei die erste ausgewählt ist, zusammen mit Farbbadge, Fälligkeitstext und optionaler Beschreibung. Wenn das Kreditlimit nicht unbegrenzt ist, zeigt es außerdem verfügbaren Kredit und ausstehenden aufgeschobenen Betrag vor der Bedingungsliste.

Wenn der Kunde die Zahlungsoption absendet, liest der Validation Controller die ausgewählte mpr_pt_term_id, berechnet die Warenkorbsumme neu, ruft canPlaceDeferredOrder() erneut auf, erstellt die PrestaShop-Bestellung im konfigurierten Status OS_AWAITING, fällt bei Fehlen auf bankwire zurück und erstellt dann einen mpr_deferred_order-Datensatz mit Betrag, Kunde, Shop und Fälligkeitsdatum basierend auf den Tagen der ausgewählten Bedingung.

Das Fälligkeitsdatum wird berechnet, indem die Anzahl der Tage der ausgewählten Zahlungsbedingung zum Datum hinzugefügt wird, an dem die aufgeschobene Bestellung erstellt wird. Die standardmäßig installierten Bedingungen umfassen Due on Receipt / Net 0, Net 15, Net 30, Net 60 und Net 90.

• Wenn die Bestellung am 2026-06-17 mit Net 0 erstellt wird, ist das Fälligkeitsdatum 2026-06-17.
• Wenn die Bestellung am 2026-06-17 mit Net 15 erstellt wird, ist das Fälligkeitsdatum 2026-07-02.
• Wenn die Bestellung am 2026-06-17 mit Net 30 erstellt wird, ist das Fälligkeitsdatum 2026-07-17.

Das Modul speichert das Ergebnis als Datum im Format Y-m-d, nicht als Zeitstempel mit Uhrzeit. Die Berechnung verwendet das aktuelle PHP-Server-/Shop-Runtime-Datum, wenn die aufgeschobene Bestellung erstellt wird. Bestellungen nahe Mitternacht folgen daher der serverseitigen Datumsgrenze statt der lokalen Uhr des Kunden. Sommerzeitwechsel fügen dem gespeicherten Fälligkeitsdatum keine Stunde hinzu, können aber indirekt relevant sein, wenn die Bestellung nahe einer Datumsgrenze erstellt wird.

Beim Checkout wählt der Kunde eine Zahlungsbedingung über mpr_pt_term_id. Das Modul validiert, dass die Bedingung aktiv ist, zu einer der Kundengruppen gehört und zum effektiven Kreditlimit des Kunden passt, bevor es die PrestaShop-Bestellung erstellt. Erst nach der Bestellvalidierung erstellt es den Deferred-Payment-Datensatz mit ausgewählter Bedingung, Bestellsumme inklusive Steuer und berechnetem Fälligkeitsdatum.

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

Der gespeicherte Wert wird zum Bestellzeitpunkt in mpr_deferred_order.due_date kopiert. Das spätere Ändern der Tagezahl einer Zahlungsbedingung berechnet Fälligkeitsdaten bereits existierender Bestellungen nicht neu. Überfälligkeitsprüfungen vergleichen das gespeicherte Fälligkeitsdatum mit dem aktuellen Serverdatum. Eine unbezahlte Rechnung, die heute fällig ist, ist also heute noch fällig; sie wird erst überfällig, nachdem dieses Datum verstrichen ist.

Der Kreditlimit-Wert gilt pro Kundengruppe, nicht pro individuellem Kunden. Das Modul speichert Limits in mpr_pt_credit_limit, wobei id_group der Primary Key ist, und Zahlungsbedingungen selbst werden ebenfalls über mpr_payment_term_group Gruppen zugewiesen.

Bei einem Kunden in mehreren Gruppen ruft der Service alle Gruppen des Kunden ab und verwendet MAX(credit_limit) über diese Gruppen. Beispiel: Wenn Ana zu Retail ohne konfiguriertes Limit, B2B Silver mit 1000.00 und B2B Gold mit 2500.00 gehört, ist ihr effektives Kreditlimit 2500.00.

Ein konfiguriertes Limit von 0 wird vom Checkout Service als unbegrenzt behandelt. Wenn ein echtes Limit existiert, zieht das Modul die ausstehenden aufgeschobenen Bestellungen dieses Kunden im aktuellen Shop ab und zeigt Pay by Invoice-Bedingungen nur, wenn outstanding + cart total innerhalb des effektiven Gruppenlimits bleibt.

Kreditlimits und Verfügbarkeit von Bedingungen sind verwandt, aber getrennt. Ein Gruppenlimit zuzuweisen macht nicht automatisch jede Zahlungsbedingung verfügbar; die Bedingung muss außerdem aktiv und mindestens einer Kundengruppe zugewiesen sein. Ebenso bedeutet die Zuweisung einer Bedingung zu einer Gruppe ohne echtes Kreditlimit, dass die Gruppe die Bedingung verwenden kann, solange das effektive Limit als unbegrenzt aufgelöst wird oder eine andere Gruppe ausreichend Limit liefert.

Der ausstehende Betrag wird aus unbezahlten Zeilen in mpr_deferred_order für denselben Kunden und aktuellen Shop berechnet. Bereits als bezahlt markierte Zeilen werden ausgeschlossen, und die für die neue Bestellung verwendete Warenkorbsumme ist die Bestellsumme inklusive Steuer. Wenn der Kunde über dem effektiven Limit liegt, entfernt der Checkout Service alle Deferred-Bedingungen aus den verfügbaren Zahlungsoptionen, und der Validation Controller lehnt eine übermittelte Deferred-Zahlung ab, selbst wenn jemand die Bedingung manuell postet.

Die Installation erstellt einen Bestellstatus namens Awaiting Deferred Payment, speichert seine ID in OS_AWAITING, und der Validation Controller verwendet diesen Status, wenn er validateOrder() für Pay by Invoice-Bestellungen aufruft. Wenn der gespeicherte Status fehlt, fällt der Controller auf PrestaShops Bankwire-Status zurück.

• logable = true bedeutet, dass PrestaShop die Bestellung als gültig platzierte Bestellung für Bestellhistorie- und Statistik-Workflows behandelt, obwohl die Zahlung noch aussteht.
• invoice = true und pdf_invoice = true bedeuten, dass Rechnungserzeugung für den Deferred-Bestellstatus aktiviert ist.
• paid = false bedeutet, dass der Bestellstatus die Bestellung nicht als bezahlt markiert; das Modul verfolgt die Begleichung separat in mpr_deferred_order.is_paid.

Wenn der Deferred-Datensatz erstellt wird, startet is_paid mit 0. Die Methode markAsPaid() des Deferred-Order-Modells setzt is_paid später auf 1 und zeichnet paid_date auf, ohne die Bedeutung des initialen Bestellstatus zu ändern.

Der installierte Status gehört dem Modul, verwendet das Label Awaiting Deferred Payment in jeder Sprache und wird mit send_email = false, unremovable = false und einem blauen Farbwert erstellt. Die Payment-Return-Seite kann dann die ausgewählte Zahlungsbedingung, den fälligen Betrag und das Fälligkeitsdatum anzeigen, während die Bestellung aus Sicht des PrestaShop-Zahlungsstatus unbezahlt bleibt.

Es gibt eine wichtige Back-Office-Nacharbeit: Wenn ein Admin eine aufgeschobene Bestellung über den Deferred-Orders-Controller des Moduls als bezahlt markiert, aktualisiert das Modul zuerst mpr_deferred_order. Wenn die zugehörige PrestaShop-Bestellung noch im Awaiting-Status des Moduls ist und der Standard-Paid-Status PS_OS_PAYMENT existiert, verschiebt es die PrestaShop-Bestellung auch in diesen bezahlten Status. Wenn die Bestellung bereits in einen anderen Status verschoben wurde, überschreibt das Modul diesen Status nicht blind.

Eine echte Benachrichtigung wird aus gultigen PrestaShop-Bestellungen im aktuellen Shop erstellt, begrenzt durch das konfigurierte maximale Bestellalter sowie Produkt-Include- oder Exclude-Regeln. Sie verwendet das bestellte Produkt, die Lieferstadt und den maskierten Vornamen.

Nein. Generierte Sales Notifications sind keine echten PrestaShop-Bestellungen und werden nicht in die Orders-Tabelle geschrieben. Das Modul hat drei Benachrichtigungsmodi:

• Nur echte Bestellungen: Zeigt aktuelle gültige Bestellungen aus PrestaShop mit maskierten Kundennamen, Stadt, Produktdaten, Produktbild, Preis und relativer Zeit.
• Nur generiert: Baut realistisch wirkende Benachrichtigungen aus aktiven Katalogprodukten plus konfigurierten oder eingebauten Namens- und Städte-Pools. Das sind Anzeigemeldungen, keine Bestellungen.
• Gemischt: Verwendet zuerst echte Bestellbenachrichtigungen und füllt verbleibende Plätze mit generierten Benachrichtigungen, wenn es nicht genug aktuelle echte Bestellungen gibt.

Der Standard-Installationsmodus ist mixed. Im Mixed-Modus erzeugt der Code automatisch Füllungen, wenn echte Benachrichtigungen weniger als die angeforderte Anzahl sind; es gibt keinen separaten Generated-Fill-Schalter innerhalb des Mixed-Modus. Wenn jede Benachrichtigung einem echten Kauf entsprechen muss, stellen Sie das Modul auf den Modus Nur echte Bestellungen um und stellen Sie sicher, dass maximales Bestellalter und Produktfilter breit genug sind, um aktuelle Bestellungen zurückzugeben.

Echte Benachrichtigungen werden aus gültigen PrestaShop-Bestellungen im aktuellen Shop geladen, begrenzt durch das konfigurierte maximale Bestellalter. Das Standard-Maximalalter ist 72 Stunden. Produkt-Include- und Exclude-Listen werden angewendet, bevor die Benachrichtigung zurückgegeben wird, und der angezeigte Kundenname wird maskiert, statt den vollständigen Vornamen zu zeigen.

Generierte Benachrichtigungen werden aus aktiven Produkten im Katalog gebaut. Das Modul wählt Produktdaten, berechnet einen Anzeigepreis, versucht das Produkt-Cover-Bild zu verwenden, wählt Name und Stadt aus seinen Pools und erstellt eine relative Zeit wie eine kürzliche Anzahl von Minuten. Das passiert zur Anzeigezeit über den Front-Office-Benachrichtigungsendpunkt; es erstellt keine Warenkörbe, Bestellungen, Kunden, Bestelldetails, Zahlungen oder Bestellhistorienzeilen.

Das Front-End-Toast labelt Benachrichtigungen im Display-Template als Verified Purchase, einschließlich generierter Benachrichtigungen. Dieses Label ist Teil der Pop-up-Präsentation, kein Beweis, dass eine generierte Benachrichtigung aus einer echten Bestellung stammt. Für strikt compliance- oder audit-sensible Shops verwenden Sie den Modus Nur echte Bestellungen.

Ja. Die Konfiguration akzeptiert kommagetrennte Include- und Exclude-Produkt-ID-Listen. Diese Filter werden sowohl bei der Auswahl echter Bestellpositionen als auch bei der Auswahl von Produkten fur generierte Benachrichtigungen angewendet.

Der Front Controller notifications gibt JSON mit einem noindex-Antwortheader zuruck, wenn das Modul aktiviert ist. Das Browser-Script ruft diesen Feed ab und rendert die Toast-Benachrichtigungen entsprechend den Timing-Einstellungen.

Nein, das Modul erstellt den Storefront-Einstiegspunkt zu Telegram. Nachdem der Käufer klickt, übernimmt Telegram die Unterhaltung in der Telegram-App oder Web-Erfahrung. Dadurch bleibt das Modul einfach und vermeidet ein zweites Nachrichtenpostfach in PrestaShop.

Das Widget rendert einen fixierten Telegram-Link mit dem konfigurierten Benutzernamen. Wenn eine optionale vorbefüllte Nachricht konfiguriert ist, fügt das Modul sie der https://t.me/...-URL hinzu und ersetzt {url} durch die aktuelle Seiten-URL, bevor der Käufer zu Telegram gesendet wird. Der Browser öffnet Telegram in einem neuen Tab oder App-Kontext; der Chat selbst ist nicht in die PrestaShop-Seite eingebettet.

Das Modul speichert keine eingehenden Telegram-Nachrichten, erstellt keine PrestaShop-Kundendienst-Threads und betreibt keinen Telegram-Webhook oder Bot-Posteingang im Back Office. Gesprächsverlauf, Antworten, Anhänge und Benachrichtigungen bleiben in Telegram.

Die Anzeige wird durch die Moduleinstellungen gesteuert. Das Widget rendert nur, wenn das Modul aktiviert ist und ein gültiger Telegram-Benutzername vorhanden ist. Sie können außerdem Storefront-Position, Icon- oder Bar-Stil, Call-to-action-Text, Farbe, Größe, Abstand, Tooltip, Animation, Anzeigeverzögerung, mobile Sichtbarkeit und Seitenscope wie alle Seiten, Produktseiten, Kategorieseiten oder Checkout-Seiten steuern.

Ja, Weekly Flash Sale kann automatisch posten, aber nur über kompatible Publisher-Module. Die Aufgabe sucht nach mprinstagramintegration mit publishToInstagram(), mprfacebookpostsintegration mit publishToFacebook() und mprxintegration mit publishToX(). Sie baut jede Caption aus den Instagram-, Facebook- und X-Templates mit Platzhaltern wie {product_name}, {original_price}, {sale_price}, {discount}, {code} und {product_url}.

• ok:... bedeutet, dass der Publisher ein Plattform-Ergebnis zurückgegeben hat, sodass der Versand als erfolgreich behandelt wurde.
• skipped bedeutet, dass das Plattformmodul fehlt oder inaktiv ist, die erforderliche Publish-Methode fehlt oder die Caption für diese Plattform leer ist.
• FAIL bedeutet, dass die Publish-Methode false zurückgegeben hat.
• FAIL:message bedeutet, dass der Publisher eine Exception geworfen hat, und die Nachricht nach dem Präfix wird zur Diagnose gespeichert.
• dry-run ist ein Gesamtstatus für Testläufe. Die Aufgabe kehrt zurück, bevor sie die Warenkorbregel erstellt, veröffentlicht oder Sale-Historie schreibt.
• disabled wird zurückgegeben, wenn Weekly Sale deaktiviert ist und der Lauf kein Dry Run ist.

Bei echten Ausführungen werden die Ergebnisse je Plattform in mprweeklysale_history als ig_result, fb_result und x_result gespeichert, zusammen mit Produkt, Rabatt, generiertem Code und Sale-Daten.

Der automatische Post ist Teil der Flash-Sale-Aufgabe. Ein echter Lauf wählt zuerst ein aktives Produkt, das gemäß dem konfigurierten History-Fenster kürzlich nicht verwendet wurde, erstellt eine Cart Rule für den Rabatt und ruft dann die verfügbaren Social-Publisher-Module auf. Die Standardkonfiguration nutzt 50% Rabatt, eine Dauer von 24 Stunden, Code-Präfix FLASH, ein 12-Wochen-History-Fenster und einen wöchentlichen Zeitplan am Mittwoch um 08:00.

Die generierte Cart Rule ist produktspezifisch, aktiv, hervorgehoben, auf Menge 1000 und Menge pro Nutzer 1 begrenzt. Captions werden gebaut, nachdem Sale-Preis, Rabattcode, Produkt-URL und Produktbild vorbereitet wurden. Die X-Caption wird gekürzt, um ins Plattformlimit zu passen, und auch die Instagram-Caption wird vor der Veröffentlichung begrenzt.

Automatisches Posting erfordert daher mehr als das Aktivieren von Weekly Flash Sale. Das passende Integrationsmodul muss installiert, aktiv sein und die erwartete Publish-Methode bereitstellen, und die geplante Cron-Aufgabe muss mit dem korrekten Token laufen. Wenn ein Plattformmodul fehlt, kann der Sale trotzdem erstellt werden, und die fehlende Plattform wird als skipped aufgezeichnet.

Verwenden Sie den Homepage-Slider des Moduls, um ein Hero-Carousel über PrestaShops displayHome-Hook zu rendern. Der Code löst den Standard-Slider über den Homepage-Identifier auf, lädt seine aktiven Banner, verbindet aktuelle Sprach-/Shop-Textfelder, wenn verfügbar, und gibt das Carousel nur aus, wenn nutzbare Bilder existieren.

Bei der Installation legt das Modul einen aktiven Slider mit dem Identifier homepage an. Um einen Homepage-Hero anzuzeigen, erstellen oder bearbeiten Sie Banner für diesen Slider, laden mindestens ein gültiges Bild hoch, lassen das Banner aktiv und stellen sicher, dass das Modul an displayHome gehookt bleibt. Der Hook ruft denselben Widget Renderer mit slider = homepage auf, daher folgt die Homepage-Ausgabe denselben Regeln wie eingebettete Widgets.

Die Carousel-Abfrage lädt aktive Banner, die dem ausgewählten Slider zugewiesen sind, und sortiert sie nach Position und anschließend nach Banner-ID. Die Sprach-/Shop-Zeile wird mit einem LEFT JOIN verbunden, sodass Titel, Untertitel und CTA-Text aus aktueller Sprache und aktuellem Shop genommen werden, wenn diese Zeile existiert. Ein Banner wird aber nicht verworfen, nur weil die Sprach-/Shop-Textzeile fehlt. Dadurch kann ein nicht übersetztes reines Bildbanner trotzdem rendern.

Wenn kein aktives Banner eine existierende Desktop- oder Mobile-Bilddatei hat, gibt das Modul einen leeren String zurück, statt einen kaputten Hero-Bereich zu rendern.

Das Anzeigeverhalten kommt aus der Modulkonfiguration. Die Standardgeschwindigkeit ist 5000 Millisekunden, Autoplay ist aktiviert, Controls und Indicators sind aktiviert, der Übergang ist slide, Ken-Burns-Styling ist aktiviert, und die Standardhöhe ist 500. Das Template gibt außerdem dem ersten Slide Eager Loading und Fetch Priority, während spätere Slides lazy-loaded werden, um das initiale Seitengewicht zu reduzieren.

Ja, jedes Banner kann ein Desktop-Bild und ein optionales Mobile-Bild für PrestaShop speichern. Das Carousel-Template gibt responsive Picture Sources aus, verwendet das Mobile-Bild auf kleinen Bildschirmen und ergänzt AVIF- oder WebP-Sources, wenn passende Dateien neben den konfigurierten Bildern existieren.

Das Mobile-Bild ist für schmale Bildschirme vorgesehen und wird mit einer Media Condition max-width: 767px ausgegeben. Das Desktop-Bild bleibt das normale Fallback-Bild für den Slide. Daher ist es am besten, für jedes Banner ein Desktop-Bild hochzuladen und ein Mobile-Bild zu ergänzen, wenn der Zuschnitt für Smartphones anders sein soll.

Das Modul konvertiert Bilder nicht während des Renderns. Es prüft, ob Geschwisterdateien mit demselben Basisnamen und den Erweiterungen .avif oder .webp bereits existieren, und fügt diese Sources dann hinzu. Wenn diese optimierten Dateien nicht auf dem Datenträger liegen, fällt das Carousel auf die ursprünglichen Upload-Pfade zurück.

Ein Banner ohne Desktop- oder Mobile-Bilddatei wird vor dem Rendern übersprungen. Das verhindert leere Carousel-Slides. Wenn nur ein Mobile-Bild existiert, kann das Banner die Datei-Prüfung trotzdem bestehen, aber Desktop-Besucher haben möglicherweise kein passendes Desktop-Fallback-Bild. Daher sollte die Händler-Einrichtung das Desktop-Bild als Basis und das Mobile-Bild als optionalen responsiven Override behandeln.

Ja, das Modul implementiert PrestaShop-Widget-Rendering für Slider außerhalb der Homepage. Ein Template kann das Widget mit einer numerischen slider_id oder mit einem Slider-Identifier aufrufen, der in der Slider-Tabelle des Moduls gespeichert ist.

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

Wenn kein Parameter übergeben wird, löst das Modul den Standard-homepage-Slider auf. Der Code weist Slider nicht automatisch CMS-Seiten zu; er löst den Slider aus den Widget-Parametern auf und rendert dann nur aktive Banner für diesen Slider, die ein verfügbares Desktop- oder Mobile-Bild haben.

Die Identifier-Version funktioniert nur für aktive Slider, weil die Suche den Active Check der Slider-Tabelle verwendet. Der numerische slider_id-Pfad lädt genau diese Slider-ID. Nachdem ein Slider aufgelöst ist, wird dieselbe Rendering-Pipeline wie auf der Homepage verwendet: aktuelle Sprache, aktueller Shop, aktive Banner, Datei-Existenzprüfungen, responsive Sources, Carousel-Einstellungen und das gemeinsame Carousel-Template.

Es gibt einen Code-Kommentar zu slider_cms, aber der implementierte Resolver behandelt slider_id, slider und den Standard-Homepage-Slider. Für CMS-Seiten oder Landing Pages verwenden Sie einen expliziten Widget-Aufruf im Seiteninhalt oder Theme-Template, statt zu erwarten, dass das Modul CMS-Seiten automatisch Slidern zuordnet.

Sie können den echten Bannerinhalt konfigurieren, der vom PrestaShop-Carousel verwendet wird: übersetzter Titel, Untertitel, CTA-Text und CTA-URL. Jedes Banner speichert außerdem Overlay-Farbe, Overlay-Deckkraft, Textausrichtung, Aktivstatus, Position, Desktop-Bild und optionales Mobile-Bild.

Die Inhaltsfelder sind mehrsprachig, sodass Bannertitel, Untertitel, Button-Text und Button-URL je Sprache variieren können. Der Titel wird als Hauptüberschrift des Slides verwendet, der Untertitel erscheint darunter, und der CTA-Button erscheint nur, wenn sowohl CTA-Text als auch CTA-URL für diese Sprache vorhanden sind.

Visuelle Steuerungen werden beim Banner selbst gespeichert. Die Overlay-Farbe ist standardmäßig Schwarz, Overlay-Deckkraft ist ein Prozentwert, und Textausrichtung unterstützt left, center und right. Das Active-Flag steuert, ob das Banner erscheinen kann, und der Positionswert steuert die Reihenfolge innerhalb des ausgewählten Sliders.

Die Bildfelder sind die tatsächlichen Medien, die vom Carousel verwendet werden. Das Desktop-Bild ist das primäre Slide-Bild, und das optionale Mobile-Bild gibt Smartphones einen anderen Zuschnitt. Der Admin-Upload-Flow akzeptiert gängige Webformate wie JPG, PNG, WebP und GIF, während der Front-Office-Renderer zusätzlich AVIF- oder WebP-Sources hinzufügen kann, wenn passende optimierte Dateien auf dem Datenträger existieren.

Leere Textfelder sind erlaubt. Ein Banner kann daher als rein visueller Slide, als Text-over-image-Hero oder als Promotion-Slide mit Button genutzt werden, abhängig davon, welche übersetzten Felder gefüllt sind.

Ja, eingereichte Nachrichten werden in PrestaShop gespeichert. Der Processor erstellt einen Submission-Datensatz mit Status, Spam-Flag, IP-Adresse, User Agent, Kunden- oder Gastkontext und speichert anschließend jeden übermittelten Feldwert in der Submission-Data-Tabelle des Moduls.

Die Haupt-Submission-Zeile wird in mprcontactform_submission gespeichert. Sie enthält Formular-ID, Shop-ID, Kunden-ID, wenn der Besucher eingeloggt ist, Kundenname, Kunden-E-Mail, IP-Adresse, User Agent, Status, Spam-Flag, Spam-Grund und Erstellungsdatum. Gast-Submissions werden mit Kunden-ID 0 gespeichert.

Einzelne Antworten werden separat in mprcontactform_submission_data gespeichert. Jede Zeile speichert Submission-ID, Feld-ID, Feldname und übermittelten Feldwert. So kann das Modul den Submission-Header und dynamische Formularfelder getrennt halten, was wichtig ist, weil jedes Formular einen anderen Satz von Feldern haben kann.

Der Processor validiert das aktive Formular und seine aktiven Felder vor dem Speichern. Pflichtfelder, E-Mail-Format, Telefonformat, URL-Format, numerische Felder, Select-Optionen, benutzerdefinierte Validatoren und die GDPR-Checkbox können die Submission ablehnen, bevor sie aufgezeichnet wird. Anschließend laufen Anti-Spam-Prüfungen; Spam-Submissions werden trotzdem mit is_spam = 1 und Grund gespeichert, aber normale Admin- und Kunden-E-Mails werden nur für Nicht-Spam-Submissions gesendet.

Die IP-Adresse wird aus Forwarded Headers genommen, wenn vorhanden, sonst aus der Remote-Address-Fallback, und der User Agent wird mit Längenbegrenzung gespeichert. Das erstellt einen Audit Trail für Anfragen, ohne das Modul in ein vollständiges CRM zu verwandeln; Nachverfolgung erfolgt weiterhin über die konfigurierten E-Mail-Empfänger oder den Back-Office-Workflow, den der Händler zur Prüfung von Submissions verwendet.

Ja, Anfragen können an konfigurierte Admin-Empfänger geroutet werden. Jedes Formular kann Admin-E-Mail-Adressen und eine Betreffzeile definieren; der Mailer akzeptiert kommagetrennte Empfänger und fällt auf die globale Modul-E-Mail oder die Shop-E-Mail zurück, wenn ein Formularempfänger leer ist.

Dieses Routing erfolgt pro Formular, sodass ein Kontaktformular Sales-Anfragen an ein Postfach senden kann, während ein anderes Formular Support-Anfragen an ein anderes Postfach sendet. Das Formular hat außerdem eine Einstellung send_admin_email; wenn Admin-E-Mails für dieses Formular deaktiviert sind, kann die Submission trotzdem gespeichert werden, ohne eine Admin-Benachrichtigung zu senden.

Der Empfänger-Fallback passiert der Reihe nach. Der Mailer nutzt zuerst die Admin-E-Mail-Liste des Formulars, dann die Module-Level-Admin-E-Mail-Einstellung und dann PS_SHOP_EMAIL. Mehrere Empfänger können als kommagetrennte Liste eingegeben werden. Ungültige E-Mail-Adressen werden übersprungen, statt für den Versand verwendet zu werden.

Der Admin-Betreff kommt aus dem übersetzten E-Mail-Betreff des Formulars, wenn gesetzt, andernfalls fällt er auf einen generischen New-Submission-Betreff zurück. Der Shopname wird angehängt, und die übermittelte Kunden-E-Mail wird als Reply-to-Adresse verwendet, wenn verfügbar, sodass Antworten aus dem Postfach an den Kunden zurückgehen können.

Die Kundenbestätigung ist getrennt. Wenn send_customer_email aktiviert ist und die Submission eine Kunden-E-Mail-Adresse enthält, kann das Modul dem Besucher ebenfalls eine Bestätigungsnachricht senden. Spam-Submissions werden zur Prüfung gespeichert, aber der Mailer wird für sie nicht aufgerufen. Spam wird daher normalerweise nicht an Admin-Empfänger oder Kunden weitergeleitet.

Ja. Das Modul prüft Submissions vor dem Versand von E-Mails, markiert erkannten Spam im Submission-Datensatz und speichert einen Spam-Grund. Die Quelle enthält diese Anti-Spam-Auslöser:

• Honeypot: Das versteckte Feld website_url_confirm muss leer bleiben.
• Submit timing: Der versteckte _mpr_ft-Zeitstempel muss vorhanden, gültig und älter sein als das konfigurierte min_submit_time des Formulars.
• Rate limit: Die Absender-IP wird blockiert, wenn sie die maximale Anzahl von Submissions pro Stunde für das Formular bereits erreicht hat.
• Blocked IPs: Die Absender-IP wird mit der zeilenweise getrennten Blocked-IP-Liste des Formulars verglichen.
• Blocked words: Jedes übermittelte Feld wird anhand einer case-insensitive Substring-Suche auf konfigurierte blockierte Wörter geprüft.

Standardmäßig aktivieren neu installierte Formulare Honeypot und Timing-Prüfung mit einer Mindest-Submit-Zeit von 3 Sekunden. Spam-Submissions werden zur Prüfung gespeichert, aber der normale Admin-/Kunden-E-Mail-Flow läuft nur für Nicht-Spam-Submissions.

Das Module-Level-Standard-Rate-Limit ist 10 Submissions pro IP und Stunde. Das Setzen der maximalen Submissions pro IP und Stunde auf 0 deaktiviert diese Rate-Limit-Prüfung. Die Rate-Limit-Abfrage zählt gespeicherte Submissions von derselben IP-Adresse in der vorherigen Stunde, sodass wiederholte Versuche blockiert werden können, selbst wenn der Besucher dasselbe Formular erneut absendet.

Die Timing-Prüfung soll automatisierte Posts erkennen, die sofort senden oder den versteckten Zeitstempel auslassen. Ein echter Besucher erhält das versteckte _mpr_ft-Feld mit dem Formular, während ein Bot, der direkt postet, ohne die Seite zu laden, meist an der Zeitstempelanforderung scheitert.

Spam-Gründe werden als maschinenlesbare Labels wie honeypot, timing, rate_limit, blocked_ip und blocked_words gespeichert. Mehr als ein Grund kann bei derselben Submission aufgezeichnet werden. Das hilft, einen einfachen zu schnellen Submit von einer Nachricht zu unterscheiden, die zusätzlich blockierte Formulierungen enthält.

Ja, es kann die Standard-Kontaktseite von PrestaShop ersetzen, wenn diese Einstellung aktiviert ist. Das Modul fügt Kontakt-Routen hinzu und nutzt den Dispatcher-Hook, um den Core Contact Controller auf sein eigenes Kontaktseiten-Rendering umzuleiten, während normale Modul-Display-Links verfügbar bleiben.

Die Einstellung ist standardmäßig deaktiviert. Wenn replace_core_contact aktiviert ist, stellt das Modul Kontakt-Routen über hookModuleRoutes bereit, verwendet dabei möglichst den Contact-Page-Rewrite des Shops und behandelt außerdem den Core-contact-Controller über den Dispatcher-Hook.

Implementierungstechnisch sendet der Dispatcher-Hook keinen browserseitigen 301- oder 302-Redirect. Er schreibt die aktuellen Request-Parameter an Ort und Stelle um, indem er den Controller zum Module Display Controller ändert und den Modulnamen auf mprcontactform setzt. Der Käufer bleibt im Kontaktfluss, aber PrestaShop rendert die Kontaktseite des Moduls statt des Core Contact Controllers.

Das Modul kann Formulare außerdem über seine eigene Module-Display-Route und über Hooks wie displayMprContactForm und displayContactContent rendern. Das bedeutet, Händler können die Hauptkontaktseite ersetzen, ein bestimmtes Formular anderswo einbetten oder die Core-Kontaktseite unverändert lassen und nur Modullinks nutzen.

Wenn der Ersatz nicht aktiviert ist, gibt der Route Hook keine Kontakt-Ersatzrouten zurück, und die Core-Kontaktseite bleibt unter normaler Kontrolle von PrestaShop. Dadurch ist die Funktion über die Konfiguration reversibel, ohne das Modul zu deinstallieren.

Das Modul fügt der PrestaShop-Admin-Bestelldetailseite eine Löschaktion hinzu. Es rendert über die Hooks displayAdminOrderMain und displayAdminOrder, wenn das Modul aktiviert ist und eine Bestell-ID verfügbar ist, und sendet die Bestellung dann in den Trash Flow des Moduls.

Bei einer Standardinstallation ist das Modul aktiviert und Bestätigung erforderlich. Die Bestellseite zeigt einen Delete Order-Block mit einem Button, der mit einem trash_order-Parameter auf den Modul-Admin-Controller verlinkt. Wenn Bestätigung aktiviert ist, fügt das Template vor dem Absenden der Aktion eine Browser-Bestätigungsabfrage hinzu.

Wenn der Admin bestätigt, übergibt der Controller die Bestell-ID und die aktuelle Mitarbeiter-ID an den Trash Service. Der Service lädt die PrestaShop-Order, erstellt den Trash Snapshot, speichert, wer sie gelöscht hat, und ruft anschließend PrestaShops native Order-Delete-Methode auf. Wenn die Bestellung nicht als gültiges Objekt geladen werden kann, gibt die Trash-Aktion false zurück, statt irgendetwas zu löschen.

Die Aktion ist für Test-, doppelte oder unerwünschte Bestellungen gedacht, die ein Händler bewusst aus dem Back Office entfernen möchte. Es ist kein Soft-Hide-Flag auf der ursprünglichen Bestellzeile; nachdem der Trash Flow abgeschlossen ist, wurde die native PrestaShop-Order-Delete-Methode aufgerufen, und der verbleibende Moduldatenensatz ist nur der Trash Snapshot.

Vor dem Löschen lädt das Modul die PrestaShop-Order, erstellt eine kompakte JSON-Zusammenfassung, fügt eine Zeile in mprdeleteorders_trash ein und ruft danach die native Order-Delete-Methode auf. Die Trash-Tabelle bleibt bei der Deinstallation aus Sicherheitsgründen bewusst erhalten.

{"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: Die ursprüngliche PrestaShop-Bestell-ID, zusätzlich als Top-Level-Spalte der Trash-Tabelle zur Filterung gespeichert.
• reference: Die Bestellreferenz, zusätzlich als order_reference gespeichert.
• id_customer: Die Kunden-ID, die mit der gelöschten Bestellung verknüpft ist.
• total_paid: Die Bestellsumme aus total_paid_tax_incl.
• date_add: Das ursprüngliche Erstellungsdatum der Bestellung.
• current_state: Die Bestellstatus-ID zum Löschzeitpunkt.
• deleted_by: Die Back-Office-Mitarbeiter-ID, die die Trash-Aktion geklickt hat.
• date_deleted: Wann der Trash-Datensatz erstellt wurde.

Das ist ein Audit Snapshot, kein vollständiges reversibles Backup jeder bestellbezogenen Tabelle, Rechnung, Nachricht und Positionszeile. Verwenden Sie ihn, um vor dem endgültigen Bereinigen zu identifizieren, was gelöscht wurde und von wem.

Die Trash-Tabelle selbst speichert id_trash, id_order, order_reference, order_data, deleted_by und date_deleted. Der List Controller kann diese Trash-Zeilen anzeigen, sodass ein Admin die ursprüngliche Bestell-ID, Referenz, den löschenden Mitarbeiter und das Löschdatum prüfen kann.

Das JSON enthält bewusst nur eine kleine Menge von Bestell-Header-Werten. Es speichert keine Produkte, Bestelldetails, Adressen, Zahlungen, Rechnungen, Nachrichten, Versanddienstzeilen, Warenkorbinhalte, Gutscheine oder Bestandsbewegungshistorie. Deshalb sollte es als Nachvollziehbarkeit für Löschungen behandelt werden, nicht als Wiederherstellungspaket.

Nein, das Modul baut eine gelöschte PrestaShop-Bestellung nicht aus dem Trash neu auf. Wenn eine Bestellung in den Trash verschoben wird, speichert es einen kleinen JSON Snapshot mit Werten wie Bestell-ID, Referenz, Kunden-ID, bezahlter Summe, Erstellungsdatum und aktuellem Status und ruft anschließend PrestaShops Order-Delete-Methode auf.

Die Restore-Methode liest nur die Trash-Zeile, bestätigt, dass sie existiert, löscht diese Trash-Zeile und gibt Erfolg für diese Cleanup-Aktion zurück. Sie erstellt die ursprüngliche Bestellzeile, Bestelldetails, Zahlungen, Rechnungen, Bestellhistorie, Warenkorbdaten oder verwandte Datensätze nicht neu.

Diese Einschränkung ist wichtig, weil das Modul nicht genug relationale Daten speichert, um eine sichere vollständige Wiederherstellung einer Bestellung durchzuführen. Behandeln Sie den Trash als Audit- und Cleanup-Puffer, nicht als vollständiges Backup. Für echte Wiederherstellung verwenden Sie ein Datenbankbackup oder einen manuellen Restore-Prozess außerhalb dieses Moduls.

Die permanente Trash-Cleanup-Aktion ist ebenfalls von der Bestellwiederherstellung getrennt. Das Entfernen einer Trash-Zeile entfernt nur den Audit Snapshot des Moduls; es beeinflusst keine bereits gelöschte PrestaShop-Bestellung, weil die ursprünglichen Bestelldaten bereits durch den nativen Delete-Aufruf entfernt wurden.

Für Live-Shops ist der praktische Workflow: Nutzen Sie das Modul zum Bereinigen bekannter Test- oder unerwünschter Bestellungen, behalten Sie Datenbankbackups zur Wiederherstellung und prüfen Sie die Bestellung vor dem Löschen. Wenn eine Bestellung möglicherweise mit Produkten, Zahlungen, Rechnungen und Historie intakt wiederhergestellt werden muss, verlassen Sie sich nicht auf die Trash-Zeile des Moduls als Wiederherstellungsquelle.

Nein, die Deinstallation behält die Papierkorb-Tabelle aus Sicherheitsgründen. In PrestaShop entfernt das Modul Tabs und Konfiguration, aber der Codekommentar sagt, dass mprdeleteorders_trash beim Deinstallieren nicht gelöscht wird.

Ja. Wenn Purchase Tracking aktiviert ist und das Modul den Besucher tracken darf, feuert es ein Hotjar-purchase-Event aus dem PrestaShop-Bestellbestätigungs-Hook. Das Front-Office-Template ruft hj('event', 'purchase') auf der Bestellbestätigungsseite auf.

Das ist für Hotjar-Analysen nützlich, weil Sie Recordings, Heatmaps, Surveys oder Funnels nach Sessions filtern können, die einen Kauf erreicht haben, und dann das Verhalten vor der Bestellung prüfen. Es hilft Fragen zu beantworten, etwa wo Käufer gezögert haben, welche Checkout-Schritte sie wiederholt haben oder welche Seitenmuster in erfolgreichen Sessions auftreten.

Es ist kein Ersatz für Umsatzanalysen oder serverseitiges Bestellreporting. Hotjar erhält das benannte Event für Behavioral Segmentation; die Bestelldetails des Moduls werden hauptsächlich genutzt, um lokalen Event-Kontext zu bauen, und sind kein vollständiger Transaktionsfeed.

Die Funktion hängt von den normalen Hotjar-Modul-Guards ab. Das Modul muss aktiviert sein, die Hotjar Site ID muss als Ziffern konfiguriert sein, Purchase Tracking muss aktiviert sein, und der Besucher muss die Tracking-Prüfungen des Moduls bestehen, etwa Consent Handling, wenn Consent Respect aktiviert ist. Wenn Tracking nicht erlaubt ist, gibt der Bestellbestätigungs-Hook nichts zurück.

Wenn der Hook läuft, baut das Modul lokalen Purchase-Kontext aus der PrestaShop-Bestellung, einschließlich Werten wie Bestell-ID, Währung, Gesamtwert, Artikelanzahl und Produktkennungen. Dieser Kontext wird dem Bestellbestätigungs-Template zugewiesen und kann vom lokalen Event Recording/Demo Tooling des Moduls genutzt werden. Der vom Template ausgeführte Hotjar Events API-Aufruf bleibt jedoch das einfache benannte Event purchase.

Verwenden Sie in Hotjar das purchase-Event als Verhaltensmarker. Für Summen, Steuer, Marge, Attribution, Rückerstattungen oder verbindliches Conversion Reporting nutzen Sie weiterhin PrestaShop-Bestelldaten oder eine Analytics-Plattform, die für Transaktionsreporting ausgelegt ist.

Nein. Das Modul sendet PrestaShop-Events und Kundenkontext an Klaviyo, aber Kampagnenlogik, Segmente, E-Mail-Inhalte und SMS-Flows werden in Klaviyo verwaltet. Diese Trennung ist nützlich, weil Shopdaten aus PrestaShop kommen, während die Marketingstrategie in der Marketingplattform bleibt.

Quellseitig ist die PrestaShop-Seite auf Onsite-Datenlieferung begrenzt. Wenn ENABLED gesetzt ist und PUBLIC_API_KEY vorhanden ist, lädt der Header-Hook Klaviyos Onsite-Script mit der Company ID. Install-Defaults lassen das Modul deaktiviert, halten den Public Key leer und stellen Tracking-Schalter wie TRACK_VIEWED, TRACK_CART und TRACK_PURCHASE bereit.

Das Front-Template kann eingeloggte Kunden mit E-Mail und Vorname identifizieren, eine Produktseite als Viewed Product tracken und die Warenkorbseite als Added to Cart tracken. Es enthält keinen Klaviyo Flow Builder, Segment Editor, E-Mail-Template-Editor, SMS-Workflow-Screen oder Campaign-API-Layer. Die Quelle stellt einen Purchase-Schalter bereit, aber das geprüfte Browser-Tracking-Template gibt keinen Purchase-Tracking-Aufruf aus. Purchase Automation sollte daher weiterhin in Klaviyo verifiziert werden, statt allein aus der PrestaShop-Einstellung angenommen zu werden.

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

Teilweise. Das Modul hat Product-Card-Templates und Produktdaten-Laden, aber der implementierte Storefront-Pfad ist keine eigenständige product_list-Dropdown-Spalte. MenuBuilder kann product_list-Spaltenelemente aus einer Kategorie-ID und einem Limit laden, aber extractChildrenFromColumns() macht product_list-Elemente nicht als Menü-Children verfügbar. Händler sollten sich daher nicht darauf verlassen, dass dieser Spaltentyp Produktkarten rendert, bis Template-/Child-Support ergänzt ist.

Der aktuell implementierte Pfad sind Produktvorschauen unter Category-Tree-Children. Fügen Sie eine Dropdown-Spalte vom Typ category_tree hinzu, aktivieren Sie PRODUCTS_NB mit einem Wert größer null, und der Builder kann Produkte aus jedem Category Child anhängen. Das Storefront-Template rendert dann das erste angehängte Produkt als Featured Card und die übrigen angehängten Produkte als kleinere Karten im Panel.

SHOW_PRICES und SHOW_DISCOUNTS steuern, ob Preise und Rabatt-Badges erscheinen; beide sind standardmäßig aktiviert. PRODUCTS_NB steuert, wie viele Produktvorschauen je Category Child angehängt werden. Die Menu Cache TTL steuert, wie schnell strukturelle Änderungen erscheinen, und Produkt-, Kategorie- und CMS-Update-Hooks sind registriert, um gecachte Menüdaten zu leeren, wenn sich Shopinhalte ändern.

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.

Das Modul rendert das mobile Menü aus derselben Top-Level-Menükonfiguration, mit einem dedizierten Mobile Parser. Das reduziert doppelte Pflege und hilft, Desktop- und Mobile-Navigation abgestimmt zu halten. Sie sollten das mobile Layout trotzdem prüfen, weil lange Labels und tiefe Kategorie-Bäume die Nutzbarkeit beeinflussen können.

Desktop- und Mobile-Ausgaben erhalten beide dieselben $menu.children-Daten für den Off-Canvas-Baum. Auf Mobile rendert das Template diesen Baum, während HtmlMobileTreeParser und der Menu Builder mehrere Desktop-Spaltenlayouts in eine einfachere mobile Struktur umwandeln können, darunter Category Trees, CMS Category Trees, Blog Categories, Link Groups, CMS Links, Link Lists, HTML-abgeleitete Mobile Trees und Visual Tabs.

Das bedeutet, dass Sie Labels, Links, Category Trees, CMS Links, Visual Tabs und kompatible Custom-Mobile-Tree-Inhalte normalerweise einmal im Modul pflegen. Die praktische Ausnahme ist Inhalt, der nicht in menu.children extrahiert wird. Insbesondere werden Desktop-product_list-Spalten nicht in den aktuellen Mobile Tree extrahiert, und das Mobile-Template rendert nur $menu.children; Product-List-Inhalt bräuchte Storefront-/Mobile-Template-Support, bevor er im Off-Canvas-Menü erscheint.

Custom HTML ist ein weiterer Bereich zum Testen. Wenn eine Spalte ungewöhnliches Markup enthält und kein nutzbarer Mobile Tree vorhanden ist, kann der Mobile Parser auf eine einfache oder leere Struktur zurückfallen. Testen Sie daher lange Labels, verschachtelte Trees und Promotion-HTML auf echter Mobile-Breite, bevor Sie sich darauf für Navigation verlassen.

Nein. Das gerenderte Template verwendet skype:username?chat, also einen Chat-Link. Der Code rendert weder einen ?call-Link noch einen separaten Button fuer Sprach-/Videoanrufe.

Das Modul muss aktiviert sein und USERNAME muss konfiguriert werden. Der Validator der Pflichtkonfiguration erlaubt Buchstaben, Zahlen, Punkte, Bindestriche und Unterstriche mit einer Laenge von 3 bis 64 Zeichen.

Der Hook displayHeader registriert views/css/mprskypechatintegration.css nur, wenn der Chat-Guard besteht; inaktive oder nicht konfigurierte Widgets laden dieses Stylesheet daher nicht.

Ja. Der gemeinsame Guard prueft SHOW_MOBILE und gibt in mobilen Kontexten false zurueck, wenn diese Einstellung deaktiviert ist.

Nein. Das Modul verbindet PrestaShop mit Tidio und steuert das Ladeverhalten im Storefront. Chatbot-Flows, Inbox-Handling und Operator-Workflows werden in Tidio verwaltet, wo diese Werkzeuge hingehören.

PrestaShop-Einstellungen sind Verbindungs- und Rendering-Einstellungen: PUBLIC_KEY ist erforderlich und wird validiert, ENABLED ist standardmäßig 1, und das Widget kann verzögert, auf Mobile verborgen, nach Seitentyp begrenzt und optional mit E-Mail/Name eingeloggter Kunden über PASS_USER_DATA versorgt werden.

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

Im Front Office definiert das Template nur optionale document.tidioIdentify-Daten und hängt Tidios gehostetes Script von code.tidio.co an. In diesem Modul gibt es keinen PrestaShop-seitigen Bot Builder, keine Inbox-Ansicht, keinen Operator-Zuweisungsscreen, keine Nachrichtentabelle und keine Flow API. Sales-/Support-Automation muss daher weiterhin im Tidio-Dashboard konfiguriert werden.

Die Konfiguration speichert Aktivierungsstatus, Titel, HTML-Nachricht, Sichtbarkeit des Newsletter-Felds, Verzogerung in Sekunden, Cookie-Dauer in Tagen und ob die Anzeige auf allen Seiten oder nur auf der Startseite erfolgen soll.

Nachdem der Besucher es geschlossen hat, setzt das Script das Cookie mprwpop_seen fur die konfigurierte Anzahl von Tagen. Vor einer erneuten Anzeige pruft das Popup-Script dieses Cookie.

Nein. Das E-Mail-Feld ist in diesem Modul nur Anzeige. Wenn SHOW_NEWSLETTER aktiviert ist, rendert das Front-Template ein Newsletter-Formular mit E-Mail-Eingabe und Subscribe-Button, aber das Modul selbst enthält keinen Front Controller, AJAX Handler, Subscriber-Table-Insert und keine Newsletter-Modul-Integration, die übermittelte Adressen speichert.

Das Popup-Script behandelt nur Anzeigezeitpunkt, Schließen des Modals, Schließen per Escape-Taste und das mprwpop_seen-Cookie. Es fängt den Form Submit nicht ab und sendet die Adresse nirgendwohin.

Wenn Sie Leads erfassen möchten, verbinden Sie dieses Formular mit Ihrem eigenen Handler, einem Newsletter-Modul, Brevo- oder Mailchimp-Endpunkt oder einer Theme-Level-Form-Action, die Ihr Shop verarbeitet. Bis diese Integration existiert, zeigt das Aktivieren des Feldes nur ein E-Mail-Feld; es erstellt keine Newsletter-Abonnenten.

Die zugehörigen Moduleinstellungen entscheiden nur, ob das Feld angezeigt wird und wie oft das Popup erscheint. Install-Defaults setzen SHOW_NEWSLETTER auf 0, DELAY auf 3 Sekunden, COOKIE_DAYS auf 7 und SHOW_ON auf all; SHOW_ON=homepage beschränkt es auf den Index Controller.

Das Sichtbarkeits-Cookie wird gesetzt, wenn der Käufer das Popup schließt, das Overlay klickt oder Escape drückt. Das Absenden des Newsletter-Formulars legt in diesem Modul keinen Subscriber-Datensatz an, und das Template-Formular hat keine Action URL. Ein Händler sollte es daher als Front-End-Platzhalter behandeln, bis es mit einem echten Newsletter-Endpunkt verbunden ist.

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

Ja. Wenn die Anzeigeeinstellung nur Startseite lautet, gibt der hook nur dann Inhalte zuruck, wenn die aktuelle front controller-Seite die Indexseite ist.

Fügen Sie Ihre numerische Microsoft UET Tag ID hinzu und aktivieren Sie Browser-Tracking im Modul. Der PrestaShop Header Hook lädt das UET-Script, pusht das Page Load Event und sendet dann konfigurierte Browser-Events, wenn Tracking aktiv ist und Consent-Regeln es erlauben.

Bei einer Neuinstallation ist Tracking erst live, wenn diese Einstellungen vollständig sind: ENABLED ist standardmäßig 0, TAG_ID ist leer, und das Modul betrachtet sich nur als aktiv, wenn die Tag ID numerisch ist. Speichern Sie im Admin-Formular die Microsoft Ads UET Tag ID ohne Buchstaben oder Leerzeichen, lassen Sie RESPECT_CONSENT aktiviert, wenn Sie ein unterstütztes Cookie-Modul verwenden, und entscheiden Sie, welche Event-Schalter aktiv bleiben sollen.

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

Wenn der Header Hook läuft, kann er außerdem msclkid aus der Landing-URL für späteres Conversion Matching erfassen. Mitarbeiterausschluss ist über EXCLUDE_EMPLOYEES standardmäßig aktiviert, sodass eingeloggte Back-Office-Tests möglicherweise keine Events feuern, wenn Sie diese Einstellung nicht berücksichtigen.

Ja, es unterstützt die Microsoft Conversions API für serverseitige Purchase Events, aber nur, wenn die erforderlichen Einstellungen vollständig sind. Das Modul benötigt aktiviertes Tracking, eine numerische TAG_ID, eingeschaltetes CAPI_ENABLED, ein gespeichertes CAPI_ACCESS_TOKEN und aktiviertes Purchase Tracking.

• Admin-Validierung: Die UET Tag ID darf nur Ziffern enthalten, CAPI kann ohne numerische Tag ID nicht aktiviert werden, der Bearer Token ist erforderlich, wenn CAPI aktiviert ist, und das Queue Batch Limit muss 1-100 sein.
• Bestellflow: Bei actionValidateOrder prüft das Modul canTrack(), TRACK_PURCHASE und CAPI-Bereitschaft, bevor es etwas in die Warteschlange stellt.
• Queue Flow: Eine Purchase Conversion wird für Provider microsoft_uet in die Warteschlange gestellt, mit der Bestell-ID verknüpft und das Modul verarbeitet sofort einen kleinen Batch von 3 Events. Die Cron-Aufgabe verarbeitet später den normalen konfigurierten Batch.

Das Browser-UET-Tag kann weiterhin Page-, Cart-, Search- und Remarketing-Events behandeln; der CAPI-Pfad in diesem Modul ist speziell der serverseitige Purchase-Pfad.

Für die Einrichtung sind die wichtigen CAPI-Felder:

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

Der API Client sendet Events an Microsoft UET CAPI und verwendet dabei die numerische Tag ID im Endpunkt und ein Bearer Token. Die Nutzlast normalisiert Event Name/ID/Time/Source URL, Ad-Storage-Consent, User Data und benutzerdefinierte Purchase-Daten. User Matching kann IP-Adresse, User Agent, gespeicherte msclkid, gehashte Kundendetails und anonyme Warenkorb-/Gastkennungen umfassen, wenn verfügbar.

Dies ist kein serverseitiger Ersatz für jedes Browser-Event im Modul. Page View, Product View, Search, Add-to-cart, Wishlist und Custom Click/URL/Controller Events bleiben in der geprüften Quelle browserseitig; CAPI ist die serverseitige Purchase-Ergänzung.

Das Modul gruppiert Microsoft Ads UET Events rund um Storefront-Commerce, Konto, Suche und Custom-Trigger-Aktivität. Die Haupt-Events sind in den Moduleinstellungen einzeln konfigurierbar.

• Commerce/Storefront: pageView, productView, addToCart, addToWishlist, initiateCheckout und purchase. Produkt-, Warenkorb- und Purchase Events enthalten Commerce-Parameter wie Produkt-IDs, Bestellwerte, Währung und Mengen, wenn verfügbar.
• Suche: search feuert auf Suchergebnisseiten mit dem Query-Kontext.
• Konto: signUp wird nach Kundenregistrierung über den Registration-Hook-Flow des Moduls ausgelöst.
• Custom: Custom Events können mit Click-, URL-, Controller- oder DOM-Event-Triggern konfiguriert werden, wobei Event-Namen auf die erlaubten UET-Naming-Regeln des Moduls begrenzt sind.

Das Purchase Event wird auf der Bestellbestätigungsseite gesendet, während Add-to-cart- und Wishlist-Events von Front-Office-JavaScript-Listenern erfasst werden.

Die meisten dieser Schalter sind bei der Installation standardmäßig aktiviert, darunter TRACK_PAGE_VIEW, TRACK_PRODUCT_VIEW, TRACK_ADD_CART, TRACK_ADD_WISHLIST, TRACK_INITIATE_CHECKOUT, TRACK_SEARCH, TRACK_PURCHASE und TRACK_SIGNUP. TRACK_CUSTOM_EVENTS ist standardmäßig aus, bis Sie Custom-Event-Regeln definieren.

Custom Rules sind bewusst begrenzt: Der Config Normalizer akzeptiert bis zu 15 unterschiedliche Event-Namen, entfernt reservierte event_id-Parameter und unterstützt Click Selectors, URL-Contains-Matches, Controller-Namen oder Custom DOM Events. Front-Office-JavaScript dedupliziert Add-to-cart- und Wishlist-Button-Events für etwa eine Sekunde, damit dieselbe Aktion seltener doppelt gezählt wird.

Ja. Mit aktiviertem RESPECT_CONSENT prüft das Modul Marketing Consent, bevor es Microsoft UET Tracking als aktiv behandelt. Es prüft zuerst mprcookiesrevolution, indem es das mprcr_consent-Cookie liest und nach marketing:1 sucht. Wenn dieses Cookie fehlt, fällt es auf den DEFAULT_CONSENT-Wert dieses Moduls zurück. Wenn Cookies Revolution nicht aktiv ist, prüft es mprcookiebanner über mprcookie_consent=granted und fällt erneut auf die Default-Consent-Einstellung dieses Moduls zurück, wenn das Cookie fehlt.

Wenn kein unterstütztes MPR-Consent-Modul aktiv ist, gibt die Consent-Funktion allowed zurück, sodass Tracking nicht allein durch Consent blockiert wird. Für striktes GDPR-Gating lassen Sie RESPECT_CONSENT aktiviert und installieren/konfigurieren eines der unterstützten Consent-Module.

Der msclkid-Flow läuft im Header Hook. Das Modul liest msclkid aus der Landing-URL, akzeptiert nur A-Za-z0-9._:--Zeichen bis 500 Zeichen, spiegelt den Wert in $_COOKIE['mprbuet_msclkid'] und schreibt dann ein HTTP-only-Cookie namens mprbuet_msclkid für 7776000 Sekunden. Spätere serverseitige Conversion User Data kann diese gespeicherte Microsoft Click ID enthalten, wenn vorhanden.

• https://shop.example/?msclkid=abc123 speichert abc123 im Modul-Cookie.
• Ein späterer Kauf kann diesen Wert an Microsoft UET Conversion Data anhängen, wenn serverseitige Conversions konfiguriert sind.

Die serverseitige Consent-Prüfung und das Front-Office-JavaScript-Gate arbeiten zusammen, sind aber nicht identisch. Der PHP-canTrack()-Guard blockiert Event-Erstellung für Mitarbeiter, deaktivierte Module und fehlgeschlagenen Marketing Consent; das Header-Template prüft außerdem Browser-Cookies, bevor bat.js geladen wird, wenn ein unterstütztes Client-Consent-Modul vorhanden ist.

Wenn RESPECT_CONSENT auf 0 gesetzt ist, wird die Consent-Prüfung umgangen. Wenn kein unterstütztes MPR-Consent-Modul installiert ist, erlaubt die PHP-Funktion Tracking allein aus Consent-Sicht. Strikte Shops sollten sich daher nicht auf das UET-Modul selbst als einzige Consent-Schicht verlassen.

Das msclkid-Cookie wird vor dem späteren Kauf geschrieben. Das ist wichtig, weil ein Käufer von Microsoft Ads kommen, browsen und in einer späteren Anfrage bestellen kann. Der Wert wird nur akzeptiert, wenn er zur Zeichen-Whitelist des Moduls passt; ungültige oder überlange Werte werden ignoriert, statt an Microsoft gesendet zu werden.

Nein. Der Browser-Tag wird vom PrestaShop Header-Hook nur eingefügt, wenn das Tracking aktiv ist, also eine numerische TAG_ID gespeichert und ENABLED gleich 1 ist. Dabei wird die Microsoft-Bibliothek mit script.async = true von https://bat.bing.com/bat.js geladen und blockiert das Rendern der Seite nicht.

Beim Laden sendet das Modul ein einzelnes pageLoad an window.uetq und danach nur die von Ihnen aktivierten Events wie Produktansicht, In-den-Warenkorb oder Kauf über uetq.push('event', ...). Ist ein unterstuetztes Consent-Modul aktiv, wird der Pixel erst nach bestaetigter Marketing-Einwilligung geladen, sodass ablehnende Besucher keine Anfrage an Microsoft ausloesen.

Der serverseitige Versand ueber die Conversions API laeuft in einem geplanten Cron-Task, nicht in der Anfrage des Kunden, und angemeldete Mitarbeiter sind standardmaessig ueber EXCLUDE_EMPLOYEES ausgeschlossen.

Wenn die Conversions API aktiviert und ein Microsoft Bearer-Token gespeichert ist, werden Kauf-Events bei der Bestellvalidierung in eine Warteschlange gestellt und serverseitig von einem geplanten Cron-Task send_bing_uet_conversions gesendet, der alle 300 Sekunden laeuft. Jeder Lauf verarbeitet die Warteschlange bis zum konfigurierten Batch-Limit (CAPI_BATCH_LIMIT, Standard 20, erlaubt 1–100 und pro Lauf auf 100 Zeilen begrenzt), sodass fehlgeschlagene oder ausstehende Events im naechsten Zyklus wiederholt statt verworfen werden.

Die serverseitigen Nutzerdaten koennen die gespeicherte Microsoft Click-ID (msclkid), gehashte E-Mail und Telefonnummer, Client-IP und User-Agent enthalten. Verarbeitete und veraltete Eintraege werden automatisch bereinigt, die juengste Historie bleibt erhalten und alte Zeilen werden mit der Zeit entfernt.

Fehlt der Bearer-Token oder ist er leer, zeigt der Admin-Bereich einen Hinweis und es werden keine serverseitigen Events gesendet, bis Sie ihn hinzufuegen. Das Browser-UET kann waehrend der Einrichtung der Conversions API unabhaengig fuer Seitenaufrufe und Remarketing aktiv bleiben.

Nein, nicht für den einfachen Messenger-Kontaktbutton. Die erforderliche Einstellung ist die numerische Facebook Page ID; ohne konfigurierte App ID rendert das Storefront-Template einen direkten https://m.me/{page_id}-Link, sodass Käufer Messenger über den Floating Button öffnen.

• m.me-Link-Modus: Benötigt aktiviertes Modul und gültige Page ID. Er ist schnell eingerichtet und funktioniert als einfacher externer Messenger-Kontaktlink.
• SDK-Modus: Das Modul behandelt ein ausgefülltes App-ID-Feld als Schalter, um Facebooks Customer Chat Plugin Markup zu rendern und das Facebook Customer Chat SDK zu laden. Der Begrüßungstext wird in diesem SDK-Modus-Markup verwendet.

Händler, die nur einen zuverlässigen Messenger-Button möchten, können die App ID also leer lassen. Fügen Sie die App ID nur hinzu, wenn Sie bewusst den SDK-basierten eingebetteten Chat-Pfad nutzen möchten und die Facebook-seitige Einrichtung bereit ist.

Die Page-ID-Anforderung ist strikt: Der Required-Config-Validator des Moduls akzeptiert nur Ziffern, 5 bis 32 Zeichen, und das Widget rendert nicht, wenn das Modul aktiviert ist, dieses Feld aber leer bleibt. Defaults aktivieren das Widget, zeigen es auf allen Seiten inklusive Mobile, verwenden den Bottom-right-Icon-Stil und verzögern die Anzeige um 0 Sekunden.

Appearance-Einstellungen wie POSITION, STYLE, CTA_TEXT, COLOR, SIZE, MARGIN, Tooltip und Animation werden vom Floating-Link-Button-Pfad verwendet. Seitenfilterung und mobile Sichtbarkeit kommen aus dem gemeinsamen Chat Guard, sodass Sie den Messenger-Einstiegspunkt nur auf Produkt-, Kategorie- oder Checkout-Seiten anzeigen können, wenn das zu Ihrem Support-Flow passt.

Die Fetch-Methode prüft zuerst RSS_URL. Wenn sie leer ist, erstellt sie eine RSS-URL aus BOARD_URL. Pin-URLs werden nur verwendet, wenn der RSS-Pfad keine Posts liefert.

Nein. mprpinterestintegration ist ein Pinterest-Content-/Feed-Modul, nicht das Pinterest-Ads-Tracking-Modul. Es zeigt Pinterest Pins, Boards oder RSS-gesteuerte Inhalte im Shop an und enthält Cache-Handling für den angezeigten Feed. Die Quelle enthält außerdem optionale Pinterest-API-Publishing-Einstellungen für Produkt-/Content-Publishing.

• Pinterest Feed Integration: Verwenden Sie es, um Pinterest-Inhalte im Storefront anzuzeigen, Benutzernamen, Pin-URLs, Board-URLs oder RSS-Quellen zu konfigurieren und optional Shop-Inhalte zu Pinterest zu veröffentlichen.
• Pinterest Tag: Verwenden Sie das separate Pinterest Tag-Modul für Werbemessung, Browser-Tag-Events und optionale Conversions API-Tracking-Events wie Page Visits, Product Views, Add-to-cart, Checkout, Search und Signup.

Wenn das Ziel besseres visuelles Merchandising oder das Einbetten von Pinterest-Inhalten ist, verwenden Sie diese Feed-Integration. Wenn das Ziel Pinterest Ads Attribution oder Conversion Optimization ist, verwenden Sie stattdessen das Pinterest Tag-Modul.

Für den Feed-Pfad kann die erforderliche Quelle so einfach sein wie eine oder mehrere gespeicherte Pin-URLs oder eine Board-URL/RSS-Quelle, je nachdem, wie Sie Inhalte kuratieren möchten. Die gemeinsamen Feed-Einstellungen steuern Display Hook, Post Count, Spalten, Grid-/Slider-Layout, Follow Button, Mobile-Sichtbarkeit und Cache-Dauer; der Cache ist standardmäßig 3600 Sekunden und kann aus dem Modul-Admin aktualisiert werden.

Der optionale Publishing-Pfad ist ebenfalls getrennt vom Ads Tracking. Pinterest Publishing erfordert Pinterest-API-Zugangsdaten wie Access Token und Board ID, und der Publisher sendet bildbasierte Pin-Daten an Pinterest. Das installiert weiterhin nicht das Pinterest Advertising Tag und meldet keine Ad Conversions; dafür braucht der Shop das separate mprpinteresttag-Modul.

Die Config Map enthält ACCESS_TOKEN, BOARD_ID, AUTOPUBLISH und AUTOPUBLISH_CAPTION. Publishing wird über den gemeinsamen PinterestPublisher abgewickelt.

Jedes Feed-Item verlinkt auf die Pin-URL, zeigt Thumbnail-Bild, optionales Video-Badge, Overlay-Text, optionalen Autorennamen und optionale Caption abhängig von Moduleinstellungen und Quelldaten.

Das Modul benoetigt den Smartsupp Website Key. Das Setup-Panel weist den Haendler an, ihn aus den Smartsupp-Einstellungen zu kopieren, und der Validator der Pflichtkonfiguration behandelt einen leeren Key als ungueltig.

Wenn PASS_USER_DATA aktiviert ist und der Kunde angemeldet ist, gibt das gemeinsame Chat-Trait customer_email und customer_name zurueck. Das Template weist diese Werte _smartsupp.email und _smartsupp.name zu.

Nein. Das Template laedt Smartsupps externes Widget-Script. Die sichtbare Chat-UI wird von Smartsupp bereitgestellt, nachdem der Loader ausgefuehrt wurde.

Ja. Wenn die Einstellung DELAY groesser als null ist, legt das Template die Initialisierung und Script-Injektion von Smartsupp in setTimeout.

Nein, Sie benötigen kein TikTok-Developer-Konto, nur um Videos anzuzeigen. Der Display Feed basiert auf eingefügten TikTok-Video-URLs und TikToks öffentlichem oEmbed-Endpunkt. Geben Sie in den Moduleinstellungen den TikTok-Benutzernamen für den Follow-Link ein, fügen Sie im Feld Video URLs eine TikTok-Video-URL pro Zeile ein und speichern Sie.

Wenn der Feed gebaut wird, teilt das Modul die gespeicherte URL-Liste zeilenweise, überspringt Einträge, die kein tiktok.com enthalten, ruft https://www.tiktok.com/oembed?url=... auf und speichert den zurückgegebenen Titel, Caption, Autor, Thumbnail und Embed HTML für die Anzeige. Dieser Display-Pfad verwendet kein API Token, keinen App Review und keine Developer-Zugangsdaten.

Zugangsdaten sind nur für den optionalen Publishing-Workflow relevant. Die Quelle hat Publishing-Einstellungen wie ACCESS_TOKEN, CLIENT_KEY, AUTOPUBLISH und AUTOPUBLISH_CAPTION und verwendet für diesen Pfad eine TikTok-Publisher-Instanz. Wenn Ihr Ziel nur ist, ausgewählte TikTok-Videos im Shop einzubetten, können Sie diese Publishing-Zugangsdaten leer lassen.

Das Display-Modul ist standardmäßig aktiviert, mit aktivierten Caption-, View-Icon- und Like-Icon-Schaltern, während die gemeinsamen Feed-Defaults displayHome, 6 Posts, 3 Desktop-Spalten, Grid-Layout, Lazy Loading und eine Cache-Dauer von 3600 Sekunden verwenden. Der Feed rendert nur im konfigurierten Social-Feed-Hook; wenn der konfigurierte Hook nicht zum aktuellen Hook passt, wird nichts ausgegeben.

Es gibt zwei praktische Randfälle: URLs ohne tiktok.com werden übersprungen, und jede fehlgeschlagene oEmbed-Anfrage wird übersprungen, statt eine kaputte Karte zu rendern. Die Storefront-Karte verlinkt zur ursprünglichen TikTok-URL und zeigt das zurückgegebene Thumbnail, den Autor und die Caption an. Gelöschte/private Videos oder blockierte oEmbed-Antworten reduzieren daher einfach den Feed.

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

Ja. Das gemeinsame Chat-Trait pruft die mobile Einstellung vor dem Rendern und gibt keinen Button zuruck, wenn die mobile Anzeige fur einen mobilen Besucher deaktiviert ist.

Nein, das Modul verwaltet keine Agenten, Gesprächsverläufe oder Support-Workflows. WhatsApp selbst behandelt die Unterhaltung, während das Modul den Storefront-Button und die Click-to-chat-URL handhabt. Das hält die Integration leichtgewichtig und klar.

Das einzige erforderliche Verbindungsfeld ist PHONE. Es darf nur Ziffern enthalten, 7 bis 20 Zeichen lang sein, inklusive Landesvorwahl und ohne Pluszeichen oder Leerzeichen. Das Front-Template baut https://wa.me/{phone}, und wenn eine Nachricht konfiguriert ist, hängt es ?text=... an, damit WhatsApp sie vorbefüllt.

• Was PrestaShop steuert: Aktivieren/deaktivieren, Telefonnummer, optionale vorbefüllte Nachricht, Position, Icon-/Bar-Stil, CTA-Text, Farbe, Größe, Abstand, Tooltip, Animation, mobile Sichtbarkeit, Anzeigeverzögerung und Seitenfilter.
• Was WhatsApp steuert: Den eigentlichen Chat-Thread, Antworten, Mitarbeiterzuweisung, Nachrichtenverlauf, Benachrichtigungen und alle Inbox- oder CRM-Funktionen.

Die optionale Nachricht unterstützt {product} auf Produktseiten und {url} für die aktuelle Seite, was für Produktfragen nützlich ist. Es bleibt dennoch nur eine vorbefüllte WhatsApp-Nachricht, kein Ticket und kein gespeicherter PrestaShop-Supportdatensatz.

Das Modul ersetzt {url} durch die aktuelle Seiten-URL. Auf Produktseiten kann es ausserdem {product} durch den aktuellen Produktnamen ersetzen.

Das Modul kann aus dem footer oder before-body hook rendern, aber ein internes statisches Flag verhindert doppelte Ausgabe. Der Seitenumfang kann alle Seiten, Produktseiten, Kategorieseiten oder checkout-bezogene Seiten umfassen.

Fügen Sie den Discord Invite Code in der Modulkonfiguration hinzu und aktivieren Sie das Widget. In PrestaShop rendert das Modul einen Front-Office-Button, der mit dem gespeicherten Invite Code auf discord.gg verlinkt ist, mit konfigurierbarer Position, Stil, CTA-Text, Farbe, Größe, Tooltip, Animation und Abstand.

Verwenden Sie nur den Invite Code, nicht die vollständige URL. Der Required-Config-Validator erwartet Buchstaben, Zahlen, Bindestriche und Unterstriche, 2 bis 64 Zeichen. Ein fehlender Invite Code verhindert das Rendering; ein ungültig gespeicherter Code wird durch den Konfigurationshinweis markiert und kann einen fehlerhaften Discord-Link erzeugen.

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

Bei der Installation setzen die Defaults das Widget bereits auf aktiviert, bottom-right, Icon-Stil, Discord-Blau #5865F2, 60px Größe, 20px Abstand, Tooltip aktiviert, Pulse-Animation, Mobile aktiviert, alle Seiten und keine Verzögerung. Das Admin-Setup-Panel empfiehlt, einen permanenten Invite und einen dedizierten Support-Channel zu erstellen, weil das Modul Käufer in den Server-Join-Flow sendet, statt Discord-Unterhaltungen in PrestaShop zu behandeln.

Ja, das Widget kann nach Seitentyp begrenzt werden. In PrestaShop unterstützt der gemeinsame Chat Guard alle Seiten, Produktseiten, Kategorieseiten oder checkoutbezogene Controller und prüft außerdem die separate Mobile-Sichtbarkeitseinstellung, bevor er rendert.

Der Seitenfilter wird in der gemeinsamen Einstellung PAGES gespeichert. Der Guard gibt true für all zurück, prüft php_self=product für Produktseiten, php_self=category für Kategorieseiten und behandelt cart, order, order-opc, orderopc und checkout als checkoutbezogene Controller.

Derselbe Guard verlangt außerdem ENABLED und einen nicht leeren INVITE_CODE, und er versteckt das Widget auf Mobile, wenn SHOW_MOBILE aus ist. Das bedeutet, Seitentargeting ist kein separates Snippet, das ins Theme eingefügt wird; es ist Teil der Render-Entscheidung des Moduls, bevor CSS und Button ausgegeben werden.

PAGES=product SHOW_MOBILE=1 DELAY=0

Ja, das Modul besitzt eine Verzögerungseinstellung für den Storefront-Button. In PrestaShop schreibt das Hook-Template einen data-delay-Wert und ein kleines Skript blendet das Widget aus und zeigt es nach der konfigurierten Sekundenanzahl.

Nein, das Modul sendet keinen vorbefüllten Text an Discord. Die erforderliche Verbindungseinstellung ist ein Invite Code, kein User-/Message-API-Token, und das Storefront-Template rendert einen Link zu https://discord.gg/{invite_code}.

Das Admin-Feld Pre-filled Message wird zur Referenz gespeichert, und das Modul kann {url} intern ersetzen, bevor Template-Daten zugewiesen werden, aber das aktuelle Storefront-Template gibt diese Nachricht nicht aus und hängt sie nicht an die Discord-Invite-URL an.

Das unterscheidet sich von Chat-Plattformen, die URL-Parameter für eine vorbefüllte Unterhaltung unterstützen. Discord-Invite-Links führen den Käufer zu einem Server-Invite-/Join-Flow. Die praktische Einrichtung besteht daher darin, einen permanenten Invite-Link zu erstellen und Kunden nach dem Beitritt zu einem Support-Channel zu leiten.

Die Quelle bestätigt diese Trennung. Das Admin-Verbindungsformular labelt das Feld als Pre-filled Message, aber seine Beschreibung sagt, dass es für Discord Invites nicht verwendet und nur zur Referenz gespeichert wird. Im Hook ersetzt das Modul {url} innerhalb der gespeicherten Nachricht, bevor es Smarty-Daten zuweist, aber das Template verwendet nur invite_code, Position/Stil/CTA/Appearance, Tooltip, Animation und Verzögerung.

Für Händler ist die zuverlässige Konfiguration der Invite selbst: Erstellen Sie einen stabilen Invite Code, verhindern Sie dessen Ablauf und nutzen Sie Discord-Server-/Channel-Regeln, um Kunden nach dem Beitritt zu führen. Verlassen Sie sich nicht darauf, dass dieses Modul eine direkte Discord-DM öffnet, in einen Channel postet oder eine Checkout-/Produktnachricht an Discord übergibt.

Nein, es ist ein Sprach-Navigationsmodul. Es hilft Käufern, zwischen Sprachen zu wechseln, die Sie bereits betreiben, und führt sie zu lokalisierten URLs, wo PrestaShop die Daten hat. Übersetzungsqualität, Länder-Targeting und Besucherstandort-Logik bleiben außerhalb dieses Moduls.

Das Modul liest aktive PrestaShop-Sprachen für den aktuellen Shop mit Language::getLanguages(true, shop_id). Wenn der Shop nur eine aktive Sprache hat, gibt es keinen Selector zurück. Für jede Sprache mappt es die Sprach-ISO auf ein Flaggen-SVG, wenn vorhanden, baut eine Sprach-URL aus den Alternative-Language-URLs des Front Controllers, wenn verfügbar, und fällt auf PrestaShops getLanguageLink() zurück.

• Navigation: Die Desktop-Ausgabe versteckt den nativen Desktop-Sprachselector und rendert ein Flaggen-Dropdown in displayNav2; die Mobile-Ausgabe kann ein einfaches Select in displayMobileLanguageSelector rendern.
• Labels: SHOW_LABEL steuert, ob der aktuelle ISO-Code neben der Flagge angezeigt wird, und SHOW_NAMES steuert, ob vollständige Sprachnamen im Dropdown angezeigt werden. Defaults sind Label aus und Namen an.
• Grenzen: Es übersetzt keine Produktnamen/-beschreibungen, wählt keine Sprachen per Geolocation, leitet Besucher nicht nach Land weiter und erstellt keine fehlenden lokalisierten URLs.

Es gibt zusätzliche URL-Bereinigung für Core-Seitenaliases und einen Integrations-Hook für übersetzte MPR Filter Revolution-Filterpfade, aber auch das hängt von vorhandenen übersetzten Routen/Daten ab. Es ist ein Switcher, keine Übersetzungsmaschine.

Es registriert displayHeader, displayOrderConfirmation, actionCustomerAccountAdd und actionValidateOrder.

Nein. Das Template der Bestellbestätigung und der Server-Conversion-Builder verwenden für abgeschlossene Bestellungen das Pinterest-Event checkout, inklusive Bestellwert, Menge, Währung, Bestell-ID und Event-ID.

CAPI_ENABLED muss aktiv sein, die Pinterest ad account ID darf nur Ziffern enthalten und der access token darf nicht leer sein. Das Batch Limit muss zwischen 1 und 100 liegen.

Ja, wenn eine Custom Rule capi aktiviert hat. Die Front Conversion Bridge mappt bekannte Browser-Eventnamen und akzeptiert auch konfigurierte Custom-CAPI-Eventnamen.

Das Modul liest den konfigurierten Selector-String und führt document.querySelectorAll für diese Selectors aus. Standardmäßig zielt es auf Produkt-Miniaturen, Kategorieblöcke und Featured-Product-Elemente.

Das Front-Script beendet sich frühzeitig, wenn IntersectionObserver nicht verfügbar ist. Das bedeutet, dass in nicht unterstützten Browsern keine versteckten Animationsklassen hinzugefügt werden.

Ja, Sie können den Effekt in den Moduleinstellungen ein- oder ausschalten. Das ist nützlich, wenn Sie testen möchten, ob Animationen Ihrem Shop helfen, oder wenn eine Kampagnenseite ein ruhigeres Layout braucht. Da der Effekt nicht hart in Templates codiert ist, erfordert das Entfernen keinen Theme-Rollback.

Der Ein-/Ausschalter ist die Einstellung ENABLED. Der Header Hook prüft diesen Wert zuerst; wenn er aus ist, kehrt er zurück, bevor er Front-CSS, JavaScript oder Inline-Konfiguration registriert. Die Theme-Templates bleiben daher unangetastet.

Standard-Installationswerte sind ENABLED=1, ANIMATION_TYPE=fade-up, DELAY=0, DURATION=600 und Selectors für Product Miniatures, Category Blocks und Featured-Product-Elemente. Die Admin-Optionen erlauben außerdem, den Animationstyp auf fade-in, slide-left, slide-right oder zoom-in zu ändern, Delay/Dauer in Millisekunden anzupassen und die Selector-Liste zu bearbeiten.

Im Storefront verwendet das Script IntersectionObserver. Wenn es keine passenden Selectors gibt oder der Browser die API nicht unterstützt, beendet es sich, ohne Hidden-/Visible-Klassen anzuwenden. Das Deaktivieren der Moduleinstellung ist daher der saubere Rollback-Pfad; kein Template-Rollback ist nötig, weil das Modul Asset-Registrierung und Klasseninjektion besitzt.

ENABLED=0

Nein. Sobald der Observer ein Element als sichtbar markiert, ruft er unobserve für dieses Element auf, sodass das Reveal ein einmaliger Übergang ist.

Die Installationsstandardwerte setzen ENABLED auf 0 und USERNAME auf eine leere Zeichenkette. Der Render-Hook beendet sich frueh, wenn das Modul nicht aktiviert ist oder kein Benutzername vorhanden ist.

Nein, es öffnet Ihr Snapchat-Profil über den konfigurierten Benutzernamen. Profilinhalte und Unterhaltungen bleiben in Snapchat selbst. So bleibt das Modul darauf fokussiert, Käufern einen sauberen Weg zum Folgen oder Kontaktieren zu geben, ohne einen schweren Social Feed zur Seite hinzuzufügen.

Die Storefront-Ausgabe ist ein Floating Button, der aus dem Hook displayBeforeBodyClosingTag gerendert wird. Der Hook stoppt vor dem Rendering, wenn der Snapchat-Button nicht aktiviert ist, wenn der USERNAME-Wert leer ist, wenn mobile Anzeige für einen mobilen Besucher deaktiviert ist oder wenn der aktuelle Controller in EXCLUDE_PAGES aufgeführt ist. Wenn gerendert wird, wird das Ziel als https://www.snapchat.com/add/ plus URL-encodetem Benutzernamen gebaut.

Das Template bestätigt, dass dies ein normaler Link ist, kein Snapchat Embed. Es gibt ein <a>-Tag mit der konfigurierten URL, optionalem target=_blank, Tooltip-Text, Button-Styling, Animation und optionaler Grabber-Nachricht aus. Es gibt kein iframe, keinen Snapchat-API-Aufruf, keinen Feed Renderer und keinen Code, der Gespräche oder Profilinhalte von Snapchat liest.

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

Für Händler bedeutet das: Das Modul ist leichtgewichtig. Es gibt Besuchern einen sichtbaren Weg zu Ihrer Snapchat-Präsenz, während alle Snapchat-Inhalte, Follows, Nachrichten und Account-Privacy unter Snapchats eigener App und Website bleiben.

Die Konfigurationsdefinition listet small, medium und large, beschriftet als 48px, 60px und 72px. Die gewaehlte Groesse wird als mprchat-size-... an die Widget-Klasse uebergeben.

Nein. Dieses Modul rendert einen schwebenden Link zu einem Snapchat-Profil. Snapchat Pixel und Anzeigen-Event-Tracking werden von einem anderen Modul in diesem Batch behandelt.

Wenn Gast-Wishlists aktiviert sind, speichert das Front-Script Produkt-IDs im localStorage des Browsers und gibt fur Hinzufuge- und Entfernen-Aktionen Antworten im Gastmodus zuruck. Eingeloggte Speicherung nutzt die Datenbanktabellen des Moduls.

Die JavaScript-Konfiguration markiert den Kunden als eingeloggt, und die Sync-Aktion kann localStorage-Artikel an den Server senden, damit sie zur Standard-Wishlist des Kunden hinzugefugt werden.

Datenbank-Wishlists haben ein Token mit 32 Zeichen. Die Front-Ansicht kann Produkte per Token laden, und das Template behandelt den eingeloggten Besitzer anders als einen Besucher, der eine geteilte Wishlist ansieht.

Wenn ein eingeloggter Kunde ein Produkt speichert, speichert das Modul den Preis zum Zeitpunkt des Hinzufugens. Die Produktliste vergleicht diesen gespeicherten Preis mit dem aktuellen Produktpreis und markiert einen Ruckgang, wenn der aktuelle Preis niedriger ist.

Nein. Dieses Modul ist hauptsächlich ein Brevo-Automation-Tracker und eine Kundenregistrierungs-Synchronisierung, keine vollständige Warenkorb-/Bestell-/Produkt-Event-Integration.

• Behandelt: displayBeforeBodyClosingTag lädt Brevos Automation-Script, ruft die Page-Tracking-Funktion auf und identifiziert den Besucher per E-Mail, wenn ein Kunde eingeloggt ist. actionCustomerAccountAdd kann den neuen Kunden als Brevo-Kontakt erstellen oder aktualisieren, wenn Auto-subscribe aktiviert ist.
• Behandelt nicht: Warenkorb-Updates, Product-View-Payloads, Order-Confirmation-Purchase-Events, Abandoned-Cart-Events oder Order-Status-Events. Das Modul registriert keine Warenkorb-, Bestell- oder Produkthooks für diese Aktionen.

Wenn Sie Cart Abandonment, Purchase Revenue oder Product-Behavior-Automation in Brevo benötigen, bräuchte dieses Modul zusätzliche Event-Hooks oder eine separate Integration, die diese spezifischen Brevo-Events sendet.

Die Hook-Liste ist die wichtige Grenze: Das Modul registriert nur displayBeforeBodyClosingTag und actionCustomerAccountAdd. Das Storefront-Template erstellt window.sib, lädt https://sibautomation.com/sa.js?key=..., stellt die Standard-Brevo-Funktionen in die Warteschlange und ruft window.sendinblue.page() auf. Wenn ein Kunde eingeloggt ist, ruft es außerdem window.sendinblue.identify() mit der E-Mail-Adresse auf. Keine Produkt-IDs, Warenkorbpositionen, Bestellreferenzen, Summen oder Bestellstatus werden dieser Browser-Payload hinzugefügt.

Bei Kontoerstellung postet das Modul an Brevos Contacts Endpoint mit Kunden-E-Mail, FIRSTNAME, LASTNAME, updateEnabled=true und der konfigurierten LIST_ID, wenn eine gespeichert ist. Das ist nützlich für Listenwachstum und einfache Automation Entry, aber getrennt vom Ecommerce Event Tracking.

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

Aktivieren Sie das Modul, fügen Sie einen Brevo API Key hinzu und lassen Sie die automatische Registrierungssynchronisierung aktiviert. Wenn PrestaShop ein Kundenkonto erstellt, sendet der Hook actionCustomerAccountAdd die E-Mail plus die Attribute FIRSTNAME und LASTNAME an Brevo und enthält die konfigurierte List ID, wenn eine gespeichert ist.

Die relevanten Einstellungen sind ENABLED, API_KEY, LIST_ID und AUTO_SUBSCRIBE. Bei der Installation startet das Modul mit ENABLED=0, leerem API Key, leerer List ID, leerem Tracker Client Key und AUTO_SUBSCRIBE=1. Die übliche Einrichtung ist also: Brevo einschalten, den API Key aus Brevo einfügen, optional die numerische List ID für neue Kontakte eingeben und Auto-subscribe New Customers aktiviert lassen.

Die Synchronisierung läuft nur bei Erstellung neuer Kundenkonten, weil das Modul auf actionCustomerAccountAdd lauscht. Es prüft zuerst, ob das Modul aktiv ist, ob der API Key existiert, ob Auto-subscribe aktiviert ist und ob PrestaShop ein geladenes newCustomer-Objekt bereitgestellt hat. Wenn eine dieser Prüfungen fehlschlägt, kehrt es zurück, ohne etwas an Brevo zu senden.

Wenn es sendet, postet das Modul JSON an https://api.brevo.com/v3/contacts mit einem 10-Sekunden-cURL-Timeout und aktivierter SSL Peer Verification. Es setzt updateEnabled auf true, sodass ein bestehender Brevo-Kontakt aktualisiert werden kann, statt einen Duplicate-Contact-Fehler zu verursachen. Diese Quellversion importiert bestehende Kunden nicht bulkweise und synchronisiert spätere Profiländerungen nicht, sofern PrestaShop nicht über diesen Hook ein neues Konto erstellt.

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

Ja. Der Storefront-Hook lädt den Brevo Automation Tracker nur, wenn das Modul aktiviert ist, der Brevo API Key konfiguriert ist und der Client Key konfiguriert ist. Das Client-Key-Feld in den Moduleinstellungen ist als Client Key (Tracker) beschriftet, und der Quellhinweis führt Händler zu Brevo > Automation > Settings > Tracking Code.

Um zu bestätigen, dass der Tracker geladen ist, öffnen Sie den Storefront-Quelltext oder die Browser-Developer-Tools und suchen Sie nach https://sibautomation.com/sa.js?key=... mit Script-ID sendinblue-js. Das Template initialisiert window.sib.client_key, stellt sendinblue.track, sendinblue.identify, sendinblue.trackLink und sendinblue.page in die Warteschlange, identifiziert eingeloggte Kunden per E-Mail und ruft dann window.sendinblue.page() auf.

Wenn Sie dieses Script nicht sehen, prüfen Sie zuerst den Modul-Aktivierungsschalter, API Key und Client Key. Der Hook gibt einen leeren String zurück, wenn eine dieser Voraussetzungen fehlt.

Die API-Key-Anforderung ist wichtig, obwohl der Browser Tracker den Client Key verwendet. In diesem Modul wird isActive() vom Tracker Hook gemeinsam genutzt und prüft sowohl ENABLED als auch API_KEY; danach prüft der Hook separat CLIENT_KEY. Ein Shop mit nur gespeichertem Client Key gibt daher weiterhin nichts aus, bis auch der API Key konfiguriert ist.

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

Die Tracker-Ausgabe ist auf das Brevo Automation Script, Page Tracking und E-Mail-Identifikation eingeloggter Kunden begrenzt. In dieser Quellversion fügt sie keine Warenkorbinhalte, Bestellsummen, Produktmetadaten oder Purchase Events hinzu.

Ja, automatische Registrierungssynchronisierung kann in der Modulkonfiguration deaktiviert werden. Der PrestaShop-Hook actionCustomerAccountAdd prüft den AUTO_SUBSCRIBE-Schalter, bevor er einen neuen Kunden an Brevo sendet. Das Modul kann daher installiert bleiben, während Registrierungssynchronisierung ausgeschaltet ist.

Die Einstellung ist in den Moduloptionen als Auto-subscribe New Customers beschriftet. Ihr Default ist bei einer frischen Installation aktiviert, aber der Hook prüft sie jedes Mal, wenn PrestaShop ein Kundenkonto erstellt. Wenn AUTO_SUBSCRIBE aus ist, beendet sich der Hook, bevor er das neue Kundenobjekt validiert oder die Brevo Contacts API aufruft.

Das Deaktivieren dieses Schalters stoppt nur die Registrierung-zu-Kontakt-Synchronisierung. Es deinstalliert das Modul nicht, entfernt keine gespeicherten API-Zugangsdaten und deaktiviert den Storefront Automation Tracker nicht automatisch. Wenn ENABLED, API_KEY und CLIENT_KEY weiterhin konfiguriert sind, kann der Tracker Hook weiterhin das Brevo-Script laden und die Page-Tracking-Funktion aufrufen.

Es meldet außerdem keine Kontakte ab und löscht keine Kontakte, die bereits in Brevo erstellt wurden. Es verhindert lediglich, dass dieses Modul künftig neue Account-Erstellungen als Kontakte sendet, solange der Schalter aus bleibt.

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

Sie können Crisp Chat zu PrestaShop hinzufügen, indem Sie Ihre Crisp Website ID eingeben und das Modul aktivieren. Der Setup-Hinweis des Moduls erwartet die Website ID im UUID-Format, aber das Modul verlangt nur, dass das Feld nicht leer ist; es erzwingt beim Speichern oder Anzeigen nicht das exakte UUID-Muster. Praktisch sollten Sie trotzdem die echte UUID-formatierte Website ID aus Crisp einfügen, weil ein beliebiger nicht leerer Wert gespeichert und gerendert werden kann, aber möglicherweise kein funktionierendes Widget lädt.

Bei der Installation erstellt das Crisp-Modul Chat-Defaults mit ENABLED=1, leerer WEBSITE_ID, SHOW_MOBILE=1, PAGES=all, DELAY=0 und PASS_USER_DATA=1. Da die Website ID leer startet, kann das Modul erfolgreich installiert und aktiviert sein, aber das Widget bleibt inaktiv, bis diese ID gespeichert wird.

Der Required-Configuration-Hinweis erwartet UUID-Format, zum Beispiel xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx. Die Setup-Hilfe verweist in Crisp auf Settings > Website Settings > Setup instructions. Sobald ein nicht leerer Wert gespeichert ist, wendet die Storefront weiterhin dieselben Anzeigeregeln an, sodass das Widget Aktivierungsschalter, eine nicht leere Website ID, Mobile-Einstellung und Seitentargeting respektiert.

Wenn diese Regeln erfüllt sind, setzt das Template window.CRISP_WEBSITE_ID, pusht optional E-Mail-/Namensdaten eingeloggter Kunden und hängt https://client.crisp.chat/l.js asynchron an den Page Head.

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

Ja, Crisp Chat kann nach PrestaShop-Seitentyp begrenzt werden. Der gemeinsame Chat Guard unterstützt alle Seiten, Produktseiten, Kategorieseiten oder Checkout-Controller, einschließlich cart, order, order-opc, orderopc und checkout, bevor er das Crisp-Script ausgibt.

Die Einstellung ist das gemeinsame Select-Feld Show on Pages. Die unterstützten gespeicherten Werte sind all, product, category und checkout. Der Moduldefault ist all, sodass eine frische Installation mit gültiger Website ID auf jeder Storefront-Seite angezeigt werden kann, sofern der Händler diese Einstellung nicht ändert.

Der Seitenabgleich verwendet PrestaShops aktuellen Controller php_self. Product-only-Modus matcht exakt product, Category-only-Modus matcht exakt category, und Checkout-Modus matcht cart, order, order-opc, orderopc oder checkout. Der Mobile-Schalter wird separat geprüft, sodass eine Seite die Seitenregel erfüllen und trotzdem auf Mobile verborgen sein kann, wenn SHOW_MOBILE aus ist.

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

Wenn ein unerwarteter Wert in PAGES gespeichert ist, erlaubt der Default-Zweig des gemeinsamen Guards die Seite, statt sie zu blockieren. Für vorhersagbares Targeting verwenden Sie einen der vier Werte, die das Formular anbietet.

Ja, aber nur wenn Kundendatenübergabe aktiviert ist und der Käufer eingeloggt ist. Die Einstellung ist der Schalter Pass Customer Data in der Crisp-Modulkonfiguration; setzen Sie ihn auf No, um zu verhindern, dass das Modul Identitätsdaten eingeloggter Kunden an Crisp sendet.

• Wenn PASS_USER_DATA aus ist, gibt der gemeinsame Chat Helper leere Kundenfelder zurück.
• Wenn er an ist und der Kunde eingeloggt ist, gibt der Helper die E-Mail des Kunden und Vorname plus Nachname zurück.
• Das Crisp-Template sendet diese als user:email und user:nickname, bevor es https://client.crisp.chat/l.js lädt.

Anonyme Besucher erhalten weiterhin das Crisp-Widget, wenn Website ID und Anzeigeregeln es erlauben, aber es wird keine PrestaShop-Kunden-E-Mail oder kein Name übergeben, weil kein eingeloggtes Kundenobjekt existiert.

Bei einer frischen Installation ist PASS_USER_DATA standardmäßig 1. Händler, die diese Übergabe nicht möchten, sollten den Schalter daher bewusst deaktivieren. Der Helper stellt dem Template nur zwei Werte bereit: customer_email und customer_name. Er enthält keine Adressdaten, Telefonnummern, Warenkorbinhalte, Bestellhistorie oder PrestaShop-Kunden-ID.

Der Crisp Hook muss außerdem zuerst die normalen Anzeigeregeln des Moduls erfüllen. Wenn das Modul deaktiviert ist, die Website ID fehlt, mobile Anzeige blockiert ist oder die Seitenregel nicht passt, wird das Template nicht gerendert und es werden keine Kundendaten zu Crisp gepusht.

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

Ja, das Crisp-Script kann um eine konfigurierte Anzahl von Sekunden verzögert werden. Das aktuelle PrestaShop-Hook-Template wickelt den Crisp Loader in setTimeout, wenn die Verzögerung größer als null ist; es wartet nicht auf Scrollen, Klick, Touch oder andere Nutzerinteraktion.

Die gespeicherte Einstellung ist DELAY, im gemeinsamen Formular als Fallback Delay (seconds) angezeigt. Im aktuellen Crisp-Modul übergibt der Hook diesen Wert als Integer an das Template. Wenn der Wert größer als null ist, umschließt das Template den gesamten Crisp-Setup- und Script-Append-Block mit setTimeout(..., DELAY * 1000).

Ein Wert von 0 bedeutet, dass das Template keinen Timeout Wrapper hinzufügt, sodass das Crisp Setup sofort läuft, wenn die Hook-Ausgabe geparst wird. Obwohl die gemeinsame Feldbeschreibung First User Interaction und einen Fallback erwähnt, implementiert dieses Crisp-Template nur das oben beschriebene Timer-Verhalten.

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

Die Verzögerung umgeht die normale Guard-Kette nicht. Das Modul muss weiterhin aktiviert sein, die Website ID muss vorhanden sein, mobile Anzeige muss für mobile Besucher erlaubt sein, und die Page-Targeting-Regel muss passen, bevor irgendein verzögertes Script ausgegeben wird.

Ja. Konfigurieren Sie ausgeschlossene Produkt-IDs in der Produktlisten-Einstellung des Moduls, zum Beispiel als kommagetrennte Liste. Der Override entfernt ausgeschlossene Produkte aus dem Paket, das an PrestaShops Cart-Rule-Berechnung übergeben wird, sodass monetäre Rabatte nur auf berechtigte Produkte berechnet werden.

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

Dieselbe Ausschlussliste kann mit Kategorie- und Herstellerausschlüssen kombiniert werden, weil das Modul alle drei Quellen zu einer ausgeschlossenen Produktmenge zusammenführt. Prozentuale Rabatte gelten nur für berechtigte Produkte. Feste Betragsreduktionen werden über das gefilterte Paket anteilig berechnet, während Free Shipping und Gift-Verhalten PrestaShops normalem Cart-Rule-Handling überlassen bleiben.

Die Produktlisten-Einstellung wird als PRODUCTS gespeichert. Der Resolver liest den kommagetrennten Wert, castet jeden Eintrag mit intval, entfernt leere Nullwerte und merged diese IDs dann mit IDs aus Kategorien und Herstellern. Die finale Liste wird für die aktuelle PHP-Anfrage gecacht, was wiederholte Kategorie- und Herstellerabfragen während derselben Warenkorbberechnung vermeidet.

Der CartRule Override ändert nur Regeln mit monetärer Reduktion: reduction_percent größer als null oder reduction_amount größer als null. Wenn das Modul nicht aktiviert ist, wenn die konfigurierte Ausschlussliste leer aufgelöst wird oder wenn das aktuelle Cart-Rule-Paket keine ausgeschlossenen Produkte enthält, delegiert es unverändert an die Parent-Berechnung von PrestaShop.

Da der Filter id_product prüft, gilt der Ausschluss für das Produkt als Ganzes. Wenn ein Produkt Kombinationen hat, unterscheidet die Quelle in diesem Ausschlussschritt nicht eine Attributkombination von einer anderen.

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

Ja. Ausschlüsse können als direkte Produkt-IDs, Kategorie-IDs und Hersteller-IDs eingegeben werden. Die Admin-Konfigurationsfelder sind kommagetrennte Listen, und der Resolver wandelt sie vor der Rabattberechnung in eine finale Produkt-ID-Liste um.

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

Mit dieser Konfiguration sind die Produkte 12 und 15 direkt ausgeschlossen. Das Modul fragt außerdem category_product für jedes Produkt ab, das den Kategorien 3 oder 7 zugewiesen ist, und product für jedes Produkt, dessen id_manufacturer 1 oder 4 ist. Es merged diese IDs, entfernt Duplikate mit array_unique und cached das Ergebnis für die aktuelle Anfrage.

Der CartRule Override fragt das Modul dann nach dieser aufgelösten Produktliste und filtert ausgeschlossene Produkte aus dem Paket, bevor der Parent-Cart-Rule-Rabatt berechnet wird. In Händlerbegriffen: passende Produkte bleiben zum vollen Preis, während der Rest des Warenkorbs weiterhin den Gutscheinrabatt erhalten kann.

Die Kategorie-Regel basiert auf den exakten Kategorie-IDs, die in CATEGORIES gespeichert sind. Die Source Query liest Zeilen aus category_product, deren id_category in dieser Liste ist; sie läuft nicht in PHP durch den Kategoriebaum. Wenn ein Shop auch alle Unterkategorien ausschließen muss, sollten diese Child-Kategorie-IDs enthalten sein, sofern die Produkte nicht auch direkt der gelisteten Parent-Kategorie zugewiesen sind.

Die Hersteller-Regel basiert auf product.id_manufacturer. Wie bei direkten Produkten erfolgt der finale Ausschluss über id_product, sodass alle Kombinationen eines passenden Produkts als ausgeschlossen behandelt werden. Ungültige Texteingaben werden durch Integer-Casting effektiv reduziert; leere und Nullwerte tragen keine nützlichen Produkt-IDs bei.

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

Nein, der Override zielt auf monetäre Cart-Rule-Reduktionen, nicht auf den Free-Shipping-Vorteil selbst. Wenn das Modul deaktiviert ist, keine ausgeschlossenen Produkte konfiguriert sind oder die Cart Rule keine prozentuale oder feste Betragsreduktion hat, delegiert der Override an PrestaShops normale CartRule-Berechnung.

Beispiel: Ein Gutschein gibt 10% Rabatt plus Free Shipping, und der Warenkorb enthält nur Produkte, die von diesem Modul ausgeschlossen sind. Der Produktrabatt wird 0, weil jedes Produkt von der monetären Reduktion ausgeschlossen ist. Wenn die Regel aber free_shipping hat und PrestaShop die Shipping Action berechnet, delegiert der Override an die Parent-Shipping-Berechnung, sodass der Free-Shipping-Teil weiterhin gelten kann.

Bei gemischten Warenkörben filtert das Modul ausgeschlossene Produkte heraus, bevor die Parent-Berechnung läuft. Prozentuale Rabatte gelten nur für berechtigte Produkte, und feste Betragsrabatte werden von PrestaShop gegen das gefilterte Paket berechnet.

Der Fast Path ist wichtig für reine Free-Shipping-Gutscheine. Wenn eine Cart Rule kein reduction_percent und kein reduction_amount hat, gibt der Override PrestaShops Parent-Ergebnis zurück, ohne das Paket zu filtern. Das bedeutet, ein reiner Free-Shipping-Gutschein folgt den normalen PrestaShop-Gutscheinbedingungen und wird nicht reduziert, nur weil Produkte in der Ausschlussliste stehen.

Wenn alle Produkte ausgeschlossen sind und eine Regel einen monetären Rabatt mit Free Shipping kombiniert, gibt der Override 0 für den monetären Teil zurück, sofern der aktuelle Filter nicht einer von PrestaShops Shipping-/All-Action-Filtern ist. Für diese Shipping-/All-Filter ruft er die Parent-Berechnung mit FILTER_ACTION_SHIPPING auf, was der source-level Grund ist, warum der Shipping-Vorteil verfügbar bleiben kann.

Ein praktischer Stolperpunkt: Der optionale Warenkorbhinweis ist von der Rabattmathematik getrennt. Der Notice Renderer prüft, ob Modul und Hinweis aktiviert sind, ob der Warenkorb Cart Rules hat und ob ausgeschlossene Produkte vorhanden sind. Er prüft nicht, ob die Cart Rule monetär oder free-shipping-only ist. Die Nachricht kann also weiterhin informativ erscheinen, während PrestaShop Versand normal behandelt.

Ja, das Modul kann einen Warenkorbhinweis anzeigen, wenn ausgeschlossene Produkte vorhanden sind. In PrestaShop erscheint der Hinweis nur, wenn Modul und Notice-Einstellung aktiviert sind, der Warenkorb Cart Rules hat und mindestens ein Warenkorbprodukt zur Ausschlussliste passt.

Die Notice-Funktion ist bei der Installation standardmäßig mit SHOW_NOTICE=1 aktiviert. Der standardmäßige mehrsprachige Hinweistext ist The following products are excluded from the applied discount:, und Händler können NOTICE_TEXT in den Moduleinstellungen bearbeiten. Das Modul registriert sowohl displayShoppingCart als auch displayShoppingCartFooter; der Footer-Hook bleibt als Kompatibilitätsalias für Shops erhalten, die noch die ältere Hook-Platzierung verwenden.

Der Renderer hat außerdem einen Duplicate Guard. Sobald ein Hinweis während der Anfrage gerendert wurde, verhindert $cartNoticeRendered, dass dieselbe Nachricht zweimal erscheint, falls beide Warenkorb-Hooks im Theme laufen.

Das Modul baut die Produktnamenliste aus den aktuellen Warenkorbprodukten, deren id_product in der aufgelösten Ausschlussliste erscheint. Wenn product_name nicht verfügbar ist, fällt es auf name und dann auf ein generisches Produktnummern-Label zurück. Das Template escaped sowohl den Hinweistext als auch die Produktnamen vor der Ausgabe.

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

Wenn kein Gutschein/keine Cart Rule angewendet ist, wird der Hinweis bewusst verborgen, selbst wenn ausgeschlossene Produkte im Warenkorb sind. So bleibt die Nachricht an den Moment gekoppelt, in dem ein Kunde einen Rabatt erwartet und sich fragen könnte, warum einige Artikel zum vollen Preis geblieben sind.

Das Pflichtfeld ist die HubSpot Portal ID. Der Hinweis auf die erforderliche Konfiguration bleibt aktiv, solange dieses Feld leer ist.

Das geprüfte HubSpot-Template identifiziert angemeldete Kunden per E-Mail, wenn pass-user-data aktiviert ist. Es sendet keine anonymen Besucherdaten aus PHP.

Das gemeinsame Chat-Trait unterstützt alle Seiten, Produktseiten, Kategorieseiten oder checkout-bezogene Seiten wie cart, order, order-opc, orderopc und checkout.

Nein. Der Code nutzt einen konfigurierten Timeout in Millisekunden, bevor das Widget gerendert wird. Es ist eine zeitliche Verzögerung, kein durch Interaktion ausgelöster Loader.

In den hier gelesenen Dateien ist keine automatische Regel-Engine vorhanden. Die Badge-Zuweisung wird pro Produkt in mprproductbadges gespeichert, und das Admin-Formular erfordert ein ausgewahltes Produkt.

Die Tabelle speichert id_product, badge_name, badge_color, badge_bg_color, position und active sowie die automatisch hochzahlende Badge-ID.

Die Storefront-Abfrage filtert nach Produkt und aktivem Status und sortiert die Ergebnisse anschliessend nach position ASC. Niedrigere Positionsnummern werden zuerst angezeigt.

Ja. MprProductBadgesConfig stellt einen Schalter ENABLED bereit. Wenn er ausgeschaltet ist, gibt renderBadges() einen leeren String zuruck, bevor Produktdaten gelesen werden.

Das Modul muss aktiviert sein und eine Pixel ID muss existieren. Der Validator der Pflichtkonfiguration akzeptiert Pixel IDs mit Buchstaben, Zahlen, Unterstrichen oder Bindestrichen und einer Laenge von 8 bis 128 Zeichen.

displayOrderConfirmation rendert das Browser-Purchase-Event. actionValidateOrder reiht ein serverseitiges Purchase-Event ein, wenn Conversions API konfiguriert und Purchase-Tracking aktiviert ist.

Header- und Purchase-Events erhalten eine event_id von PrestaShopConversionBuilder::buildEventId, und derselbe Wert wird nach client_dedup_id kopiert. Das Queuing von Purchase-CAPI verwendet dieselbe bestellbasierte Event ID.

Regeln koennen durch CSS-Klicks, URL-Uebereinstimmungen, Controller-/Modul-Uebereinstimmungen oder benannte DOM-Events ausgeloest werden. Der Normalizer validiert Trigger-Anforderungen, begrenzt die Selektorlaenge und bereinigt Custom-Parameter, bevor das JSON gespeichert wird.

Der Feed benotigt einen bearer token und einen Benutzernamen, wenn das Modul nicht von Social Revolution verwaltet wird. Das Modul kann X API aufrufen, um die user ID aus diesem Benutzernamen aufzulosen.

Die Konfiguration steuert Post-Text, Datum, Likes, Reposts, Antworten, Medien und Autorendetails. Der Code erstellt ausserdem Permalinks und verarbeitet von der API zuruckgegebene Medien-Erweiterungen.

Nein. Die Anforderungen unterscheiden sich. YouTube kann manuelle Video-URLs ohne API key verwenden, während Facebook, Instagram und X Plattform-Zugangsdaten brauchen, bevor sie Posts aus ihren APIs abrufen können. Jedes Modul zeigt seinen eigenen Hinweis zur erforderlichen Konfiguration.

Die Feed-Module nutzen gecachte Daten und rufen von ihrer konfigurierten Plattform/Quelle ab, wenn die Cache-Regeln es erlauben. Manche bieten außerdem Cache-Clear- oder Sync-Steuerungen, daher hängt das praktische Refresh-Verhalten von Zugangsdaten, Cache-Dauer und den Einstellungen des jeweiligen Plattformmoduls ab.

Nein. Die Layout-Optionen sind ähnlich, aber nicht identisch. Facebook und X enthalten Grid-, Slider- und Listenoptionen; Instagram und YouTube enthalten Grid-/Slider-Optionen; Pinterest und TikTok haben eigene Feed- und Post-Item-Templates.

Die einzelnen Integrationsmodule enthalten Feed-Anzeige und im Code einige Auto-Publish-Hooks oder Bereiche, aber das Pack sollte primär als Feed-Display-Integration beschrieben werden, sofern nicht die Publishing-Einrichtung eines konkreten Plattformmoduls konfiguriert und getestet ist.

Das Modul ordnet PrestaShop-Storefront-Seiten und Hooks Criteo-OneTag-Events zu, mit separaten Einstellungen für jedes Standard-Event.

Alle Browser-Events hängen weiterhin davon ab, dass das Modul aktiv ist, eine Criteo Partner ID konfiguriert ist, der Besucher die Tracking-/Consent-Prüfungen des Moduls besteht und der jeweilige Event-Schalter aktiviert ist.