Du hast in deiner WordPress-Installation schon lange kein Update mehr gemacht? Und das nur, weil du Bammel hast, dass deine Website im Nirwana verschwindet? Dann hilft dir vielleicht meine ToDo-Liste, die ich neulich für eine Netzwerk-Kollegin erstellt habe. Auf keinen Fall solltest du einfach auf die Knöpfe im Backend drücken, sondern die anstehenden Updates gut vorbereiten. Keine Angst, es ist Arbeit aber keine Raketenwissenschaft.

Ich liste mal die Schritte auf, die ich vornehmen würde:

1. Backup machen

   Zunächst machst du ein Backup deiner gesamten Installation – sowohl von den Dateien als auch von der Datenbank. Sie ist besonders wichtig, denn sie ist das Herzstück deiner Installation und enthält alle Einstellungen sowie die Inhalte deiner Seiten und Beiträge. Du solltest unbedingt das Theme und alle Plugins einbeziehen, denn wenn diese Komponenten schon älter sind, ist die Wiederbeschaffung vermutlich nicht ganz einfach. Nicht vergessen den Upload-Ordner mitzunehmen, denn er enthält alle über die Mediathek hochgeladenen Bilder oder andere Dateien wie PDFs. Dazu nutzt du ein Plugin wie BackWPup oder UpdraftPlus, falls du nicht bereits eines installiert hast. Beide Plugins gibt es in einer kostenfreien und einer kostenpflichtigen Pro-Version.

2. PHP-Version checken

   Gut möglich, dass deine Seite noch mit einer älteren PHP-Version wie 5.6 läuft. Dein Provider hat dich dazu bereits angeschrieben und du zahlst nun extra für diesen Support? Dann ist es Zeit, auf PHP7 umzustellen. Mit WordPress selbst sollte es keine Probleme geben, wenn bei dir mindestens die Version 4.2 läuft. Die unterstützt bereits neueres PHP. Anders ist es bei Plugins und Themes, die möglicherweise nicht mitspielen. Teste daher zunächst, ob alle deine installierten Komponenten bei PHP7 mitspielen. Dazu empfehle ich diesen Beitrag von Torsten Landsiedel und den dort erwähnten Compatibility Checker.Achte darauf, dass du im Zeifel auf PHP5.6 zurückstellen kannst. Sollte es trotz Prüfung Probleme geben, machst du die Einstellung zunächst wieder rückgängig, damit die Seite läuft.

3. Umstellung erfolgreich

   Alles ok? Dann kannst du es bei der neuen PHP-Einstellung belassen. Die Updates sollten nun problemlos durchgeführt werden können. Meine Empfehlung für Plugins: Immer nur ein Update auf einmal. Sollte doch etwas schief gehen, weißt du gleich, welches Plugin das Problem ausgelöst hat.

4. Umstellung fehlgeschlagen

   Nicht alles ok? Bei einigen Plugins oder beim Theme hat die Prüfung ein rotes X ergeben? Dann musst du dir diese Komponenten genauer ansehen.

   • Theme

     Das Theme muss unbedingt funktionieren. Gibt es hier ein rotes X, dann schaust du auf der Seite des Theme-Entwicklers oder bei WordPress nach, ob es ein Update gibt, das für PHP7 geeignet ist. Es könnte allerdings sein, dass die neuere Theme-Version nicht mehr mit PHP 5.6 arbeitet. Dann aktivierst du zunächst ein Standard-Theme. Für solche Fälle solltest du immer eines installiert haben. Sonst musst du das jetzt nachholen. Erst nach der PHP-Umstellung machst du dann das Update für dein eigentliches Theme und aktivierst es wieder. Möglich, dass du einige Einstellungen anpassen musst.

   • Plugins

     Hier hilft ein Blick in die WordPress-Bibliothek der Plugins. Sollte eines oder mehrere deiner Plugins hier nicht mehr gelistet sein, musst du sie im Zweifel mit einem geeigneten ähnlichen Plugin ersetzen oder auf das Plugin verzichten.Ist deine PHP-Version älter als 5.6 stellst du zunächst auf PHP5.6 um. Damit müssten die bisherigen Komponenten (Plugins und Theme) noch umgehen können. Danach machst du alle Updates für Plugins und Theme. Wenn alles läuft, versuchst du die Umstellung auf PHP7.

