Der Alptraum wp-cron.php

BY admin
|

Ein großes Problem, das ich mit WordPress habe, ist die standardmäßige Implementierung von wp-cron.php. Wenn Sie damit vertraut sind, wie WordPress wp-cron.php standardmäßig verwendet, können Sie den nächsten Abschnitt dieses Artikels überspringen.

Die Datei wp-cron.php ist der Teil von WordPress, der geplante Ereignisse innerhalb einer WordPress-Site behandelt. Alles, was mit der Planung von Beiträgen oder Veröffentlichungen zu tun hat, und wirklich alles, was mit Datum und Uhrzeit zu tun hat, wird von der Datei wp-cron.php gesteuert.

Damit wp-cron.php richtig funktioniert, muss sie häufig ausgeführt werden, aber nicht öfter als einmal pro Minute. Das Standardverhalten erfordert jedoch nicht, dass Sie einen echten Cron-Job auf Systemebene auf Ihrem Server einrichten. Stattdessen wird eine Huckepack-Methode für jede eingehende Anfrage verwendet. Wenn eine Anfrage auf der Website eingeht, erzeugt WordPress eine zusätzliche Anfrage von sich selbst an die Datei wp-cron.php über HTTP(S). Das klingt ziemlich harmlos, nicht wahr?

Warum ist das Standardverhalten von wp-cron.php ein Alptraum?

Die Standardmethode funktioniert perfekt auf einer kleinen Website mit sehr wenigen Besuchern pro Stunde. Wenn sie jedoch auf einer mittelgroßen oder größeren Website oder sogar auf einer Website, die von Bots gescannt wird (was heutzutage sehr häufig vorkommt), implementiert wird, bedeutet dies, dass Sie das Doppelte des Datenverkehrs erhalten, den Sie derzeit verarbeiten. Es wird zu einem rudimentären DDoS-Angriff gegen Sie selbst. Der Grund dafür ist, dass der Cron mehrmals pro Minute mit einer HTTP-Anfrage ausgeführt wird. Die HTTP-Anfrage verursacht zusätzlichen Overhead, da die Verbindung über einen Netzwerk-Socket erstellt, ausgehandelt und aufgebaut werden muss. Sie wirkt sich sogar auf die effektive Kapazität des zugrunde liegenden Webservers aus. Diese Lösung eignet sich in den meisten Situationen nicht, und ehrlich gesagt sollte sie als Standardverhalten entfernt werden, da sie dazu neigt, missbraucht oder in einen Angriffsvektor auf einen Server verwandelt zu werden, der nur aus regulärem Datenverkehr besteht.

Was sind nun die Alternativen?

Die einzige wirkliche Alternative und die viel bessere Lösung besteht darin, einen regelmäßigen System-Cronjob zu konfigurieren, der das Skript wp-cron.php jede Minute direkt über PHP ausführt. Dadurch wird sichergestellt, dass alle geplanten Aufgaben tatsächlich zur geplanten Zeit ausgeführt werden. Es sollte auch nicht über eine HTTP-Anfrage erfolgen, sondern eine direkte Ausführung von PHP, um die Kapazität des Webservers nicht zu behindern oder zusätzlichen Speicher-Overhead auf der Netzwerkebene zu erzeugen.

Wie kann ich das Standardverhalten von wp-cron.php deaktivieren?

Dies ist ziemlich universell und einfach zu machen. Sie müssen Ihre wp-cronfig.php-Datei aktualisieren, um die folgende Einstellung aufzunehmen:

define('DISABLE_WP_CRON', true);
  • Sie finden Ihre wp-config.php-Datei normalerweise im Verzeichnis public_html Ihrer Website.
  • Diese neue Einstellung sollte in der Datei direkt nach der DB_COLLATE-Datenbankzeile vorgenommen werden, die wie folgt aussieht
define('DB_COLLATE', '');

Wie richte ich einen System-Cron-Job ein?

