PrestaShop-Cron läuft nicht: die unsichtbare Panne

Die Störung, die niemand bemerkt

Ein PrestaShop-Cron, der nicht läuft, erzeugt keine sichtbare Fehlermeldung. Der Shop arbeitet, Bestellungen kommen herein. Nur ist der an die Preisportale gesendete Produktfeed drei Wochen alt, die Bestände gleichen sich nicht mehr mit dem ERP ab, die Erinnerungen an abgebrochene Warenkörbe gehen nicht raus, und der Buchhaltungsexport des Monats ist leer.

Der Händler erfährt davon durch Dritte: durch einen Kunden, der ein ausverkauftes Produkt bestellt, oder durch die Buchhaltung, die eine Datei anmahnt. Bis dahin haben sich mehrere Wochen Schaden angesammelt.

Das Missverständnis am Anfang

Das Modul ps_cronjobs ist ein interner Planer, kein Auslöser. Es führt die Liste der Aufgaben und weiß, welche wann laufen soll, aber es wacht nicht von selbst auf: Eine echte geplante Aufgabe bei Ihrem Hoster muss seine URL in festen Abständen aufrufen.

Viele Installationen hören genau hier auf: Die Aufgaben sind im Backoffice angelegt, alles sieht richtig aus – und ausgeführt wird nie etwas. Das Modul bietet mitunter an, sich über den Besucherverkehr auslösen zu lassen; das ist unvorhersehbar und für eine Aufgabe zu einer festen Uhrzeit unbrauchbar.

Die fünf echten Ursachen

1. Beim Hoster ist gar keine geplante Aufgabe eingerichtet. Sehen Sie im Verwaltungspanel Ihres Hostings unter „Geplante Aufgaben“ oder „Cron“ nach. Ist die Liste leer, haben Sie die Ursache.

2. Die falsche PHP-Version. Das ist die Falle beim Shared Hosting. Geplante Aufgaben laufen über PHP auf der Kommandozeile, dessen Version sich oft von der der Website unterscheidet. Das Skript landet dann auf einem alten PHP und scheitert sofort, ohne dass jemand die Ausgabe liest. Geben Sie den absoluten Pfad zum richtigen Interpreter an:

/usr/local/php8.2/bin/php /home/compte/site/modules/ps_cronjobs/cron.php

3. Ein ungültiges Token. Die URL der Aufgaben enthält ein Sicherheitstoken. Es ändert sich, wenn das Modul neu installiert oder die Konfiguration geändert wird. Sämtliche beim Hoster hinterlegten Aufgaben laufen dann stillschweigend in einen Berechtigungsfehler.

4. Ein blockierter Aufruf. Ein Shop hinter HTTP-Authentifizierung, einer Regel der Web Application Firewall oder einer IP-Beschränkung antwortet mit einem Fehler, noch bevor PrestaShop überhaupt erreicht wird.

5. Eine überschrittene Ausführungszeit. Eine schwere Aufgabe wie das Neuaufbauen des Suchindex oder ein umfangreicher Katalogexport reißt die zulässige Grenze und bricht mittendrin ab. Der schlimmste Fall: Sie hinterlässt halb verarbeitete Daten.

Die Diagnose in drei Minuten

Test 1: Läuft die Aufgabe über HTTP? Kopieren Sie die vollständige URL der Aufgabe samt Token und öffnen Sie sie in einem privaten Browserfenster. Läuft sie durch, liegt das Problem nicht bei PrestaShop, sondern beim externen Auslöser.

Test 2: Läuft sie auf der Kommandozeile? Führen Sie sie per SSH mit dem absoluten Pfad zum PHP-Interpreter aus. Eine Syntaxfehlermeldung deutet auf eine unpassende PHP-Version hin.

Test 3: Was sagt das Protokoll? Ergänzen Sie Ihre geplante Aufgabe grundsätzlich um eine Umleitung der Ausgabe:

wget -q -O - "https://boutique.fr/modules/ps_cronjobs/cron.php?token=XXXX" >> /home/compte/logs/cron.log 2>&1

Ohne Protokoll stellen Sie Ihre Diagnose blind. Das ist die lohnendste Änderung aus diesem ganzen Beitrag.

Die empfohlene Konfiguration

Bevorzugen Sie den HTTP-Aufruf gegenüber der Kommandozeile für PrestaShop-Aufgaben. Mit wget oder curl läuft das Skript im selben Kontext wie die Website: gleiche PHP-Version, gleiche Umgebungsvariablen, gleiche Rechte. Damit ist die erste Fehlerquelle beseitigt.

Ziehen Sie die Aufgaben zeitlich auseinander. Drei Katalogexporte in derselben Minute lasten den Server aus und bringen einander zu Fall. Verschieben Sie sie um einige Minuten.

Wählen Sie die Randzeiten für schwere Verarbeitungen – gemessen an Ihren tatsächlichen Verkaufszeiten.

Setzen Sie eine Zeitgrenze für schwere Skripte und zerlegen Sie sie in Pakete. Ein Export von 50 000 Artikeln gehört in Abschnitte, mit einem Wiederaufsetzpunkt.

Überwachen – oder es bleibt beim Blindflug

Ein stummer Cron bleibt eine unsichtbare Störung, auch wenn er sauber konfiguriert ist. Der einzige Schutz besteht darin, seine Ausführung zu überwachen.

Das Prinzip ist einfach: Ihre Aufgabe ruft am Ende ihres Laufs eine Kontroll-URL auf, die ein Monitoring-Dienst bereitstellt. Bleibt dieser Aufruf im erwarteten Zeitfenster aus, erhalten Sie eine Warnung. Sie werden also über das Ausbleiben der Ausführung informiert, nicht nur über einen Fehler – und genau das fehlt hier.

Fehlt ein externes Werkzeug, hält schon eine wöchentliche Kontrolle den Schaden klein: Datum des zuletzt erzeugten Feeds, Datum des letzten Buchhaltungsexports und Aktualität des Bestandsabgleichs prüfen.

Passend dazu: Erinnerungs-E-Mails, die nicht rausgehen, liegen häufiger an einem stummen Cron als am Versand selbst – siehe die Diagnose der PrestaShop-E-Mails.

Ihre geplanten Aufgaben absichern lassen

Wir prüfen Ihre Aufgaben, bringen ihre Auslösung in Ordnung und richten die Überwachung ein. Sehen Sie sich dazu unser Angebot zur Onlineshop-Betreuung an.