Die Qualität der Langsamkeit. Etwas mehr Zurückhaltung bei der Einführung neuer Versionen wäre doch schön.
Vor rund zwei Wochen kam die WordPress-Version 4.5. Und inzwischen die fast schon obligatorische Korrekturversion 4.5.1 hinterher. Deswegen rate ich bei größeren WordPress-Websites im laufenden Betrieb dazu, bei einem Upgrade (neue Version) einige Zeit abzuwarten. Wer selbst aktualisiert, sollte sicherheitshalber sowohl den FTP- als auch den Hoster-Zugang parat haben, um sofort manuell eingreifen zu können.
Im Grunde läuft die neue Version gut und schön. Danke an die Core-Entwickler! Ich bin nicht undankbar, sondern froh, dass WordPress permanent gut gepflegt wird. Und bei vielen Websites klappt das Upgrade via „automatisch aktualisieren“ nahtlos. Aber eben leider nicht bei allen. So groß war das Fehlerpotenzial lange nicht mehr. Ganz besonders betrifft das ältere WordPress-Websites, die schon einige Jahre laufen.
Kleinere Websites, die ich flugs mal eben aktualisiert habe, waren plötzlich nicht mehr erreichbar. Da kommen nicht nur Laien ins Schwitzen. Klar konnte ich die Websites reanimieren, aber es dauert eben alles viel länger, als geplant. Was war der Grund?
Einmal passte die auf dem Server eingestellte PHP-Version nicht (in dem Fall lief die Seite mit 5.5 aber nicht mit 5.6, kurios), im anderen Fall hatte ich vergessen (Anfängerfehler …), zuerst die Plugins zu aktualisieren. Hier war das ältere WPML-Plugin nicht kompatibel – und ich musste die neue wpml-Version umständlich per FTP hochspielen. Im dritten Fall war das bisherige Datenbank-Passwort zu alt und zu kurz, auf diese Idee muss man erstmal kommen [Warning: mysqli_real_connect(): The server requested authentication method unknown to the client [mysql_old_password]. Außerdem gibt es lt. Support-Foren Probleme mit älteren Galerien und Lightboxen – besonders diese Art von Plugins bzw. Themes müssen vor dem Upgrade auf Kompatibilität geprüft werden. Sogar weit verbreitete Themes wie Avada melden Probleme.
Anscheinend geht die neue WordPress-Version ein wenig übermotiviert an den Start. Das war lange nicht mehr der Fall, bei den letzten Versionen blieb es doch recht ruhig. Nun wurde wohl mal wieder die Rückwärts-Kompatibilität vernachlässigt. Stattdessen wurden Plugin- und Theme-Entwickler vorab gedrängt, die Beta-Version zu testen – was wohl viele nicht getan haben.
Dass immer alles auf dem neuesten Stand der Technik sei soll, ist zwar eine nette Idee, aber wohl nicht mehr als ein frommer Wunsch. Zumal die sichtbaren Neuerungen dieser Version, wie das Einfügen von Links per Linkbox, einen nun nicht gerade umhauen. Klar, neue jQuery-Version ist wichtig, zweifelsohne. Sicherheitsupdates sowieso. Auch die verbesserte Bild-Komprimierung und der inline Script-Loader sind super.
Aber drei, vier Monate später hätte das Upgrade vielleicht auch gereicht … man muss die allgemeine Beschleunigungs-Spirale nicht unnötig befeuern und geneigte (Profi-) Nutzer damit stressen. Sonst könnte WordPress ganz schnell in den Ruf kommen, schwierig zu sein. Wo es doch immer als so einfach gilt – weswegen es zu Recht so populär wurde.
Anders als in Texas, sind die deutschen Webhoster bei Shared Hosting noch längst nicht alle bei php 5.6 angelangt. Hierzulande mahlen die Mühlen eben langsamer. Als ich im Januar 2016 eine neue WordPress-Website installierte, meckerte der Hoster-Support, weshalb ich SQL 5.5 haben wolle, es liefe doch auch so. Klar, solche Umstellungen sind für die Webhoster ein Arbeits- und Kostenfaktor. Übrigens war diesmal 1&1 bei den ersten, die schon Monate zuvor php 5.6 angeboten haben.
Man kennt das ja, den Traditionalisten unter den Administratoren ist WordPress ohnehin schon von Anfang an ein Dorn im Auge. Sie fürchten wohl den Kontrollverlust. Mag sein. Für Kontrollfreaks ist WordPress (bzw. eine Datenbank an sich?) vermutlich zu dynamisch. Da empfehle ich eine statische html5-Website.
Wer sich um WordPress-Websites kümmert, hechelt der schnellen Entwicklung von WordPress oft hinterher. Man muss ständig am Ball bleiben, in einem Jahr kann sich alles verändern. Das ist den betroffenen Kunden nicht immer leicht zu erklären. Ich denke, ein wenig langsamer wäre für alle Beteiligten besser. Klar, es ist nicht nur WordPress, sondern die technische Entwicklung an sich, mag sein. Aber man muss ja nicht jeden Schritt mitgehen, der von außen aufgedrückt wird, liebe WordPress-Core-Entwickler, sondern kann sicher auch mal welche auslassen. Auch bei Technik bewährt sich wie so oft: Never touch a running system. (Das soll jetzt keine Entschuldigung sein, die Sichererheitsupdates zu vernachlässigen. Ein unsicheres System läuft nicht, sondern dümpelt vor sich hin.)
Möglicherweise ist diese elende Update-Schufterei und aufwändige Pflege (bei kleinen Websites sind das mind. 2 Arbeitsstunden pro Jahr, bei größeren auch mal 20 …) ein Grund, dass der Trend zu Anbietern von zentral gepflegten Komplettinstallationen geht, wie Jimdo, Squarespace oder auch wordpress.com (in der Bezahl-Version ohne Werbung natürlich). Die Nutzer wägen ab, wie wichtig ihnen ist, dass ihre Daten auf dem „eigenen“ Server liegen. Sicher hängt es von der Art der speziellen Website ab. Für mich ist es im Grunde gleich gut, ob ich für meine Kunden eine Website bei einem „Komplettanbieter“ einrichte oder individuell WordPress auf dem eigenen Server installiere und dort pflege. Beides hat für die Stabilität von Websites und die Präsentation Vor- wie Nachteile. Es bleibt also spannend.
Hallo,
wohl wahr, wohl wahr…
Einer von mehreren Gründen, warum ich immer darauf bedacht bin, mit Plugins so sparsam wie möglich zu sein. Lieber ein paar Zeilen CSS und ein Profi-Theme als ein dutzend Plugins, die irgendwann Ärger machen. Und nicht jeder kennt sich dann so gut damit aus, um die Sachen schnell wieder in Ordnung bringen zu können.
Stimmt.