WordPress 5.1.1 Multisites mit DB-Updateproblem

Nächste Warnung: Wer eine WordPress Multisite betreibt und von 5.0 auf 5.1.1 aktualisiert wird, der könnte ein Problem haben, ohne es zu wissen.

Datenbankupdate nicht ausgeführt

Die Fehler reichen von Logmeldungen wie dieser:

WordPress-Datenbank-Fehler Table ‚db466398.wp_blogmeta‘ doesn’t exist für Abfrage SELECT blog_id, meta_key, meta_value FROM wp_blogmeta WHERE blog_id IN (6) ORDER BY meta_id ASC von include(‚wp-load.php‘), require_once(‚wp-config.php‘), require_once(‚wp-settings.php‘), require(‚wp-includes/ms-settings.php‘), ms_load_current_site_and_network, get_site_by_path, get_sites, WP_Site_Query->query, WP_Site_Query->get_sites, _prime_site_caches, update_site_cache, update_sitemeta_cache, update_meta_cache

bis hin zu 500er Fehlern, wenn man die Webseiten aufruft.

Das Problem wurde vor 4 Wochen bereits bekannt, konnte aber nicht zuverlässig reproduziert werden von den Devs, tritt aber so oft auf, daß es kein Zufall mehr ist, ich habs ja auch gehabt 😉

Lösung:

Einloggen in die Datenbank und das hier ausführen:

