KeyHelp: Geplante Aufgaben für Kunden anlegen, PHP-Skripte und WordPress-Cron

Viele Websites brauchen Aufgaben, die regelmäßig laufen: ein PHP-Skript, das nachts Daten abgleicht, ein Newsletter-Versand oder die geplanten Ereignisse von WordPress. KeyHelp bringt dafür unter „Geplante Aufgaben“ eine eigene Oberfläche mit, in der Kunden solche Cronjobs ohne SSH anlegen. Diese Anleitung stellt alle drei Aufgabentypen vor, zeigt was KeyHelp daraus in der crontab des Kunden macht, wie Sie die Ausführung mit echten Zeitstempeln nachweisen und wie Sie WP-Cron von Seitenaufrufen auf einen festen Zeitplan umstellen. Sie richtet sich an Kunden und Administratoren eines Servers, wie er in KeyHelp installieren und absichern eingerichtet wird. Getestet haben wir mit KeyHelp 26.1.1 auf Debian 12 und dem Testkunden kunde1.

Voraussetzungen

• Ein KeyHelp-Server mit einem Kundenkonto. Getestet mit KeyHelp 26.1.1 (Build 3698) auf Debian 12.15, PHP 8.2.33.
• Ein Skript, das ohne Webserver lauffähig ist, oder eine URL, die der Server selbst auflösen kann.
• Für WordPress eine Installation im Webspace des Kunden. Im Test: WordPress 7.1.2 unter /home/users/kunde1/www/wp, installiert mit WP-CLI 2.12.0.
• Ein Postfach für Benachrichtigungen. KeyHelp schlägt die E-Mail-Adresse des Kunden vor.

Schritt 1: Die Seite „Geplante Aufgaben“ öffnen

Melden Sie sich als Kunde an und öffnen Sie „Ressourcen“, „Geplante Aufgaben“. Die Übersicht zeigt das Kontingent, im Test „0 / Unbegrenzt“, und den Knopf „Aufgabe hinzufügen“. Im Formular stehen drei Aufgabentypen zur Wahl:

• „Befehl ausführen“: eine beliebige Befehlszeile, etwa ein Shell-Skript.
• „PHP-Skript ausführen“: ein Pfad zu einer PHP-Datei plus Auswahl „PHP-Interpreter“, im Test nur „Standard - PHP 8.2.33“.
• „URL aufrufen“: eine Adresse, die per HTTP abgerufen wird.

Unter dem Pfadfeld steht der Hinweis „Verwenden Sie beim Zugriff auf Dateien immer absolute Pfade.“ samt dem Home-Verzeichnis des Kunden, hier /home/users/kunde1/. Darunter folgt der Zeitplan mit dem Hinweis „Der Server verwendet die Zeitzone Etc/UTC.“ Zur Auswahl stehen „Stündlich“, „Täglich“, „Wöchentlich“, „Monatlich“, „Jährlich“, „Minuten-Intervall“, „Stunden-Intervall“, „Nach Server-Neustart“ und „Cron-Syntax“. Vorbelegt sind „Täglich“ um 00:00 und die Benachrichtigung „Immer“.

Verifizieren: Prüfen Sie die Zeitzone des Servers, bevor Sie Uhrzeiten eintragen. Im Test lief der Server auf UTC, eine Aufgabe für 03:30 läuft dann in der Sommerzeit um 05:30 deutscher Zeit.

Schritt 2: Ein PHP-Skript als Aufgabe anlegen

Als Testskript haben wir eine kleine Datei angelegt, die bei jedem Lauf Datum, PHP-Version und den ausführenden Benutzer in eine Logdatei schreibt und „Fertig“ ausgibt:

mkdir -p /home/users/kunde1/cron
cat > /home/users/kunde1/cron/aufgabe.php <<"EOF"
<?php
$benutzer = function_exists("posix_geteuid") ? posix_getpwuid(posix_geteuid())["name"] : "unbekannt";
$zeile = date("Y-m-d H:i:s") . " PHP " . PHP_VERSION . " Benutzer " . $benutzer . "\n";
file_put_contents(__DIR__ . "/aufgabe.log", $zeile, FILE_APPEND);
echo "Fertig\n";
EOF
chown kunde1:kunde1 /home/users/kunde1/cron/aufgabe.php

Im Formular wählen Sie „PHP-Skript ausführen“, tragen bei „Beschreibung“ einen sprechenden Namen ein, hier „Test PHP-Skript“, und setzen den „PHP-Skript-Pfad“. Für den Test haben wir „Minuten-Intervall“ mit „Alle XX Minuten“ = 1 gewählt und gespeichert. Die Meldung lautete „Die geplante Aufgabe wurde erfolgreich hinzugefügt.“

