Auf einen Blick
- WordPress führt geplante Aufgaben nicht von selbst aus — angestoßen werden sie durch Seitenaufrufe.
- Bei wenig Besuch laufen Sicherungen, Newsletter und geplante Beiträge deshalb verspätet oder gar nicht.
- Ein echter Cronjob beim Hoster löst das. Wer dabei die halbe Einstellung vergisst, hat es danach schlimmer als vorher.
Wie WordPress Termine abarbeitet#
WordPress bringt eine eigene Terminverwaltung mit, den sogenannten WP-Cron. Dort tragen sich Erweiterungen ein: die Sicherung um drei Uhr nachts, die Prüfung auf Updates, der Newsletter am Dienstag, der auf Freitag geplante Beitrag.
Der entscheidende Unterschied zu einem echten Cronjob: WordPress schaut nur nach, wenn jemand die Seite aufruft. Bei jedem Aufruf prüft es, ob etwas fällig ist, und arbeitet es dann ab.
Das ist praktisch, weil es überall funktioniert, ohne dass jemand etwas einrichten muss. Und es ist der Grund für zwei ganz verschiedene Probleme.
Problem eins: zu wenig Besuch#
Eine Firmenseite mit ein paar Dutzend Besuchern am Tag hat nachts stundenlang keinen einzigen Aufruf. Genau dann sollen aber die Aufgaben laufen.
- Die Sicherung um drei Uhr läuft um halb neun, wenn der erste Kunde die Seite öffnet.
- Der auf acht Uhr geplante Beitrag erscheint mittags.
- Der Newsletter geht mit Verspätung raus — oder mehrfach, wenn der Versand mitten in der Abarbeitung abbricht.
- Sicherheitsprüfungen laufen unregelmäßig, und niemand merkt es.
Das Tückische daran: Es fällt nicht aus, es kommt nur zu spät. Und Verspätung sieht in keinem Protokoll nach einem Fehler aus.
Problem zwei: zu viel Besuch#
Bei einem gut besuchten Shop dreht sich der Fall um. Dort prüft WordPress bei jedem einzelnen Aufruf, ob etwas zu tun ist. Das kostet für sich genommen wenig — bei vielen gleichzeitigen Besuchern kann es aber passieren, dass mehrere Aufrufe dieselbe Aufgabe anstoßen.
Die Folgen reichen von doppelt verschickten E-Mails bis zu Sicherungen, die sich gegenseitig behindern.
Wann es auch ohne geht#
Nicht jede Seite braucht das. Eine reine Visitenkarte ohne Shop, ohne Newsletter und ohne geplante Veröffentlichungen kommt mit dem eingebauten Verfahren gut zurecht. Wer nichts Zeitkritisches plant, merkt den Unterschied nicht.
Sobald aber Geld, Post oder Termine daran hängen — Bestellungen, Rechnungen, Newsletter, Sicherungen —, gehört die Terminverwaltung auf den Server.
Wie es eingerichtet wird#
Zwei Schritte, und beide gehören zusammen.
Erstens wird der eingebaute Anstoß über Seitenaufrufe abgeschaltet. Dafür kommt eine Zeile in die wp-config.php, oberhalb der Zeile mit dem Hinweis „That’s all, stop editing“:
define( 'DISABLE_WP_CRON', true );Zweitens wird beim Hoster ein Cronjob angelegt, der dieselbe Datei in festem Takt aufruft. Wo das eingetragen wird, heißt bei jedem Anbieter anders — der Aufruf selbst ist überall gleich:
https://ihre-domain.de/wp-cron.php?doing_wp_cronAls Takt haben sich fünf bis fünfzehn Minuten bewährt. Häufiger bringt nichts, seltener macht aus „pünktlich“ wieder „irgendwann“.
Der Fehler, den wir am häufigsten finden#
Schritt eins gemacht, Schritt zwei vergessen. Die Zeile steht in der Konfiguration, der Cronjob beim Hoster fehlt — und damit läuft überhaupt nichts mehr.
Das fällt selten sofort auf. Vorher lief es unzuverlässig, jetzt gar nicht, und beides sieht im Alltag gleich aus. Bemerkt wird es meist erst, wenn jemand eine Sicherung zurückspielen will und feststellt, dass die letzte ein halbes Jahr alt ist.
Deshalb gehört zum Einrichten immer die Gegenprobe: einen Beitrag auf fünf Minuten später planen und nachsehen, ob er pünktlich erscheint. Das dauert fünf Minuten und beantwortet die Frage endgültig.
Wenn Sie nicht wissen, wie es bei Ihnen eingestellt ist: Schicken Sie uns die Adresse, wir sehen nach. Die Gegenprobe gehört bei uns zum Update-Service.