CREATE TABLE `wp_blogmeta` (
`meta_id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
`blog_id` bigint(20) NOT NULL DEFAULT 0,
`meta_key` varchar(255) DEFAULT NULL,
`meta_value` longtext DEFAULT NULL,
PRIMARY KEY (`meta_id`),
KEY `meta_key` (`meta_key`),
KEY `blog_id` (`blog_id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8

Dann hören die Meldungen im Errorlog des Apachen auf. Ob das auch den 500er behebt, kann ich nicht sagen, da er mir nicht passiert ist. Wer sich jetzt fragt wo ich die Struktur her habe, es gibt in WP eine Datei, in der die DB Schemata drinstehen, da bekommt man das her.

 

Ihr habt WordPress und FastCGI im Einsatz?

Dann wird Euch sicher interessieren, wie man das reaktiver bekommt.

Das Problem

Wenn eine Seite mit FASTCGI läuft, wird PHP als CGI ausgeführt, also EXTERN vom Apache aus gesehen. Daher kann der Apache nur für native Files die GZIP Komprimierung übernehmen, nicht aber für die Webseiten selbst. PHP muß das tun, da es für den Datenstrom selbst zuständig ist.

Damit es das tut, fügen wir eine eigene php.ini mit diesem Inhalt im Hauptpfad ein:

zlib.output_compression = On
zlib.output_compression_level = 6

z.b. so “ echo ‚zlib.output_compression = On‘ > php.ini; echo ‚zlib.output_compression_level = 6‘ >> php.ini
Das wars. Fertig. Jetzt werden die PHP Seiten mit GZIP vom Server komprimiert und z.b. im Mobilfunknetz schneller übertragen. Alle werden es Euch danken 😉

Classic Editor is back

Ich hab es wirklich versucht, aber der neue Editor „Gutenberg“ von WordPress ist eine Qual. Das tut in der Seele weh. Wie kommt man nur auf sowas? Alleine schon die Optik hat mit Texte schreiben nichts zu tun. Diese Blocktechnik ist was für Facebook-Timelime-Kids u.V. .

Classic Editor reaktivieren

Da mit Gutenberg jeder seine eigenen schlimmen Erfahrungen gemacht hat oder noch machen wird, wenden wir uns produktiveren Dingen: Wie wird man ihn los?

Das ist zum Glück ganz einfach!

Im Dashboard unter Plugins „Installieren“ auswählen und in das Suchfeld „Editor“ eingeben. Kommt als erster Treffer mit über 1 Million Installationen „Classic Editor“ 😀 Alles mit OK bestätigen und Fertig.

Ich habe so das Gefühl, daß wird mit weitem Abstand das beliebteste Plugin werden.

Meine wenig positive Meinung  werde ich hier nicht zurückhalten: WP werdet die Typen los, die das verbrochen haben!

Die Aussichten bis 2020

Da die Menschheit ja bei wichtigen Entscheidungen immer die schlechtere Option wählt, haben besorgte Blogschreiber WP geforkt und lassen es ohne Gutenberg weiter laufen. GGF. muß man das in Zukunft als Option wählen, wenn man einfach nur Blogs schreiben will. Im Gutenberg habe ich nicht mal die Rechtschreibkontrolle gefunden, und das viele unnötige rumgeklickte um substanzielle Funktion zu erreichen. Wo es doch vorher super funktioniert hat. Das kommt bestimmt aus der Ecke der Handy und Tablelike-Benutzer mit Minibildschirmen. Als wenn das die Hauptgruppe der Blogschreiber wäre. Das wäre mir viel zu anstrengend mit den virtuellen Tastaturen. Wobei, „Diktieren“ ist ganz nett, führt aber meiner Erfahrung nach zu schlechtem Satzbau, so daß man viel editieren muß.

WordPress DOS – wp-admin Verzeichnis schützen

Die Hacker News berichten von einem Angriff auf WordPress, der von Seiten der Entwickler als „nicht-unsere-Baustelle“ abgeschmettert wurde, aber ganz leicht abgewehrt werden kann.

Der Angriff

Im wp-admin Verzeichnis gibt es ein Script namens „load-scripts.php„, das auf Zuruf, und liegt das Problem, alle Javascripte der Installation, zu einer gemeinsamen Javascriptseite zusammenbaut, damit der Browser nicht jede einzeln laden muß. Das Problem daran ist, jeder kann die Seite aufrufen. Wenn man dann noch die gesamten Javascripte eines WordPress zusammenstellen läßt, reichen wenige Aufrufe, bis die Webseite offline ist.

Das liegt daran, daß bei der Zusammenstellung sehr viel IO entsteht, was den Webserver belastet. Dadurch wird alles langsamer, bis es bei genug Anfragen zum faktischen Stillstand kommt. Dazu kommt eine erhöhte Rechenleistung während die Scripte Ihren Job tun.

Was meint WordPress dazu ?

Die sagen, daß ein Admin diese Seite aufrufen können muß, wenn er noch nicht als Admin erkennbar ist. Also muß es jeder können. Man solle doch das Problem irgendwo anders löschen, nur nicht bei Ihnen.

„However, the company refused to acknowledge the issue, saying that this kind of bug „should really get mitigated at the server end or network level rather than the application level,“ which is outside of WordPress’s control.“ (Zitat von THN )

Das ist natürlich peinlich, weil jemand das in WordPress gefixt hat und einen Fork davon bereitstellt. Es ist also scheinbar leicht möglich es zu beheben.

Eine Lösung des Problems

Wenn Ihr Zugriff auch Euren Webserver habt, erstellt Ihr einfach für wp-admin eine .htaccess Datei . Das kann man über eine Weboberfläche lösen, so wie hier :

Wenn man die HT-Accessabfrage mit  Usernamen und Passwort anlegt, fragt einen der Browser nach den Zugangsdaten, aber merkt sich die auch, so daß man selbst recht unproblematisch wieder ins Backend gelangt. ( Die 5.6 Version von PHP ist wohl beim Testen hängen geblieben und wurde bereinigt 😉 ).

Nach dem Anlegen zeigt meine Oberfläche dann auch an, daß dort eine HTAccess mit Benutzernamen liegt :

Admin-Weboberfläche nach dem Anlegen des Benutzers

Nach dem Anlegen des Benutzers

Wenn man das alles von Hand machen muß, geht das so :

In die Datei wp-admin/.htaccess  kommt dieser Inhalt, bei dem Ihr den Pfad anpassen müßt:

AuthType Basic
AuthName "Das ist mein WordPress!"
AuthUserFile /path_to_wp/wp-admin/.htpasswd
Require valid-user

danach gibt man in der Bash ein :

htpasswd -bc  /path_to_wp/wp-admin/.htpasswd username password

Das war es dann schon. Jetzt noch im Browser wp-admin/ aufrufen und die neuen Zugangsdaten eingeben und auf Speichern drücken.