Bewusst haben wir den relativen Pfad cron/aufgabe.php eingetragen, entgegen dem Hinweis im Formular. KeyHelp hat ihn ohne Prüfung angenommen, und er funktionierte: Die Aufgabe lief im Home-Verzeichnis /home/users/kunde1/ an, das Skript schrieb seine Logdatei nach cron/. Verlassen Sie sich darauf nicht und tragen Sie absolute Pfade ein, wie es das Formular verlangt.

Verifizieren: Die crontab des Kunden zeigt, was KeyHelp geschrieben hat:

crontab -l -u kunde1

#
# This config was generated by KeyHelp on 2026-10-01 19:20:02.
# System user: kunde1
#

SHELL=/bin/bash
TMPDIR=/home/users/kunde1/tmp/

# Test PHP-Skript
MAILTO="info@kunde1.example.de"
*/1 * * * * php cron/aufgabe.php

Gespeichert hatten wir nach 19:19 UTC, die Datei trägt den Zeitstempel 19:20:02. Das passt zum KeyHelp-eigenen Cronjob, der laut Systemjournal jede Minute mastercronjob.php startet:

Oct 01 19:20:01 server.example.de CRON[2025]: (root) CMD (nice -n 5 php /home/keyhelp/www/keyhelp/cronjob/mastercronjob.php)

Die Beschreibung landet als Kommentar über der Zeile, die Benachrichtigungsadresse als MAILTO, und TMPDIR zeigt in das tmp-Verzeichnis des Kunden.

Schritt 3: Die Ausführung nachweisen

Den Nachweis liefern drei Stellen: die Ausgabedatei des Skripts, das Journal von cron und die Benachrichtigungsmail. Die Logdatei füllte sich minütlich, ausgeführt als Benutzer kunde1:

cat /home/users/kunde1/cron/aufgabe.log
journalctl -u cron --since "-4min" --no-pager | grep "(kunde1) CMD"

2026-10-01 19:21:01 PHP 8.2.33 Benutzer kunde1
2026-10-01 19:22:01 PHP 8.2.33 Benutzer kunde1
2026-10-01 19:23:01 PHP 8.2.33 Benutzer kunde1
2026-10-01 19:24:01 PHP 8.2.33 Benutzer kunde1
2026-10-01 19:25:01 PHP 8.2.33 Benutzer kunde1
2026-10-01 19:26:01 PHP 8.2.33 Benutzer kunde1
Oct 01 19:23:01 server.example.de CRON[2397]: (kunde1) CMD (php cron/aufgabe.php)
Oct 01 19:24:01 server.example.de CRON[2488]: (kunde1) CMD (php cron/aufgabe.php)

Weil das Skript „Fertig“ ausgibt und die Benachrichtigung auf „Immer“ steht, verschickt cron eine E-Mail an die eingetragene Adresse. Die Mail zum ersten Lauf kam im Postfach info@kunde1.example.de so an:

From: root@server.example.de (Cron Daemon)
To: info@kunde1.example.de
Subject: Cron <kunde1@server> php cron/aufgabe.php
Date: Thu,  1 Oct 2026 19:21:01 +0000 (UTC)

Fertig

Laut Formular sendet „Immer“ nur, wenn das Skript etwas ausgibt, „Bei Fehlern (STDERR)“ nur bei Ausgaben auf den Fehlerkanal, mit dem ausdrücklichen Hinweis „Bitte beachten Sie, dass dadurch auch Benachrichtigungen verhindert werden, wenn der Befehl oder das Skript überhaupt nicht ausgeführt werden kann.“ Schreiben Sie Skripte daher so, dass sie im Erfolgsfall still sind, und lassen Sie „Immer“ stehen.

Verifizieren: Die Zeitstempel in der Logdatei liegen jeweils in Sekunde 01 der Minute und decken sich mit den CMD-Zeilen im Journal.

Schritt 4: WordPress-Cron auf einen festen Zeitplan umstellen

Laut WordPress-Entwicklerdokumentation prüft WP-Cron bei jedem Seitenaufruf, ob geplante Ereignisse fällig sind. Mit einer geplanten Aufgabe übernimmt cron diese Arbeit nach festem Zeitplan. Zuerst schalten Sie den Start per Seitenaufruf ab, hier mit WP-CLI im WordPress-Verzeichnis:

cd /home/users/kunde1/www/wp
runuser -u kunde1 -- wp config set DISABLE_WP_CRON true --raw

Success: Added the constant 'DISABLE_WP_CRON' to the 'wp-config.php' file with the raw value 'true'.

