Die Aktualisierung mehrerer databaseen für mehrere databaseen beansprucht Erfolg, aber db_version wurde nicht aktualisiert

Ich habe WP Core 4.4.2 für eine Weile ausgeführt und gerade auf 4.6.1 aktualisiert. Ich führe eine Installation für mehrere Standorte unter einem Verzeichnis durch.

Ich kann keine automatischen Updates verwenden. Also deaktiviere ich alle Plugins, kopiere die neuen Core-Dateien, logge mich als Super-Admin ein und starte dann www.example.com/wp/wp-admin/network/upgrade.php . Wenn ich auf den Link zum Upgrade Network , durchläuft es ein paar Seiten mit allen Seiten (ungefähr 5 Seiten pro Seite) und sagt dann, dass alles fertig ist.

Wenn ich phpMyAdmin verwende und den Wert von db_version in den verschiedenen wp_nnn_options Tabellen wp_nnn_options , ändert sich der Wert nicht vom Upgrade. Aber es ändert sich nur in der ” wp_options -Tabelle der “root” wp_options . Zumindest für dieses Update. db_version Wert db_version für einige andere frühere Aktualisierungen in den Tabellen wp_nnn_options .

Und für dieses Update, wenn ich www.example.com/wp/wp-admin/sitename/upgrade.php für einen bestimmten Unterstandort manuell ausführe, dann ändert sich der Wert von db_version in der Tabelle wp_nnn_options für diesen bestimmten Unterstandort .

Ist das normal / erwartetes Verhalten? Sollte ich davon absehen, upgrade.php manuell auf den einzelnen Unterseiten laufen zu upgrade.php und einfach dem Netzwerk-Upgrade zu vertrauen, um das Richtige zu tun?

Solutions Collecting From Web of "Die Aktualisierung mehrerer databaseen für mehrere databaseen beansprucht Erfolg, aber db_version wurde nicht aktualisiert"

Dank hilfreicher Hinweise von TheDeadMedic sehe ich, dass mein Problem durch meine eigene Anwendungsumgebung verursacht wird, die ich in der Frage nicht angegeben habe, weil ich es nicht für relevant hielt. Das tut mir leid! Normalerweise beschreibe ich die Umgebung kurz, wenn ich eine Frage stelle, aber es war nie zuvor relevant, also habe ich es diesmal ausgelassen 🙁

Ich verwende WordPress als eine Art Subsystem für eine Zend Framework MVC application , die eine Anmeldung erfordert. Der Zugriff auf fast alle WordPress Seiten erfordert, dass der Benutzer bei der ZF application angemeldet ist. Wenn bei einer Anfrage keine eingeloggte ZF session ist, wird die Anfrage zur Anmeldeseite umgeleitet und die Anmeldeseite wird mit der Meldung angezeigt, dass Login erforderlich ist. Diese Seite wird jedoch mit einem 200-Statuscode angezeigt ( Seltsamerweise habe ich kürzlich eine Änderung erwogen, um beim Anzeigen der Anmeldeseite mit dieser Nachricht den Status 401 oder 403 zu erhalten, aber ich habe das noch nicht getan).

Das Skript network upgrade.php verwendet cURL , um das Script upgrade.php für jede untergeordnete Site im Netzwerk anzufordern. Diese cURL-Anfragen erhalten tatsächlich eine Antwort (nach der Weiterleitung), die nur die Anmeldeseite für die ZF application . aber da es einen Statuscode von 200 hat, glaubt das Netzwerk-Upgrade, dass jede Site-Aktualisierung erfolgreich war, und alle sind glücklich, obwohl in der WP-database nichts geändert wurde.

Ich war verwirrt / falsch, als ich sagte, dass die Root-Site aktualisiert wurde. Ich muss es manuell aktualisiert haben und habe es vergessen, als ich phpMyAdmin zu sehen, was mit der database passiert ist. Wenn ich von einem Backup aus wp_*options , sehe ich, dass bei der Durchführung des Netzwerk-Upgrades keine der wp_*options db_version ihre db_version aktualisiert hat (noch wurde die wp_blog_versions Tabelle aktualisiert).

Im Moment konnte ich jede Unterseite manuell aktualisieren, da es nur 10 von ihnen gibt, aber diese Zahl sollte wesentlich wachsen. Ich schätze, ich werde eine neue Frage stellen, um zu sehen, ob es eine Möglichkeit gibt, die cURL Anfragen zur Verwendung der PHP-Sitzung des aufrufenden Codes zu bekommen (die ZF application speichert den Anmeldestatus in der Sitzung).

Das zugrunde liegende Problem und die Lösung