5. Update

   Mit WordPress 5 wurde Ende 2018 der neue Editor „Gutenberg“ eingeführt. Nicht alle aktuellen Plugins und Themes kommen damit zurecht. Bevor du also auf die aktuelle WordPress-Version 5.1.x umstellst, solltest du noch das Plugin Classic Editor installieren und aktivieren. Unter „Einstellungen -> Schreiben“ legst du den bisherigen Editor für deine Seite festlegen. Plugins, die mit Gutenberg nicht funktionieren, steht so automatisch der „Classic Editor“ zur Verfügung.

   Wenn du Gutenberg ausprobieren willst, dann erlaubst du dort den Wechsel. Dann kannst du individuell auswählen, ob du in deinen Seiten oder Beiträgen mit Gutenberg arbeiten willst. Meinen Beitrag zur Umstellung auf Gutenberg findest du hier.

6. Wiederherstellung

   Falls der SuperGAU eintritt und deine Seite nicht mehr erreichbar ist, kommt dein Backup zu Einsatz. Die alten Dateien und die gesicherte Datenbank müssen zurück in dein Account. Dabei hilft dir das bereits genannte UpdraftPlus, wenn du dein Backup damit erstellt hast. Es bietet die Recovery-Funktion bereits in der kostenfreien Variante. Oder du fragst bei deinem Provider nach, ob er ein Backup bereit hält und deine Website in den alten Zustand versetzen kann.  Dieser Service ist allerdings bei den meisten Providern kostenpflichtig.

Fazit

Du hast es geschafft und dein Webauftritt ist auf dem neuesten Stand? Dann kannst du echt stolz auf dich sein! Ab jetzt sind die regelmäßigen Updates nur ein Klacks für dich. Um den nächsten „Gewaltmarsch“ zu vermeiden, solltest du die angefallenen Updates zukünftig zeitnah vornehmen.

Welche Erfahrungen hast du gemacht? Ich freue mich, deinen Kommentar zu lesen.

Ladezeiten – ein wichtiger Ranking-Faktor bei der WordPress Suchmaschinenoptimierung

Bereits seit einigen Jahren setzt sich Google vor allem dafür ein, lange Wartezeiten beim Aufbau einer Website zu vermeiden. User sollen insbesondere bei schlechten Handy-Verbindungen nicht allzu lange auf die gesuchte Information warten müssen. Auf diesen Zug sind mittlerweile viele Anbieter von mehr oder weniger kostenintensiven Dienstleistungen und Prüf-Tools aufgesprungen. Auch wenn das in diesem Bereich viele Analyse-Tools suggerieren, Raketenwissenschaft ist die Seiten-Optimierung nicht.

Welche Maßnahmen wirkungsvoll die Ladezeiten herabsetzen können, erläutere ich im Folgenden anhand des kürzlich fertiggestellten Kundenprojektes https://www.textfuss.de/. Das hier verwendete Theme ist übrigens „Enfold“. Ich beschränke mich hier zunächst auf Maßnahmen für Einsteiger, die sich mit Plugins realisieren lassen.

WordPress 3 Schritte zur Optimierung der Performance

Schritt 1: der Start-Check

Meine bevorzugte Testumgebung ist GT-Metrix. Es ist sowohl für den Allround-Check als auch für eine tiefergehende Analyse geeignet. Für den Start reicht ein Blick in den „Page Speed“.

Ein Score von 85 % ist für den Anfang bei der WordPress Suchmaschinenoptimierung nicht schlecht, optimal ist das aber noch nicht. Schauen wir uns die wichtigsten Stellschrauben mal genauer an.

Schritt 2: die Optimierung der schlecht bewerteten Punkte

Bilder

Besonders schlecht schneiden die Bilder in der Seite ab. Sie ziehen das Ergebnis der WordPress Suchmaschinenoptimierung maßgeblich runter. Daher solltest du ihnen erhöhte Aufmerksamkeit schenken:

