Wie genau funktionieren automatische Updates?

Ich habe heute Morgen eine E-Mail erhalten, die besagt, dass meine Wordpress-Site automatisch auf die neueste Version aktualisiert wurde. Ich wusste über die Funktion Bescheid, habe mich aber immer genau gefragt, wie sie funktioniert.

PHP ist kein permanent laufender Prozess: Es wird nur auf Anforderung ausgeführt. Soweit ich das beurteilen kann, kann sich Wordpress nur selbst aktualisieren, wenn jemand eine Webseite lädt. Der Aktualisierungsvorgang ist jedoch nicht sofort möglich, sodass ein Benutzer, der die Website besucht, mit Sicherheit nur sehr langsam eine Seite laden muss.

Gibt es einen anderen Trick für automatische Updates? Ich habe überall gesucht, aber keine Erklärung gefunden.

PHP ist kein permanent laufender Prozess: Es wird nur auf Anforderung ausgeführt. Soweit ich das beurteilen kann, kann sich Wordpress nur selbst aktualisieren, wenn jemand eine Webseite lädt. Der Aktualisierungsvorgang ist jedoch nicht sofort möglich, sodass ein Benutzer, der die Website besucht, mit Sicherheit nur sehr langsam eine Seite laden muss.

Gibt es einen anderen Trick für automatische Updates? Ich habe überall gesucht, aber keine Erklärung gefunden.

Das System, das Sie hier suchen, heißt "WP Cron". Es ist ein Hintergrundprozesssystem in WordPress, mit dem Ereignisse außerhalb der normalen Verarbeitung auftreten können. Sie benötigen immer noch einen Auslöser, um sie auszulösen, aber sie stören das Laden von Seiten aufgrund des Hintergrundprozesses nicht.

Also ja, jemand muss Ihre Seite laden. In der Datei default-filters.php finden Sie folgende Codezeile:

add_action( 'init', 'wp_cron' );

Daher wird bei jedem Laden der Seite die Funktion wp_cron ausgeführt. Diese Funktion ist in wp-includes / cron.php beendet und überprüft die geplanten Ereignisse in der Datenbank. Wenn es Prozesse gibt, die im Hintergrund ausgeführt werden müssen, ruft es die Funktion spawn_cron auf.

Spawn cron kann auf zwei Arten ausgeführt werden. Am häufigsten wird jedoch die Funktion wp_remote_post aufgerufen, um über die URL von wp-cron.php eine Verbindung zu sich selbst herzustellen. Durch diese zusätzliche HTTP-Anforderung wird ein weiterer PHP-Prozess gestartet, der die gesamte eigentliche Arbeit erledigt. Die Anforderung, die hier gestellt wird, ist mit einer Zeitüberschreitung von 0,01 Sekunden nicht blockierend. Daher werden hier eigentlich keine Ergebnisse erzielt. Der Zweck der Anfrage ist einfach, einen neuen Prozess im Hintergrund zu starten. Nachdem dies erledigt ist, kehrt es einfach zurück, so dass der Betrachtungsbenutzer keine Verzögerungen hat.

Der Prozess wp-cron.php erledigt die eigentliche Arbeit, das Update und alles andere. Viele Prozesse in WordPress werden vom Cron-System verwaltet. Geplantes Nachveröffentlichen, Verarbeiten von Pings, Aktualisierungsprüfungen, alles, was außerhalb des normalen Ablaufs geschehen muss, kann geplant und dann nach Bedarf ausgeführt werden.

Aber ja, ein normaler Treffer auf der Website muss tatsächlich passieren, um den Prozess auszulösen. Und nein, WordPress.org kontaktiert Ihre Site nicht direkt, um die Dinge anzukurbeln. Ihre Site muss irgendeine Art von Verkehr erhalten, um sie zu starten. Jede Form von Verkehr wird ausreichen.

Eigentlich wird das automatische Update von gepusht wp.org. Der Update-Vorgang läuft weiterhin auf Ihrer Site, jedoch im Hintergrund über wp-cron.

Wenn ein neues kleines Update veröffentlicht wird, fangen die Jungs von WordPress an, das Update herauszubringen. Der eigentliche Update-Vorgang wird gestartet, nachdem Ihre Site auf wp.orgUpdates überprüft wurde , theoretisch ein Update verfügbar ist und Ihre Site nach dem Zufallsprinzip ausgewählt wurde, um aktualisiert zu werden.

(Vielen Dank an @otto für den Hinweis auf meine falsche Formulierung :))

Da jede Site wp.orgnach neuen Versionen sucht (normalerweise zweimal täglich wp-cron), weiß der Rollout-Server , wie viele Sites aktualisiert werden müssen.

Dann beginnt der Rollout langsam - 1 von 128 Sites wird automatisch aktualisiert. Dies wird überwacht, und wenn die Erfolgsrate keine Probleme mit dem Rollout anzeigt, erhalten mehr Sites das automatische Update (normalerweise ist der nächste Schritt 1 von 64 und wird auf diese Weise weiter ausgebaut), bis alle automatischen Updates bereitgestellt sind.

Auf diese Weise können die Entwickler den Rollout stoppen, wenn Probleme auftreten. Das letzte Update von 3.8bis 3.8.1hatte jedoch eine Erfolgsquote von 100%.

Die von der ausgewählten Websites 1 out of 128sind tatsächlich zufällig. Nun, nicht wirklich, aber wenn du es wissen willst, funktioniert es so:

Die URL der Site, die ein Update benötigt, wird mithilfe von Hashes überprüft MD5. Wenn nur die ersten drei Zeichen dieses Hashs verwendet und in konvertiert werden base10, ergeben sich 4096 Möglichkeiten. Das Update wurde für Sites mit einer berechneten Anzahl zwischen 0 und 31 (4096/32 = 128) gestartet.

Okay, ich denke es ist doch ziemlich zufällig;)

In meinem Fall, da ich viele WordPress-Sites betreibe, dauerte die Aktualisierung 1 Tag - es war ziemlich lustig zu sehen, wann alle Seiten aktualisiert wurden.

Nur für den Fall, dass Sie sich fragen: D

Übrigens, hier ist ein Artikel auf make.wordpress.org, der den Vorgang beschreibt.

Wenn ein Benutzer die Site besucht, prüft WordPress, ob der Zeitgeber abgelaufen ist, und wenn ein Ablauf festgestellt wird, wird eine weitere Anforderung an den Server gesendet, um die mit dem abgelaufenen Ereignis verbundenen Aktionen auszuführen. Aus diesem Grund verspürt der Benutzer keine merkliche Verzögerung beim Laden der Seite, da der Server die eigentliche Aktion (in diesem Fall das Upgrade) in einem separaten Prozess ausführt.

Dies funktioniert, aber das Timing ist nicht sehr genau. Je mehr Verkehr Ihre Website hat, desto genauer wird es sein.

Benutzer, die eine bessere Leistung und ein genaueres Timing wünschen, können den internen Cron-Prozess von WordPress blockieren und den Cron-Prozess des Betriebssystems verwenden, um die Überprüfung von Timern auszulösen.