Wie oben erwähnt, wurden die cURL Anforderungen (die innerhalb von WP_Http::request() , aufgerufen von network/upgrade.php , um jede einzelne Unter-Site zu aktualisieren) auf die Anmeldeseite der ZF application's umgeleitet. Dies lag daran, dass sie nicht auf die gleiche PHP-Sitzung wie das Netzwerkupgrade-Skript zugreifen konnten, da sie den PHPSESSID Cookie nicht PHPSESSID . cURL und WP_Http::request() bieten eine Möglichkeit, Cookies mit einer Anfrage weiterzuleiten, und es gibt einen Filter namens “http_request_args”, mit dem Cookies zu einer Anfrage hinzugefügt werden können. Ich könnte das verwenden, um den Cookie PHPSESSID , der das Verhalten verbesserte, aber es war immer noch nicht ganz richtig. Es stellte sich heraus, dass es zwei zusätzliche Probleme gab:

  1. Mein Code für die Integration von WordPress in die ZF application verhindert den Zugriff auf die Root-Site, es sei denn, der WordPress Benutzer ist ein Super-Administrator. Und da WordPress Cookies verwendet, um den Anmeldestatus beizubehalten, müssen diese Cookies auch in den Anforderungen übergeben werden, die die Upgrade-Skripte ausführen. Anscheinend überprüfen die einzelnen Upgrade-Skripte den WordPress Login-Status (!) Nicht. Also habe ich den ‘http_request_args’-Filter verwendet, um den $_COOKIE Superglobal zusammenzuführen.

  2. Wenn eine PHP-Sitzung aktiv ist, ist die Datei mit den Sitzungsdaten gesperrt. Damit die Anforderung, die ein Upgrade-Skript session_write_close() , die Sitzung des aufrufenden Skripts verwendet, muss das aufrufende Skript session_write_close() aufrufen, um die Sitzungsdatei zu entsperren. Kein Problem für WordPress selbst, da es nicht die Sitzung verwendet, aber für meine Integration mit der ZF application wesentlich ist. Es gab keinen Haken, den ich leicht finden konnte, um diesen Aufruf hinzuzufügen, also habe ich ihn direkt vor dem Aufruf von Requests::request in die class-http.php Datei geschrieben, geschützt durch Tests, dass meine ZF application aktiv ist, eine PHP-Sitzung ist aktiv und die Anforderung wird an denselben Server gesendet, der in der aktuellen Anfrage angegeben ist:

     if (ZF_PLUGGABLE_RUN && session_status() == PHP_SESSION_ACTIVE && $defaults['cookies'] == $_COOKIE) { // PHP keeps session file locked, need to close it to allow the request to use it session_write_close(); } 

Ich versuche zwar, Core-Dateien zu bearbeiten, aber es gibt eine Handvoll Orte, an denen ich keinen passenden Hook gefunden habe. Ich verwalte die Core-Dateien unter git und trage jede Datei, die ich in jeder Version ändere, separat nach, so dass das Abrufen einer neuen Version einen relativ kleinen, wohldefinierten Merge-process beinhaltet.

Endgültige Lösung ohne Core-Datei zu bearbeiten


Obwohl unmittelbar vor dem Aufruf von Requests::request() kein Hook vorhanden war, stellte sich heraus, dass der Filter “http_request_args” nahe genug war. So, jetzt habe ich die Core-Datei-Bearbeitungen entfernt und definieren Sie einfach den ‘http_request_args’ Filter wie folgt (innerhalb einer class, die andere Filter für die Integration von WordPress mit meiner ZF application ). Ich füge diesen Filter nur hinzu, wenn meine ZF application aktiv sein soll. ZF_PLUGGABLE_RUN ich die ZF_PLUGGABLE_RUN Konstante nicht testen:

 public function http_request_args($args, $url) { $retval = $args; if (@parse_url($url, PHP_URL_HOST) == $_SERVER['SERVER_NAME']) { // The request is going to our own server, so we need to provide it our current cookies, // including both PHPSESSID for the session holding the ZF user, and the WordPress cookies // holding the WordPress user. if (! array_key_exists('cookies', $args)) { // The default array settings in WP_Http::request() include a 'cookies' element, // so that element should always be present in $args. throw new Exception("Unexpected: \$args does not contain an element name 'cookies'"); } if (! is_array($args['cookies'])) { // The default value of $args['cookies'] is an empty array, not null throw new Exception("Unexpected: \$args['cookies'] is not an array"); } // In known example of self-directed requests for database update, $args['cookies'] // will be empty. But for generality, instead of assigning it a value, just merge in // the $_COOKIE superglobal, letting any user-specified cookies in $args['cookies'] override. $retval['cookies'] = array_merge($_COOKIE, $args['cookies']); // PHP keeps the session file locked, so we need to close it to allow the request to use it if (session_status() == PHP_SESSION_ACTIVE) { session_write_close(); } } return $retval; }