• Die Bildgröße sollte den tatsächlich verwendeten Maßen entsprechen.
  Keine Bilder direkt aus der Kamera in die Website laden. Für die einfache Verkleinerung reicht ein Programm wie Irfanview. Bei Gregor Möllring findest du eine Anleitung dazu.
• Die Dateigröße der Bilder weiter reduzieren.
  Bildbearbeitungsprogramme leisten hier schon einiges. Besser arbeiten Tools, die Bilder auch mit einem gewissen Verlust komprimieren können. Mein Lieblings-Tool für Bilder im JPG-Format ist der mozjpeg Encoder. Das kostenfreie Online-Werkzeug kann Bilder mit einer Verlustrate bis zu 60 % komprimieren. Vorher- und Nachher-Version stehen nebeneinander. So kann man sehen, ob die gewählte Verlustrate noch akzeptable Bilder ausgibt. Ansonsten ändert man die Einstellungen und versucht es erneut. Das fertige Bild lädt man auf den eigenen Rechner herunter.
  Die Einsparungen bei der Dateigröße sind meist enorm.
• Dateigrößen beim Upload reduzieren
  Geeignete Plugins komprimieren Bilder in WordPress direkt beim Upload in die Mediathek. Die freien Varianten ersparen zwar nur wenige Prozent, was sich aber dennoch lohnt – insbesondere für Blogger. Manche kostenpflichtige Plugins erlauben auch die verlustbehaftete Komprimierung. Ich bevorzuge hier WP Smush.

Browser-Caching

Alle statischen Anteile in der Webseite speichert der Browser mit dem ersten Aufruf der Seite. Insbesondere sind das Bilder, Schriften und auch Skripte. Dazu braucht der Browser eine Anweisung, welche Inhalte er wie speichern soll. Das erledigen bei WordPress sogenannte Caching-Plugins.

• WP Fastest Cache
  Meine bevorzugte Lösung bei der WordPress Suchmaschinenoptimierung ist WP Fastest Cache, das bereits in der kostenfreien Variante sehr gute Dienste leistet. Es arbeitet übrigens perfekt mit WP Smush zusammen.
  
  Die Einstellungen für das Plugin sind schnell gemacht:

Für mich haben sich die im Bild angezeigten Einstellungen bewährt. Sie minifizieren HTML-, CSS- und JavaScript-Dateien, indem sie Leerzeichen und Kommentare entfernen. Mehrere Skripte werden zu einer Datei zusammengefasst. Das spart Abfragen vom Server und reduziert damit die Ladezeit.

Einige Checkboxen sind ausgegraut. Diese Optionen gibt es nur in der kostenpflichtigen Pro-Variante.

• Autoptimize
  Daher ergänze ich die fehlenden Optionen häufig mit der kostenfreien Version von Autoptimize. Damit lässt sich beispielsweise Lazy Loading, das Nachladen von zunächst nicht sichtbaren Bildern aktivieren. Zudem lassen sich damit zuverlässig die bei vielen Themes standardmäßig geladenen Skripte für Google-Fonts und die WordPress-Emojis entfernen.
  
  Auch nicht unwichtig: Die Versionierung bei Skripten kannst du ebenfalls entfernen. Solche Skripte mit der Erweiterung „ver“ sperren sich oft gegen das Caching, was mit Anhaken dieser Checkbox vermieden wird.
  
  

Schritt 3: Testen, Testen, Testen

Sind die geänderten Bilder eingebaut und die Caching-Tools eingerichtet, dann testest du deine Website erneut. Nun sollte das Ergebnis deutlich besser ausfallen.

Wenn nicht, beginnt die Optimierungsschleife erneut.

Ich optimiere übrigens meist nur die Startseite und zusätzlich ausgewiesene Landingpages. Bei allen anderen Seiten achte ich darauf, dass die Bilder die optimale Größe haben. Die Skripte (Stylesheet und Javascript) sind bereits für die gesamte Seite im Browser-Cache.

Und wenn das Ergebnis bei GTmetrix für dich zufriedenstellend ist, kannst du auch noch einen Blick in Google-Insights werfen. Hier gibt es noch ein paar Zusatzinformationen. Andersherum kann ich nicht empfehlen. Da Google immer etwas zu meckern hat, ist hier der Frust nicht weit.

Viel Erfolg bei deiner WordPress Suchmaschinenoptimierung