Um die Wirkung zu sehen, haben wir ein kleines Must-Use-Plugin angelegt, das bei einem eigenen Ereignis eine Zeile schreibt, und das Ereignis stündlich eingeplant:

runuser -u kunde1 -- wp cron event schedule sedv_cron_test now hourly

Success: Scheduled event with hook 'sedv_cron_test' for 2026-10-01 19:22:37 GMT.

Dann folgt die Aufgabe im Panel: „PHP-Skript ausführen“, Beschreibung „WordPress-Cron“, Pfad /home/users/kunde1/www/wp/wp-cron.php, „Minuten-Intervall“ mit 5 Minuten.

KeyHelp ergänzte die crontab um diesen Block:

# WordPress-Cron
MAILTO="info@kunde1.example.de"
*/5 * * * * php /home/users/kunde1/www/wp/wp-cron.php

Verifizieren: Fällig war das Ereignis seit 19:22:37 GMT. Ausgeführt wurde es erst um 19:25:01, zur gleichen Sekunde, in der cron wp-cron.php aufrief. Danach plante WordPress den nächsten Lauf eine Stunde später ein:

2026-10-01 19:25:01 sedv_cron_test ausgeführt
Oct 01 19:25:01 server.example.de CRON[2560]: (kunde1) CMD (php /home/users/kunde1/www/wp/wp-cron.php)
hook	next_run_gmt	recurrence
sedv_cron_test	2026-10-01 20:22:37	1 hour
1

Die letzte Zeile ist wp config get DISABLE_WP_CRON: Der Wert ist gesetzt. Der manuelle Lauf in Schritt 5 zeigte für wp-cron.php keine Ausgabe, laut Formulartext wird dann trotz „Immer“ keine Benachrichtigung gesendet.

Schritt 5: Eine Aufgabe sofort ausführen

In der Übersicht hat jede Aufgabe unter „Aktionen“ drei Symbole: bearbeiten, ausführen und löschen.

Ein Klick auf das Ausführen-Symbol startet die Aufgabe nicht sofort, sondern stellt sie ein. Die Seite meldet „Der Befehl /home/users/kunde1/www/wp/wp-cron.php wird in Kürze gestartet. Bitte aktualisieren Sie diese Seite, um nachfolgend aktualisierte Statusberichte zu erhalten.“ mit „Status: Ausstehend“. Nach etwa einer Minute neu geladen, zeigte KeyHelp einen Bericht mit Laufzeit, Rückgabewert und beiden Ausgabekanälen:

Verifizieren: „Rückgabestatus-Code: 0 (Erfolg)“ und leere „Fehlerausgabe (STDERR)“. Der Link „Klicken Sie hier, um alle ausstehenden und beendeten Aufgaben auf einmal zu entfernen.“ entfernt laut Beschriftung die Berichte wieder.

Schritt 6: „URL aufrufen“ richtig einschätzen

Der dritte Typ ruft eine Adresse ab. Wir haben https://kunde1.example.de/wp/wp-cron.php mit dem Zeitplan 30 3 * * * (täglich 03:30 UTC) eingetragen. KeyHelp schreibt dafür keinen direkten curl-Aufruf in die crontab, sondern ruft ein eigenes Hilfsskript auf:

# URL-Aufruf
MAILTO="info@kunde1.example.de"
30 3 * * * /usr/local/keyhelp/call_url 'https://kunde1.example.de/wp/wp-cron.php' > /dev/null

Laut Kopfkommentar prüft es, ob der Abruf den HTTP-Status 200 liefert:

# This script calls a URL and checks if the returned HTTP status code is 200.
# It is supposed to be used with KeyHelp's 'Scheduled Tasks' feature.

Der Abruf läuft vom Server selbst aus, also muss der Server den Namen auflösen können. Unsere Testumgebung hatte kein öffentliches DNS, der Name kunde1.example.de war dort nicht auflösbar. Der manuelle Start schlug deshalb fehl, das ist eine Grenze der Testumgebung und kein Fehler von KeyHelp. Der Bericht der Bericht meldete „Rückgabestatus-Code: 1 (Fehler)“ mit dieser Fehlerausgabe:

curl: (6) Could not resolve host: kunde1.example.de
Failed to call URL: https://kunde1.example.de/wp/wp-cron.php

Für Skripte auf demselben Server braucht „PHP-Skript ausführen“ dagegen keine Namensauflösung: Der Aufruf von wp-cron.php lief im selben Test fehlerfrei. Einen erfolgreichen URL-Abruf konnten wir in dieser Umgebung nicht prüfen.

Verifizieren: Nutzen Sie nach dem Anlegen immer einmal das Ausführen-Symbol und lesen Sie den Bericht, bevor Sie sich auf den Zeitplan verlassen.

