WordPress 5.0 Update verursacht unnötige Probleme

Selten war ein WordPress Update bereits im Vorfeld dermaßen kontrovers diskutiert worden. Kernpunkt der Neuerungen in der 5.0 Version des beliebtesten CMS weltweit ist die Integration der neuen Editor Engine namens Gutenberg. Kaum ein Durchschnittsnutzer, der seine WordPress-Webseiten nicht mit dem Visual Composer, Elementor oder dem SiteOrigin Pagebuilder aber stattdessen noch mit dem hauseigenen Editor baut.

Der klassische Editor (um die Möglichkeiten von TinyMCE Advanced und Shortcodes Ultimate erweitert) ist meiner Meinung nach völlig ausreichend, um ansprechende Inhalte zu erstellen, aber im Vergleich mit den eben genannten Schwergewichten der Branche lockt er heutzutage keinen Hund mehr hinter dem Ofen hervor.

Und auch wenn Gutenberg ein Schritt in die richtige Richtung scheint – der Wechsel ist zu krass und zu früh. Die Gutenberg Engine bricht radikal mit dem Konzept des klassischen Editors und ist technisch noch nicht ausgereift. Buggy, Kinderkrankheiten und ständig verschobene Release-Termine der 5.0er Version. Dazu kommen nicht wenige Plugin- und Themehersteller, die offen Stellung gegen die Veröffentlichung von WordPress 5.0 zu diesem Zeitpunkt bezogen haben. Das Irrwitzige ist ja, dass bei nicht wenigen WordPress Installationen der Webhoster das Update automatisch durchdrückt oder die Einstellungen entsprechend gesetzt sind, dass sich WordPress automatisch updated. Das gab dann große Überraschungen. Aber keine freudigen. Bei vielen Erweiterungen hakt es nach dem Update im Betrieb oder es lassen sich Einstellungen nicht abspeichern, der Cursor springt etc.
Gut, man könnte jetzt sagen: das 5.0 Update stelle ich zurück. Aber was ist mit den Plugin- und Theme-Updates? Die Entwickler haben um den 6.12.2018 herum viele Updates eingestreut, um ihre Plugins und Themes dem neuen WordPress anzupassen. Eigentlich dürfte man die dann auch nicht aktualisieren, aber wer kann schon sagen, ob das Plugin-Update xyz jetzt aus Anpassung an WordPress 5.0/Gutenberg resultiert oder damit Plugin-eigene Sicherheitslücken geschlossen werden. Oder beides? Ja, man könnte dies in den Release Notes nachlesen, aber das hilft dem Durchschnittsnutzer herzlich wenig.

Mögliche Lösungswege

Ich halte es im Moment so:

• WordPress Webseiten, die eher statischer Natur sind und bei denen nur 08/15 Plugins oder Themes laufen – von denen ich keine Kompatibilitätsprobleme erwarte -, werden auf WordPress 5.0 aktualisiert.
• WordPress Webseiten, mit denen richtig gearbeitet wird, also auf denen ständig neue Inhalte publiziert werden – Upgrade auf WP 5.0 bei gleichzeitiger Installation des Classic Editor Plugins. Dann kommt man zwar nicht in den Genuss von Gutenberg, aber meistens laufen auf solchen Seiten auch schon Pagebuilder wie Elementor, die man in dieser Konstellation einfach weiterbenutzen kann.
• WordPress Webseiten, bei denen ein Upgrade auf 5.0 richtig heikel werden könnte, verbleiben bei 4.9.8 und werden erst bei der bald zu erwartenden WordPress 5.x Version aktualisiert.

Wer böse erwischt wurde und bei dem die Webseite mit WordPress 5.0 nur noch herumzickt und kein vollumfängliches Backup besitzt, hat ein Problem. Für Plugins und Themes gibt es zur Not das WP Rollback Plugin, aber beim WP Kernsystem gibt es keinen Button, der einem das Downgrade ermöglicht.

WordPress händisch Downgraden

Dann müsst selbst Hand anlegen. Die offizielle WordPress-Webseite bietet auch immer Zugriff auf die früheren Veröffentlichungen an. Ladet euch also das zip-File der 4.9.8 oder meinetwegen 4.8.7 herunter und entpackt das.

Je nachdem, wie ihr Zugriff auf die Verzeichnisse und Dateien eures Webhosters habt (WebFTP, FTP, SSH …) – löscht auf eurem Webspace in der WordPress Installation die Ordner wp-includes und wp-admin. Das Verzeichnis wp-content rührt ihr nicht an. Auf derselben Ebene löscht ihr alles an Dateien, außer die .htaccess und die wp-config.php. Es kann sein, dass sich hier auch noch andere Dateien befinden, die für den laufenden Betrieb wichtig sind (php.ini, Google Authentification etc.). Aber da ihr ohnehin im Vorfeld (!) ein komplettes Datenbank- und Dateien-Backup zieht, könnt ihr dem gelassen entgegensehen.
Nachdem ihr die aufgezählten Sachen gelöscht habt, ladet die kompletten Verzeichnisse wp-admin und wp-includes aus eurem entpacken Archiv von der Festplatte hoch. Ebenso die Dateien, die ihr gelöscht habt. Wenn ihr euch dann wieder an der WordPress-Webseite anmeldet, müsste WordPress nicht mehr bei 5.0 stehen.
Für den Erfolg dieses Rollbacks gebe ich keine Garantie

Das mit dem Classic Editor ist aber nur ein Notbehelf, denn die Zukunft bei WordPress ist eindeutig mit dem Namen Gutenberg verknüpft. Kein Entwickler setzt jetzt noch auf den klassischen Editor und das damit verbundene Metaboxen Konzept. Momentan ist die Situation aber noch zerfahren und unübersichtlich, so dass man keine allgemeingültige Problemlösung anbieten kann.
Beispiel ist der SiteOrigin Pagebuilder, den ich vielfach einsetze. Nach dem WordPress Update kann man nicht einfach mehr Seiten oder Beiträge mit diesem freien Pagebuilder bearbeiten oder erstellen. Es öffnet sich der Gutenberg Editor und man kann über einen Siteorigin Layout „Block“ (in Gutenberg ist jeder Content-Schnipsel ein Block) sein gewohntes Arbeitsbild wiederherstellen. Obwohl der SiteOrigin Block noch Beta-Status hat, klappt das mit dem Pagebuilder in seiner Grundfunktionalität (Zeilen- und Widgetmanagement) ganz gut. Der SO Pagebuilder lebt aber von seinen zahlreichen Erweiterungen, die ihm erst das Maß an Funktionalität geben, dass ihn zu den Premium Pagebuildern ebenbürtig macht. Und bei diesen Erweiterungen hakt es zum Teil ganz gewaltig. Dafür kann SiteOrigin gar nichts und der Anwender erst recht nicht, aber das Problem ist nun einmal vorhanden. Bestehende Seiten und Beiträge mit problematischen Widgets können dann nicht geändert/bearbeitet werden, sofern man nicht das klassische Editor Plugin installiert und aktiviert.

Nirgendwo waren umfassende Backups so sinnvoll wie in dieser Angelegenheit.

Das ist vor allem so unnötig und wäre bei einem besseren Verhältnis von WordPress/Automattic zur Anwenderschaft vermeidbar gewesen.