Ich wünsche dir gutes Gelingen. Und schalte die „innere Perfektionistin“ einfach mal ab. Jeder Schritt in Richtung Ladezeit-Optimierung ist bereits ein Gewinn.

Wie hältst du es mit dem Update auf Gutenberg? Hast du die Installation der neuesten WordPress-Version bereits ohne Probleme erledigt? Prima, dann kannst du jetzt aufhören zu lesen. Für alle anderen habe ich mal meine Erfahrungen zusammengetragen:

Update jetzt – ja oder nein

Eine tolle Nachricht vorab: Wenn du dich noch nicht traust, kannst du noch eine Weile bei WordPress 4.9.9 bleiben. Hier wird es längere Zeit die nötigen Sicherheits-Updates geben. Irgendwann wirst du aber umstellen müssen, denn Gutenberg geht nicht mehr weg. Wenn du dich entschieden hast, das Update durchzuführen, solltest du auf diese Punkte achten.

Meine Checkliste für ein stressfreies Update auf Gutenberg:

1. Alle verwendeten Plugins darauf prüfen, ob sie mit Gutenberg arbeiten können. Bei nicht kostenpflichtigen Komponenten hilft das WordPress-Repository weiter. Die hier gelisteten Plugins sind darauf überprüft, ob sie bereits mit Gutenberg-Blöcken arbeiten.
2. Das Theme ebenfalls prüfen. Auch hier hilft das Verzeichnis weiter. Hast du dein Theme gekauft, solltest du bei der Entwicklerin oder dem Entwickler nachfragen. Ist das Theme für Gutenberg geeignet oder wenigstens eine Anpassung geplant ist?
3. Ein komplettes Backup – WordPress-Dateien und Datenbank – machen. Und zwar, bevor du an die Updates gehst.
4. Gutenberg ist kein Problem, weder für dein Theme noch für deine Plugins? Dann kannst du die neueste WordPress-Version installieren. Gutenberg ist ein Problem, dann installierst du dir den „Classic Editor“.

Den findest du ganz einfach, wenn du auf „Plugins -> installieren“ gehst. Am besten richtest du es ein, bevor du das WordPress-Update machst. Dann machst du zunächst alle Updates, die dir für Plugins und Theme angezeigt werden – erst dann folgt das Update auf WordPress 5.x.

Ab jetzt mit Gutenberg?

Herzlichen Glückwunsch, nun kannst du entweder wie gehabt weiterarbeiten oder du arbeitest ab jetzt mit Gutenberg. Da aller Anfang bekanntlich schwer ist, kann ich die Gutenberg-Fibel meiner WordPress-Kollegin Jessica Lyschik empfehlen.

Gut zu wissen: Der „Classic Editor“ bietet in den Einstellungen die Möglichkeit, beide Varianten zu nutzen – du kannst also auch weiterhin mit dem klassischen Editor arbeiten. Vor allem für alte Blog-Beiträge ist das hilfreich. Gutenberg selbst bietet aber auch die Möglichkeit der klassischen Ansicht: Dann wird dir der gesamte Inhalt in einem einzigen Block angezeigt. Allerdings kannst du deinen Beitrag dann nur eingeschränkt bearbeiten. Dann bleibst du besser beim klassischen Editor.

Was tun, wenn das Theme beim Update auf Gutenberg nicht mitmacht?

Wenn dein Theme nach dem Update nicht mehr mitspielen will, brauchst du möglicherweise ein neues. Schon jetzt findest du geeignete Themes, wenn du im WordPress-Repository den Filter auf „Block-Editor-Stile“ setzt. Sicher werden hier noch viele Angebote folgen. Nach meiner bisherigen Erfahrung sind aber alle Standard-Themes von WordPress für den Einsatz von Gutenberg gut geeignet. Am besten schaust du also vor der Installation in die Beschreibung deines Wunsch-Themes!

Obacht bei Page Buildern

Aufpassen musst du aber manchmal bei Themes, die einen Page Builder enthalten. Selbst getestet habe ich bereits die neuesten Versionen von „Enfold“ und „Divi“. Da ist der Page Builder bereits optimiert für Gutenberg. Nach meinen Recherchen können auch „Elementor“, „WP-Bakery“ und der „Beaver-Builder“ in den aktuellen Versionen mit dem neuen Editor umgehen