Das ist in cPanel ganz einfach, vorausgesetzt, Ihr Hosting-Provider hat die Cron-Job-Funktion für Ihren Account aktiviert. In der cPanel-Dokumentation zu Cron-Jobs finden Sie weitere Einzelheiten, aber im Wesentlichen müssen Sie Folgendes tun:

  1. Melden Sie sich im cPanel für Ihre Domain an: yourdomain.tld/cpanel
  2. Geben Sie „cron“ in das Schnellsuchfeld oben auf der Seite ein.
  3. Klicken Sie auf das Symbol „Cron-Jobs“, das erscheint.
  • Wenn es nicht erscheint, ist die Funktion „Cron Jobs“ in Ihrem Konto nicht aktiviert und Sie müssen sich an Ihren Hosting-Provider wenden, um Hilfe bei der Einrichtung des Cron zu erhalten oder zu einem Paket zu wechseln, das die Funktion „Cron Jobs“ enthält.
  1. Auf der Seite „Cron Jobs“ finden Sie den genauen Pfad zu Ihrem PHP-Binary. Kopieren Sie diesen Pfad in das Befehlsfeld unten auf der Seite und ändern Sie die von PHP ausgeführte Datei in die Datei /home/username/public_html/wp-cron.php ab. Verwenden Sie den vollständigen Pfad.
  2. Wählen Sie den ersten Eintrag („*“) für jeden Parameter. Dadurch wird die Datei wp-cron.php jede Minute ausgeführt.
  3. Klicken Sie auf die Schaltfläche „cron hinzufügen“ und Sie sind fertig.

Warum sind Sie so streng mit dieser Praxis, sie scheint vernünftig und leicht zu beheben zu sein?

Ich glaube, es liegt an den Software-Ingenieuren, die unsere digitale Welt entwickeln, sich selbst ein Verantwortungsgefühl für ihre Produkte einzuprägen. WordPress ist heutzutage allgegenwärtig, und mit automatischer Installationssoftware wie Softaculous wird WordPress auf einer sehr großen Mehrheit von Websites installiert. Sie werden mit aktiviertem Standardverhalten installiert, was im Grunde genommen einen Angriffsvektor auf jeden Server darstellt. Da die Hosting-Branche in unserem Leben so weit verbreitet ist, haben viele Leute WordPress-Sites und wissen nichts von diesem Problem, bis es ihre Site lahmlegt. Die Standardintegration ist äußerst unzureichend und sollte entfernt werden. Allein auf einem Server habe ich heute über 500 verschiedene WordPress-Installationen gefunden und beobachtet, wie ein Bot jede einzelne Site auf dem Server angriff. Jede einzelne dieser Sites wurde plötzlich zu einer Gefahr für die Stabilität des Servers.

Mir ist klar, dass dieses Problem von Fall zu Fall behandelt wird. Bei so vielen Installationen auf der ganzen Welt wäre es jedoch besser, wenn WordPress sich darum kümmern würde, als wenn jeder einzelne Hosting-Provider spezielle Bedingungen auf seinem Server einrichten müsste, um sich gegen das Loch zu schützen, das diese Software verursacht. Die Kosten für die Beseitigung dieses Verhaltens und die Erzwingung der Erstellung eines System-Cron-Jobs durch die Website-Besitzer sollten als Basis dienen, und es sollte ein Hinweis in der WordPress-Verwaltungsoberfläche platziert werden, dass geplante Aufgaben nicht ausgeführt werden, bis ein System-Cron-Job ordnungsgemäß erstellt wurde. Dies liegt im Rahmen meiner Programmierfähigkeiten, also weiß ich, dass es auch in deren Bereich liegt.

WordPress zielt auf Benutzerfreundlichkeit ab, daher sind die Zielkunden diejenigen, die in der Regel wenig über Vorbehalte beim Hosting wissen. Ich glaube, die Verantwortung liegt hier ganz bei WordPress, und sie haben sich dagegen ausgesprochen. In der Zwischenzeit müssen die Systemadministratoren in der Hosting-Branche unter dieser schrecklichen „Funktion“ leiden, wenn sie Server untersuchen, die durch einen Bot, der über eine Standard-WordPress-Installation läuft, außer Kontrolle geraten sind.