PrestaShop-Monitoring von der Kasse bis zum Cron
XICTRAQ prüft Warenkorb, Kasse, Webservice und Cron-Läufe Ihres PrestaShop-Shops und meldet, wenn ein eingebundenes Fremdskript seinen Inhalt ändert. Was der cookielose Tracker in PrestaShop von selbst erfasst und was nicht, steht weiter unten.
Diese PrestaShop-Pfade zuerst prüfen
- Uptime-MonitoringWarenkorbseite, mit und ohne sprechende URLs
/index.php?controller=cart&action=show - Uptime-MonitoringAnmeldeseite für Kunden
/index.php?controller=authentication - Uptime-MonitoringProduktsuche mit Suchbegriff
/index.php?controller=search&s=test - Browser-MonitoringVom Produkt über den Warenkorb zur Kasse
/index.php?controller=order - API-MonitoringWebservice mit Schlüssel im Authorization-Header
/api/
Warum eine erreichbare Startseite nicht reicht
PrestaShop erweitern Sie über Module. Laut Entwicklerdokumentation hängen sie sich über Hooks an bestimmte Ereignisse im Shop und fügen meist Inhalte in eine Seite ein. Zahlungs- und Versandmodule wirken vor allem in Warenkorb und Kasse – geht dort nach einem Modul-Update etwas schief, kann die Startseite weiter normal antworten.
Dazu kommen Aufgaben, die per Crontab laufen: etwa die Aktualisierung der Wechselkurse über cron_currency_rates.php im Admin-Ordner oder Exporte und Abgleiche, die Sie oder ein Modul anstoßen. Bleiben sie aus, bleibt der Shop erreichbar – und eine reine Erreichbarkeitsprüfung sieht davon nichts.
XICTRAQ verteilt die Prüfung deshalb auf mehrere Module: Uptime-Monitoring mit Unterseiten für Warenkorb, Anmeldung und Suche, Browser-Checks für den Weg zur Kasse, API-Checks für den Webservice, Heartbeats für Cron-Aufgaben und die Skript-Integrität für extern eingebundene Skripte.
Den Wartungsmodus von PrestaShop wertet XICTRAQ in der Regel als Ausfall: Die Wartungsseite antwortet mit HTTP 503, und weder der englische Standardtext noch seine deutsche Übersetzung aus dem Sprachpaket enthält einen der Wartungsbegriffe, an denen der Prüfknoten eine geplante Wartung erkennt. Steht in Ihrem Wartungstext „Wartungsarbeiten“ oder „Wartungsmodus“, gilt die Seite dagegen als Wartung, und Ausfall- sowie Inhaltsalarme pausieren – auch wenn der Wartungsmodus versehentlich an bleibt. Legen Sie für Updates deshalb ein Wartungsfenster an; darin bleiben Ausfall- und Unterseitenalarme stumm.
Wo es in PrestaShop-Shops hakt – und welches Modul es bemerkt
Wartungsmodus bleibt nach einem Update an
Im Wartungsmodus zeigt PrestaShop Besuchern eine Wartungsseite mit HTTP 503, freigegebenen IP-Adressen und – in der Grundeinstellung – im Backoffice angemeldeten Mitarbeitern dagegen den normalen Shop. Wer von einer freigegebenen Adresse aus oder mit offener Backoffice-Sitzung nachsieht, bemerkt deshalb nichts. Das Uptime-Monitoring prüft von den Prüfknoten aus und wertet die Standard-Wartungsseite als Ausfall, solange deren Adressen nicht freigegeben sind; außerhalb eines Wartungsfensters folgt ein Alarm.
Kasse bricht nach einem Modul-Update ab
Das Update eines Zahlungs- oder Versandmoduls oder des Themes verändert den Checkout, und ein Schritt lädt nicht mehr. Ein dafür eingerichteter Browser-Check legt einen Artikel in den Warenkorb, öffnet die Kasse und prüft, ob die erwarteten Elemente sichtbar werden, ohne die Bestellung abzuschicken. Schlägt ein Schritt fehl, speichert er einen Screenshot der Stelle.
Warenkorb oder Anmeldung fallen aus, die Startseite nicht
Die Startseite kann weiter antworten, während Warenkorb, Kundenanmeldung oder Suche einen Fehler liefern, etwa nach dem Update eines Moduls, das sich dort einklinkt. Überwachte Unterseiten prüft XICTRAQ bei jedem Uptime-Lauf mit; fällt eine aus, kommt ein eigener Alarm mit dem betroffenen Pfad.
Wechselkurse oder Exporte bleiben stehen
Nach einem Serverumzug oder einem gelöschten Crontab-Eintrag läuft eine Cron-Aufgabe nicht mehr. Ein Heartbeat-Ping nach dem Aufruf fällt dann aus, und XICTRAQ meldet einen verpassten Heartbeat; ein Aufruf der /fail-Adresse löst einen Fehleralarm aus. Der Ping belegt den Aufruf, nicht seine Wirkung: Passt der Schlüssel in der Adresse von cron_currency_rates.php nicht mehr, etwa nach einer Umbenennung des Shops, bleibt der Aufruf ohne Fehlermeldung wirkungslos.
Fremdskript ändert seinen Inhalt
Module können Skripte fremder Anbieter einbinden, etwa für Zahlung oder Chat. Die Skript-Integrität speichert den SHA-256-Hash extern eingebundener Skripte aus dem Quelltext der Startseite und der Seiten Ihrer verifizierten Website, die Sie im Live-Scan prüfen (bis zu zwölf je Seite), und meldet, wenn sich einer ändert oder nicht mehr erreichbar ist; neu hinzugekommene Skripte nimmt sie beim nächsten Live-Scan ohne Meldung auf. Skripte, die erst in der Kasse laden, erreicht sie nicht, denn ohne Artikel im Warenkorb leitet PrestaShop von der Kasse zum Warenkorb um; Dateien, die Ihr Shop unter seiner eigenen Adresse aus /modules/ oder /themes/ ausliefert, deckt sie ebenfalls nicht ab. Das ist ein Hinweis, kein abschließender Sicherheitsbeweis.
Webservice liefert Fehler
Warenwirtschaft oder Marktplatzanbindung können über den Webservice auf den Shop zugreifen. Kommt der Authorization-Header nach einem Serverwechsel nicht mehr bei PrestaShop an, scheitert die Anmeldung; die Entwicklerdokumentation nennt dafür die Direktive CGIPassAuth. Ein API-Check ruft /api/ mit Ihrem Schlüssel auf und prüft Statuscode, Antwortzeit und einen erwarteten Text in der XML-Antwort; weicht die Antwort zweimal in Folge ab, folgt ein Alarm.
Woran XICTRAQ PrestaShop erkennt
PrestaShop wird an zwei Stellen erkannt: im Live-Scan und im Tracker. Beide Wege greifen nicht bei jedem Shop; daraus folgt, welche Angaben in Technikübersicht, CRA-Cockpit und Auswertung erscheinen.
- Als Shopsystem trägt der Live-Scan PrestaShop ein, wenn der Quelltext ein Generator-Meta-Tag mit „PrestaShop“ oder Adressen mit /prestashop/js oder /modules/prestashop enthält; die Standard-Themes Classic und Hummingbird geben kein Generator-Tag aus. Lädt der Shop Modul-Skripte einzeln, etwa unter /modules/ps_shoppingcart/, erscheint PrestaShop zumindest unter „Weitere erkannte Technologien“.
- Die laufende Technikerkennung der Prüfknoten führt PrestaShop nicht. Findet sie nichts, bleibt ein PrestaShop-Befund aus dem Live-Scan aber stehen.
- Der Tracker erkennt PrestaShop-Seiten am JavaScript-Objekt prestashop, das PrestaShop in die Shopseiten schreibt, oder an den Elementen #product-details und [data-product]. Produktaufrufe liest er aus den strukturierten Produktdaten (JSON-LD), Warenkorb-Klick, Kassenbeginn und Bestellabschluss aus dem Markup.
- Im CRA-Komponenten-Cockpit erscheint ein als Shopsystem erkannter PrestaShop-Shop ohne Versionsnummer und damit als nicht bewertbar. Einen Abgleich mit Sicherheitshinweisen gibt es für PrestaShop nicht.
- Die Erkennung des Bestellbetrags ist auf das Theme Classic ausgerichtet. Hummingbird, seit PrestaShop 9.1 das Standard-Theme, und eigene Themes weichen davon ab; Betrag und Bestellnummer übergeben Sie dort über die JavaScript-API.
Was der Tracker in PrestaShop erfasst
Der cookielose Tracker liest Produktaufrufe aus den strukturierten Produktdaten, die Classic und Hummingbird ausgeben, und erkennt Warenkorb-Klick, Kassenbeginn und Bestellabschluss am Markup. Bestellnummer und Betrag kommen dabei nicht verlässlich an; übergeben Sie beides selbst, wie im Hinweis unten beschrieben.
Erfasst der Tracker von selbst
- Produktaufrufe mit Referenz (sonst Produkt-ID), Name, Preis und Währung aus den JSON-LD-Daten der Produktseite, ergänzt um Kategorie und Marke (Hersteller, sonst Shopname)
- Klicks auf „In den Warenkorb“ (.add-to-cart und [data-button-action="add-to-cart"]) als Warenkorb-Ereignis
- Kassenbeginn auf der Bestellseite, wenn deren Pfad „order“ oder „bestellung“ enthält
- Bestellabschluss auf der Bestellbestätigung, in Classic mit dem Betrag aus der Gesamtzeile
- Ereignisse, die ein Modul im dataLayer ablegt: view_item, add_to_cart, begin_checkout und purchase mit ecommerce.value
Nicht automatisch erfasst
- Die Bestellnummer: In Classic übernimmt der Tracker ein Wort der Beschriftung statt der Referenz, etwa „Order“ oder „Bestellnummer“. Automatisch erkannte Käufe in derselben Shopsprache tragen damit dieselbe Kennung und zählen nur, wenn in den 30 Tagen davor kein Kauf mit dieser Kennung eingegangen ist; in Hummingbird fehlt die Nummer ganz
- Ein verlässlicher Betrag: In Hummingbird meldet der Tracker den Kauf mit Betrag 0, als Währung setzt er fest EUR ein, und in Classic kann eine Beschriftung wie „(tax incl.)“ in der Gesamtzeile den Betrag verfälschen
- Angemeldete Kunden: Das prestashop-Objekt der Seite enthält keine Kundenkennung, die der Tracker lesen könnte
- Mengenänderungen, entfernte Artikel und die Warenkorbsumme auf der Warenkorbseite: Das Classic-Markup passt nicht zu den Selektoren des Trackers
- Ob ein Artikel wirklich im Warenkorb gelandet ist: Gezählt wird der Klick auf den Button, und die Produktangaben dazu liest der Tracker aus dem umliegenden Markup, wo sie unvollständig sein können
- Kassenbeginn, wenn der Pfad weder „order“ noch „bestellung“ enthält – etwa ohne sprechende URLs unter /index.php?controller=order oder bei einer anders benannten Kassenadresse in einer weiteren Shopsprache
- Erstattungen und Gutschriften: Sie entstehen im PrestaShop-Backoffice, nicht im Browser des Kunden
Betrag und Bestellnummer übergeben Sie über die JavaScript-API, sobald der Tracker geladen ist, etwa im Template checkout/order-confirmation.tpl: xictraq.revenue({$order.totals.total_including_tax.amount}, "{$currency.iso_code}", "{$order.details.reference}"). Angemeldete Kunden machen Sie mit {if $customer.is_logged}<meta name="xictraq:user-id" content="{$customer.id}">{/if} im Kopf des Themes oder mit xictraq.identify(kundenId, { name }) erkennbar. Die automatische Erkennung meldet den Kauf zusätzlich: In Hummingbird zählen dann beide Meldungen, der Umsatz stimmt, die Zahl der Bestellungen ist aber zu hoch; in Classic zählt die automatische Meldung mit, wenn in den 30 Tagen davor keine andere mit demselben Beschriftungswort einging. Prüfen Sie nach dem Einbau in der Auswertung, ob Betrag und Anzahl der Bestellungen stimmen.
Die passenden Module für PrestaShop
Häufige Fragen
Wertet XICTRAQ den PrestaShop-Wartungsmodus als Ausfall?
Mit dem englischen Standardtext und seiner deutschen Übersetzung aus dem Sprachpaket ja: Die Wartungsseite antwortet mit HTTP 503 und enthält keinen der Wartungsbegriffe, an denen XICTRAQ eine geplante Wartung erkennt. Steht in Ihrem Wartungstext „Wartungsarbeiten“ oder „Wartungsmodus“, gilt die Seite als Wartung, und Ausfall- sowie Inhaltsalarme pausieren, solange sie so antwortet. Für Updates empfiehlt sich ein einmaliges oder wöchentlich wiederkehrendes Wartungsfenster; darin bleiben Ausfall- und Unterseitenalarme stumm.
Wie überwache ich Cron-Aufgaben in PrestaShop?
Legen Sie für jede Aufgabe einen Heartbeat mit dem Zeitplan Ihres Crontab-Eintrags an und rufen Sie dessen Ping-Adresse nach dem eigentlichen Aufruf auf. Bleibt der Ping aus, meldet XICTRAQ einen verpassten Heartbeat; über die Adressen /start und /fail melden Sie zusätzlich Beginn und Fehlschlag eines Laufs. Der Ping belegt, dass der Aufruf stattfand, nicht, dass die Aufgabe ihr Ziel erreicht hat.
Erkennt XICTRAQ meinen Shop automatisch als PrestaShop?
Nicht immer. Der Live-Scan sucht nach einem Generator-Meta-Tag oder bestimmten Adressen im Quelltext, und die Standard-Themes Classic und Hummingbird geben kein Generator-Tag aus. Der Tracker erkennt PrestaShop-Seiten dagegen am JavaScript-Objekt prestashop. Unterseiten, Browser-, API- und Heartbeat-Checks richten Sie unabhängig von der Erkennung ein.
Prüft XICTRAQ meine PrestaShop-Version auf Sicherheitslücken?
Nein. Der Live-Scan liest keine PrestaShop-Versionsnummer aus, und für PrestaShop gibt es keinen Abgleich mit Sicherheitshinweisen. Der Security-Scan prüft allgemeine Punkte wie Sicherheits-Header, TLS und offen liegende Dateien wie .git/config, .env oder SQL-Dumps, aber keine PrestaShop-eigenen Pfade. Updates von PrestaShop und Modulen einzuspielen bleibt Aufgabe Ihres Teams oder Ihrer Agentur.
Warum stimmen Umsatz oder Bestellzahl bei PrestaShop nicht?
Die automatische Erkennung liest die Bestellbestätigung aus dem Markup: In Classic übernimmt sie statt der Referenz ein Wort der Beschriftung, in Hummingbird meldet sie den Kauf ohne Nummer und mit Betrag 0. Verlässliche Werte liefern ein Aufruf von xictraq.revenue() mit Betrag, Währung und Referenz auf der Bestellbestätigung oder ein purchase-Ereignis mit ecommerce.value im dataLayer. Die automatische Meldung bleibt daneben bestehen, und nur Meldungen mit gleicher Bestellnummer zählt die Auswertung einmal. Prüfen Sie deshalb nach dem Einbau, ob Betrag und Anzahl der Bestellungen stimmen.
Wie erkennt XICTRAQ angemeldete Kunden in PrestaShop?
Von selbst nicht, weil das prestashop-Objekt der Seite keine Kundenkennung enthält. Geben Sie im Theme für angemeldete Kunden ein Meta-Tag xictraq:user-id mit der Kundennummer aus oder rufen Sie xictraq.identify() auf. Übergeben Sie dabei die Kundennummer aus PrestaShop, keine E-Mail-Adresse.