Letztlich liegt die Entscheidung bei dir: Gutenberg – ja oder nein? Auf deine Erfahrungen bin ich sehr gespannt. Schreib mir deine Meinung in die Kommentare.

Bild von Manuel Schäfer auf Pixabay

Umzug auf HTTPS in WordPress

WordPress umzustellen ist vergleichsweise trivial: In den Einstellungen die Domain ändern und dann in der Datenbank per SQL-Statement die Links umschreiben. Fertig!

UPDATE wp_posts SET guid = replace(guid, 'http://www.ihredomain.de','https://www.ihredomain.de');

UPDATE wp_posts SET post_content = replace(post_content, 'http://www.ihredomain.de', 'https://www.ihredomain.de');

UPDATE wp_postmeta SET meta_value = replace(meta_value,'http://www.ihredomain.de','https://www.ihredomain.de');

Fertig? Leider nicht, denn jetzt geht die Arbeit erst richtig los: Es wurden beim Umzug auf HTTPS nicht alle Links erfasst und das bedeutete, dass ich die Stellen ausfindig machen musste, an denen noch http-Links stehen. Das konnten beispielsweise Einträge in einem Text-Widget, der Pfad zu Logo und Favicon oder von Plugins gesetzte URLs sein. Puh, diese Suche konnte langwierig werden – und wurde es auch.

Für die Anzeige des grünes Schlosses darf es keine Vermischung von verschlüsselten und unverschlüsselten Inhalten geben. Bisher gab es lediglich ein graues Schloss mit einem Warndreieck, was sehr ungünstig ist. Moderne Browser weisen den Besucher einer Webseite ausdrücklich darauf hin, dass hier unter dem Label einer verschlüsselten Seite auch unverschlüsselte Inhalte zu finden sind. Das wirkt eher abschreckend als vertrauenserweckend.

VG-Wort Zählpixel

Beim Umzug auf HTTPS habe ich mir in der Website einer Netzwerkkollegin einen Wolf gesucht. Sie verwendet nämlich den von der VG-Wort zur Verfügung gestellten Zählpixel – ein 1×1 Pixel großes Bild (img), dessen Pfad normalerweise mit http ausgezeichnet ist. Das winzige Element zeigte sich erst nach ausgiebiger Inspektion des Quellcodes. Es gibt aber auch einen verschlüsselten Server bei der VG-Wort: Der Domain-Pfad vor der Zähl-ID muss dann zwingend https://ssl-vg03.met.vgwort.de/na/ lauten. Im Blog von Daniel Weihmann habe ich eine hilfreiche Anleitung dazu gefunden.

So aufgeschlaut stellte ich dann fest, dass in dem von mir irgendwann mal eingerichteten Plugin Prosodia VGW eine Einstellung existiert, mit der ich auf den oben genannten https-Server umstellen konnte. Diese Aktion erfasst dann gleich alle genutzten Zählpixel und stellt den Pfad um – sehr hilfreich!
Und jetzt war es endlich geschafft, das Schloss war grün.

301-Redirect für Google & Co.

Um Suchmaschinen von der Umstellung zu informieren, empfiehlt sich dann noch den 301-Redirect (dauerhaft umgezogen) in die .htaccess-Datei zu schreiben. Den passenden Codeschnipsel und weitere nützliche Informationen zum Thema fand ich in einem Artikel bei ambranet.de. Wer die Webmastertools von Google nutzt, sollte nun auch zwei Einträge mit https hinzufügen – einen mit einen ohne www. Der Verifizierungscode wird dabei automatisch erkannt. Die XML-Sitemap sollte man aktualisieren und dann in die neuen Einträge hochladen. Und dann heißt es nur noch auf die Indizierung warten!
Für Google-Analytics muss die geänderte Domain ebenfalls eingetragen werden. Im Fall einer Komplettumstellung ist das sehr einfach, in den Einstellungen muss nur die Standard-URL umgestellt werden. Alles super, oder?

Keine Facebook-Likes mehr nach dem Umzug auf HTTPS