Typische Fehler

• „Ungültige Angabe im Feld Zeitplan.“ Diese Meldung kam bei der „Cron-Syntax“ */5 * * (nur drei statt fünf Felder) und ebenso bei „Alle XX Minuten“ = 90. Für größere Abstände bietet das Formular „Stunden-Intervall“.
• Leerer Pfad: Das Formular wird gar nicht abgeschickt, der Browser meldet am Feld „Fülle dieses Feld aus.“
• Von Hand eingetragene Zeilen verschwinden. Wir haben mit crontab -u kunde1 - die Zeile */2 * * * * echo manuell >> /home/users/kunde1/cron/manuell.log angehängt und danach im Panel die Aufgabe „Test PHP-Skript“ abgeschaltet. Die neu geschriebene crontab von 19:30:01 enthielt nur noch die beiden übrigen Panel-Aufgaben, die manuelle Zeile war weg. Pflegen Sie Kunden-Cronjobs nur über das Panel.
• Uhrzeit falsch verstanden: Zeitpläne gelten in der Serverzeit, im Test UTC.
• „URL aufrufen“ schlägt fehl: „Could not resolve host“ heißt, der Server selbst kann den Namen nicht auflösen. Im Test lag das an der Testumgebung ohne öffentliches DNS. Wechseln Sie auf „PHP-Skript ausführen“ oder prüfen Sie DNS auf dem Server.

Häufige Fragen

Unter welchem Benutzer laufen die Aufgaben?

Unter dem Systembenutzer des Kunden. Das Journal zeigt (kunde1) CMD, das Testskript protokollierte „Benutzer kunde1“. Das Skript hat also dieselben Dateirechte wie der Kunde.

Wie schnell wirkt eine Änderung?

Im Test wurde die crontab beim nächsten Minutenlauf von KeyHelp neu geschrieben. Nach dem Deaktivieren der Testaufgabe kurz vor 19:30 UTC trug die neu geschriebene crontab den Zeitstempel 19:30:01. Um 19:30:01 lief die Aufgabe noch ein letztes Mal, um 19:31 nicht mehr.

Welche PHP-Version nutzt die Aufgabe?

Die im Feld „PHP-Interpreter“ gewählte, in der Übersicht als Kennzeichen neben php zu sehen. Im Test stand nur „Standard - PHP 8.2.33“ zur Auswahl.

Muss ich WP-Cron wirklich abschalten?

Wenn cron wp-cron.php aufruft, ist das sinnvoll, sonst prüft WordPress laut seiner Dokumentation weiterhin bei Seitenaufrufen. Mit DISABLE_WP_CRON hängt die Ausführung nur noch am Zeitplan, im Test lief das fällige Ereignis genau zum cron-Lauf.

Testumfang

Getestet haben wir in KeyHelp 26.1.1 die Aufgabentypen „PHP-Skript ausführen“ und „URL aufrufen“, die erzeugte crontab, Ausführung mit Zeitstempeln, Benachrichtigungsmail, manuellen Start und WP-Cron mit WordPress 7.1.2. Auffällig: Manuell eingetragene crontab-Zeilen überschreibt KeyHelp. „URL aufrufen“ scheiterte am fehlenden öffentlichen DNS der Testumgebung, ein erfolgreicher URL-Abruf ist nicht geprüft, ebenso der Typ „Befehl ausführen“, „Nach Server-Neustart“ und Administrator-Aufgaben für root. Prüfen Sie jede neue Aufgabe einmal mit dem Ausführen-Symbol.

Fazit

Die geplanten Aufgaben in KeyHelp sind eine saubere Oberfläche über der normalen crontab: Was Sie im Panel eintragen, steht kurz darauf mit Kommentar, MAILTO und TMPDIR beim Systembenutzer des Kunden. Für PHP-Skripte und WordPress ist „PHP-Skript ausführen“ mit absolutem Pfad im Test der direkte Weg ohne Abhängigkeit von DNS und Webserver. Kontrollieren Sie neue Aufgaben über den Ausführungsbericht, halten Sie Skripte im Erfolgsfall still und bearbeiten Sie Kunden-Cronjobs nicht an KeyHelp vorbei.

Weiterführende Anleitungen und Quellen

• KeyHelp installieren und absichern
• WordPress Cron Job einrichten: WP-Cron durch echten System-Cron ersetzen
• Cron und crontab richtig nutzen: die Grundlagen
• WordPress Developer Resources: Cron
• KeyHelp-Changelog (Release Notes)
• Keyweb: KeyHelp, alle Funktionen im Überblick