Leider nicht! Facebook fand die Umstellungsaktion gar nicht lustig, alle Likes waren futsch, die Arbeit von Jahren hin. Für meine Kollegin eine Katastrophe. HTTP ist nämlich nicht gleich HTTPS. Diese URLs werden wie unterschiedliche Domains betrachtet.

Im Web habe ich dazu leider nicht viel gefunden – und in dem wenigen gingen die Meinungen auch noch auseinander, ob Facebook Likes und Shares überträgt oder nicht. Erst mal waren sie definitiv nicht mehr da. Ein 301-Redirect ist dafür auch nicht die Lösung. Facebook transferiert Likes nur auf die neue Seite, wenn die alte noch erreichbar ist. Der empfohlene Redirect verhindert aber deren Erreichbarkeit.
Nach längerer Suche fand ich im Forum von Stackoverflow doch eine Lösung: Ein zusätzlicher Eintrag in der .htaccess nimmt den Facebot von der Umleitung aus. Der Eintrag sieht dann wie folgt aus:

RewriteCond %{HTTPS} off
RewriteCond %{HTTP_USER_AGENT} !(Facebot|facebookexternalhit/1.1) [NC]
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
RewriteCond %{HTTP_HOST} !^www\.
RewriteCond %{HTTP_USER_AGENT} !(Facebot|facebookexternalhit/1.1) [NC]
RewriteRule ^(.*)$ https://www.%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Open Graph-Angaben anpassen

Das ist leider noch nicht alles: Denn Facebook benötigt auch noch die Angabe der alten URL in den Open Graph-Angaben. Da SEO-Plugins diese Angaben automatisch aus der für WordPress eingetragenen Domain generieren, muss per Hand die og:url im Meta-Tag mit http angegeben werden. Damit der Eintrag jeweils automatisch den Deep-Link berücksichtigt, muss das in der header.php von WordPress entsprechend angegeben werden.

Obacht: Mit the_permalink() kommt man hier nicht zum Ziel, denn damit würde die komplette neue URL, also die mit https ausgegeben. Der Server-Request dagegen fragt nur den Teil ab, der hinter dem Domainnamen steht.

<meta property="og:url" content="http://www.ihredomain.de<?php echo $_SERVER['REQUEST_URI']; ?>" />

Ein Blick in den Facebook-Debugger zeigte jetzt: Alles im grünen Bereich. Die übrigen Angaben für Open Graph müssen nun allerdings ebenfalls händisch gesetzt werden, denn die Nutzung eines SEO-Plugins für die Social Meta-Angaben ist ja nicht möglich.
Wichtig: Sollen die Einträge dynamisch sein, muss man sie mit den Mitteln von WordPress erstellen – was nicht gerade trivial ist, wenn man sich nicht mit Filtern und Hooks auskennt. Die Beschreibung der Vorgehensweise wäre dann schon wieder ein eigener Beitrag.

Puh, jetzt läuft erst mal alles. Aber vielleicht habt ihr Verbesserungsvorschläge oder weiterführende Hinweise? Dann freue ich mich auf einen Kommentar :-).

Bildquelle: Pixabay

Und jetzt?

In der Datei „gad-admin-options.php“ im Verzeichnis des Plugins findet sich ab Zeile 33 folgender Code:

 if( !is_admin() ){
     die( "Please open this page in the Admin panel only." );
 }

Mit „die“ steigt das Plugin aus, der Rest wird nicht mehr ausgeführt. Das betrifft dann aber leider nicht nur das Plugin, denn die so genutzte Funktion „is_admin()“ legt die Frontansicht komplett lahm.

Die einfachste Lösung, die ich im Forum fand: Die Zeile mit „die“ einfach auskommentieren (mit „//“). Habe ich gemacht und die Webseite war wieder da. So weit, so gut. Ich würde mich allerdings freuen, wenn die Macher für das Plugin bald einen Fix herausbringen. Nicht jeder Nutzer hantiert gern im Quellcode seiner Plugins und empfehlen kann man diese Vorgehensweise ohnehin nicht.

Nachtrag am 30.7.2014:

Heute gab es ein Update auf Version 2.1.1. Leider steht nichts dazu im Changelog. Ach ja: So funktioniert alles wieder :-).