Ist dir als Stammleser etwas auf meinem Blog aufgefallen? Irgendwie sieht der Blog anders aus und doch auch wieder nicht, richtig? Was da genau passiert ist, warum und wie ich meinen Blog unter der Haube und quasi über Nacht komplett generalüberholt habe, erfährst du in diesem Artikel.

Der Auslöser

Wie das fast immer so ist – erst wenn ein Problem da ist, wird der Schmerz groß genug, um bestimmte Dinge, die man gern vor sich herschiebt, tatsächlich zu realisieren. Mir geht das jedenfalls ganz gern mal so. In meinem konkreten Fall waren das plötzlich auftretende Performance Probleme in Kombination mit der Tatsache, dass Leser plötzlich keine Kommentare mehr auf meinem Blog hinterlassen konnten. Mitbekommen habe ich das auch nur durch befreundete Blogger, die mir eine Nachricht geschrieben haben. Erreicht haben mich die Nachrichten natürlich gerade, als ich unterwegs war. Perfekt. Oder eben auch nicht.

Sobald es mir möglich war, bin ich also auf Spurensuche gegangen, habe Plugins deaktiviert, aktiviert oder getauscht – aber irgendwie wurden die Probleme dadurch nur größer. Und was das Schlimmste an allem war – ich habe die Änderungen on the fly auf dem Blog vorgenommen.

Die Gefahr, dabei etwas komplett zu zerschießen, war entsprechend groß.

Genau in dem Moment habe ich einen radikalen, längst überfälligen Entschluss gefasst. Ein neues Theme muss her, der Blog muss auf PHP7 umgezogen werden, Plugins und Wordpress Installation müssen komplett auf den aktuellsten Stand gehoben werden. Denn vor allem letzteres ist seit langem (über)fällig.

Du fragst dich, warum ich nicht alles up-to-date habe?

Nun, ganz einfach. Ich habe am Anfang meines Blogs eine Entscheidung getroffen, die im Nachhinein betrachtet, dumm war. Ich habe mir ein schickes Theme gesucht, gekauft und installiert. Und wie das so ist, wenn man selbst Software Entwickler ist – habe ich mal hier, mal da im Code rumgefummelt, CSS und PHP Files angepasst – und das alles natürlich, ohne ein Child Theme zu verwenden. Dass es so etwas gibt, wusste ich damals nicht.

Updates auf das Theme gab es nur sehr selten und durch meine Änderungen habe ich darauf natürlich verzichtet. Zumindest ab dem 2. Update. Denn das erste, noch durchgeführte Update hat mir natürlich alle meine Änderungen zerschossen gehabt. Die habe ich dann von Hand wieder aufwendig nach implementiert.

Plugins dagegen hielt ich immer aktuell. Die Wordpress Version dagegen habe ich bis auf kritische Sicherheits-Updates ebenfalls unberührt gelassen. Auch das – ein Fehler. Zu groß war aber einfach die Angst, dass ich dadurch wieder mein Layout zerschieße, Plugins nicht mehr funktionieren oder das Theme gar nicht mehr läuft.

Nach einem Jahr dann der nächste Hammer – mein schönes Theme bekam gar keine Updates mehr, weil mein einjähriger Support abgelaufen war. Die Verlängerung hätte mich erneut eine Stange Geld gekostet, die ich auszugeben einfach nicht bereit war.

Jedes Jahr aufs Neue für Updates bezahlen?

Nein, danke!

Das Ende vom Lied ist: ich hänge seit Monaten immer weiter mit meiner Wordpress Version hinterher und Plugins bekommen immer mal wieder merkwürdige Probleme, deren Lösung mich wertvolle Zeit kostet.

Damit musste Schluss sein.

Sofort!

Aber wie?

Testumgebung aufsetzen!

Den Blog 2 Wochen vom Netz nehmen? Das kam nicht in Frage. Nicht mal eine Stunde wollte ich ihn offline sehen. Drum bin ich das ganze Thema nun konsequent und grundlegend anders angegangen.

Es wurde höchste Zeit!

Ich habe mir als erstes eine Testumgebung aufgesetzt.

Folgende Schritte waren dafür nötig:

Erstellen einer neuen Subdomain für meine Testumgebung

Das geht bei meinem Provider 1und1 sehr einfach über die Domainverwaltung des Control Centers. Die neue Subdomain ist nach wenigen Minuten eingerichtet.

subdomain-anlegen-1und1-control-center

Dieser habe ich einen neuen Webspace Ordner zugeordnet. Beispielhaft nenne ich die Subdomain nachfolgend einfach mal dev.erkunde-die-welt.de – auch wenn ich real dafür einen anderen Namen verwendet habe.

Hinweis: Je mehr Informationen du über Plugins, Installationen, Versionen oder Pfade deines Blogs Preis gibst, desto einfacher machst du es möglichen Hackern. Dem entsprechend sind alle Pfadangaben, Bezeichner und Ähnliches in diesem Artikel natürlich fiktiv!

Neue Datenbank anlegen

Schritt 2 bestand im Anlegen einer neuen Datenbank. Zunächst habe ich dafür die gleiche, alte PHP Version (5.6) verwendet, die auch meinem Live Blog zugrunde liegt. Das geht bei 1und1 im Control Center unter MySQL-Datenbank. User, DB Name und Passwort habe ich mir entsprechend notiert.

mysql-datenbank-anlegen-1und1-control-center

Original Datenbank exportieren

Als nächstes habe ich mir das Plugin WP Migrate DB gesucht und installiert. Mit diesem habe ich einen Export meiner Datenbank erstellt. Das Tolle an dem Plugin – man kann beim Export bereits entsprechende Pfade ändern. Ich habe also den aktuellen Webspace Ordner durch den neu angelegten ersetzt und den Pfad meines Blogs von //www.erkunde-die-welt.de auf //dev.erkunde-die-welt.de geändert.

wp-migrate-db-datenbank-exportieren

Den kryptischen Pfad /homepages/… findest du bei 1&1 übrigens über das Control Center > Domains in den erweiterten Einstellungen deiner Webseite (Hauptverzeichnis Webspace).

Diesen Datenbank Export in Form eines gezippten SQL Files habe ich über phpMyAdmin in meine neue DB importiert. Den phpMyAdmin Client findest du im Control Center, indem du über MySQL-Datenbank gehst und dann in der Zeile der entsprechenden Datenbank auf den Button in der rechten Spalte klickst.

phpmyadmin-1und1-control-center

Blog spiegeln

Nun fehlte mir nur noch eine Kopie meines Blogs. Mittels FTP Client habe ich alle Dateien meines Original Blogs zunächst auf meine lokale Festplatte heruntergeladen (das dauert schon mal etwas länger) und von dort habe ich sie dann wieder in das neue Verzeichnis meiner Testumgebung hochgeladen.

Hinweis: Du kannst natürlich auch ein aktuelles Backup verwenden. Ich wollte aber sichergehen, dass ich erstens wirklich alles aktuell kopiere und zweitens nicht versehentlich die Dateien meines Blogs verschiebe, statt sie zu kopieren.

Um nun den gespiegelten Blog mit der neuen DB zu verbinden muss noch das wp-config.php File im Verzeichnis der Testumgebung angepasst werden. Dazu änderte ich die lokal vorliegende Kopie dahingehend ab, dass ich die neuen, zuvor notierten Datenbank-Daten eingetragen habe. Außerdem habe ich noch den Debug Mode mit folgender Zeile aktiviert:

define(‚WP_DEBUG‘, true);

Da mein Blog CloudFlare als CDN (Content Delivery Network) verwendet und ich dieses natürlich auch in der Testumgebung aktiv haben möchte, musste ich nun noch die neue Subdomain unter 1&1 CDN für mehr Performance im Control Center im CDN Paket mit angeben. Dazu ist einfach nur der entsprechende Haken bei der bereits aufgeführten, neuen Subdomain unter „Alle Einstellungen“ > „Subdomain zuweisen“ zu setzen.

SSL auch für Testumgebung einrichten

Soweit so gut. Wenn ich kein SSL verwenden würde, wäre ich nun fast fertig gewesen. So jedoch musste ich auch für meine Subdomain noch ein SSL Zertifikat anlegen. Schließlich möchte ich ja, dass meine Testumgebung exakt genauso wie mein Live Blog funktioniert. Gerade im Zusammenspiel zwischen Caching Plugin, SSL, CDN und anderen Plugins habe ich immer wieder Probleme gehabt. Eine abweichende Testumgebung ohne SSL, hätte für mich daher nicht viel Wert gehabt – ganz abgesehen davon, dass diverse Pfade auch noch hätten angepasst werden müssen (http:// versus https://).

Leider deckte mein bisher verwendeten SSL Starter Zertifikat bei 1&1 nur meine Hauptdomain ab. Ich habe also ein neues SSL Starter Plus Zertifikat bestellt, gekauft und mit dem meiner Hauptdomain getauscht. Das frei gewordene SSL Starter Zertifikat habe ich einfach für eine andere Domain verwendet. Das Schöne am SSL Starter Plus ist, es gilt auch für alle Subdomains! Genau, was ich brauchte!

ssl-zertifikat-anlegen-1und1-control-center

Und siehe da, nach Hochladen des geänderten PHP Files war meine Testumgebung unter https://dev.erkunde-die-welt.de erreichbar. Ich hatte nun eine exakte Kopie meines Blogs, in der ich beliebig Dinge ausprobieren kann, ohne dass ich meinen Live Blog offline nehmen muss.

Endlich!

Eine Kleinigkeit fehlte jetzt aber trotzdem noch – das Einrichten eines htaccess Verzeichnisschutzes. Er ist wichtig, um sicherzustellen, dass niemand ohne entsprechende Zugriffsrechte auf die Testumgebung gelangen kann. Dafür habe ich die lokal vorhandene .htaccess Datei angepasst, indem ich folgende Zeilen an den Anfang gestellt habe:

# Start Verzeichnisschutz
AuthName „Entwicklung“
AuthType Basic
AuthUserFile /kunden/homepages/42/d12345678/htdocs/EDWDEV/.htpasswd
require user mein_user_name
# Ende Verzeichnisschutz

Ferner habe ich mittels dieses Generators eine verschlüsselte Zeile Code erzeugt, die einen von mir definierten User nebst zugehörigem Passwort erhält.

mein_user_name:$apr1$42vnfroa$Cse6jRYBisB2ehteomwOu/

Genau dieser User ist ins .htaccess einzutragen. Meine generierte Zeile Code habe ich als Datei mit dem Namen .htpasswd gespeichert. Beide Dateien habe ich dann in die Testumgebung ins Root Verzeichnis hochgeladen.

Und siehe da, der Zugriff zur Testumgebung ist nun nur noch nach Eingabe des Users nebst Passwort möglich. Alle anderen – inklusive Bots, Robots und Crawler – sind damit ausgesperrt!

Sicherheitshalber habe ich trotzdem noch in der Testumgebung die gesamte Webseite auf NoIndex gesetzt – denn dublicated Code, der meine Rankings negativ beeinflusst, ist natürlich das Letzte, was ich brauchen kann.

Den Blog updaten

Jetzt begann die eigentliche Arbeit, um dem Blog das Facelifting zu verpassen, das ich im Sinn hatte.

Hinweis: Alle folgenden Schritte finden natürlich auf der Testumgebung statt. Der Live Blog bleibt unberührt und unverändert. Vorerst!

Ich habe mir ein Theme gesucht, das seit Jahren etabliert ist, Updates zeitlich unbegrenzt zur Verfügung stellt und mir alle Features bietet, die ich brauche. Entschieden habe ich mich für das komplexe Avada Theme von ThemeFusion. Auch das ist ein Premium Theme, aber eines, das gut dokumentiert, sehr häufig verkauft und eingesetzt ist und das auch noch einen riesigen Feature-Umfang bei gleichzeitigem Fokus auf Performance besitzt. Das Theme zu kaufen und zu installieren war eine Sache von einer Minute.

avada-theme-wordpress

Wordpress nebst Plugins updaten

Bevor ich nun aber anfing, mein vorheriges Layout nachzubauen, wollte ich erst einmal wissen, ob denn das Updaten auf die aktuellste Wordpress Version gelingt.

Folgende Schritte folgten daher:

  1. Updates aller vorhandenen Plugins auf die aktuellste Version.
  2. Update von Wordpress auf die aktuellste Version.

Zu meinem Erstaunen klappte das hervorragend und ohne Konflikte. Dadurch ermutigt habe ich auch die Datenbank der Testumgebung in den PHP-Einstellungen im 1&1 Control Center direkt auf PHP7 umgestellt. Auch das funktionierte, produzierte jedoch Einiges an Debug Ausgaben durch deprecated Code in den PHP Dateien einiger verwendeter Plugins.

Hinweis: Diese Debug Ausgaben siehst du im Normalbetrieb nicht. Sie schaden auch in der Regel nicht, solange es nur Notices oder Warnings sind. Fehler jedoch sollten zwingend beseitigt werden. Besser ist es natürlich, auch die Warnings in den Griff zu bekommen.

Nun kam der nächste logische Schritt – Hausputz in den Plugin Liste. Ganze 14 Plugins konnte ich komplett wegwerfen, weil Avada diese Funktionalitäten bereits abdeckt! Zusätzlich kam auch das WP Google Maps Plugin auf den Index – zu oft hat mir das schon in der Vergangenheit Probleme mit JQuery und im Zusammenspiel mit anderen Plugins beschert. Avada selbst beinhaltet ohnehin eine Google Maps Integration – allerdings werde ich auch diese aus zuvor genannten Gründen nicht nutzen. Die 35 Shortcodes aus den betroffenen Artikeln zu entfernen, kostete etwas Zeit, ging aber recht flott. Eigentlich war ich ein großer Freund von eingebundenen Google Maps Karten – aber künftig möchte ich auf die diversen technischen Schwierigkeiten, die ich damit immer wieder hatte einfach verzichten!

Es blieben 2 Plugins, die noch deprecated Code beinhalteten. Diese habe ich durch ähnliche Plugins ersetzt.

Außerdem habe ich noch das Cache Plugin von W3 Total Cache auf WP Rocket gewechselt. Ersteres war zwar in meiner Umgebung schneller, aber auch deutlich komplexer und schwieriger einzustellen. Außerdem hat es sehr sensibel auf Plugin-Änderungen reagiert und da immer wieder Wartungsaufwand produziert.

Weil das Minify von CSS und JS immer wieder zu Layout Problemen bei Plugin Updates etc. geführt hat, habe ich ferner beschlossen, darauf künftig im Caching Plugin zu verzichten.

Lieber verzichte ich auf ein wenig Performance, bin dabei aber auf der sicheren Seite, was Funktionalität und Layout betrifft. Denn mein anfangs beschriebenes Problem mit den Kommentaren stellte sich nach intensiver Analyse auch wieder als Minify Problem heraus. Da ich aber ohnehin das CDN  CloudFlare verwende – kann ich auf diesen kleinen zusätzlichen Boost guten Gewissens verzichten.

Hat ohnehin nur viel Arbeit gemacht.

Warum?

Nun, wenn du das richtig machst, dann lässt du beispielsweise alle CSS Dateien über Minify zusammenfassen und dann asynchron beim Seitenaufbau laden. Allerdings musst du vorher die CSS Skriptanteile herausfinden, die zwingend vor Anzeige deiner Seite geladen sein müssen, damit das Layout keine Fehler zeigt.

Dafür gibt es entsprechende Tools im Netz. Das Problem – immer wenn du ein Plugin aktualisierst, musst du das theoretisch wiederholen. Und wenn du dabei nicht sehr sorgfältig vorgehst, dann passiert dir eben genau das, was auch mir passiert ist – irgendwann kommt es einfach zu Konflikten und Fehlfunktionen.

Die Arbeit möchte ich mir in Zukunft ersparen!

Meiner Erfahrung nach tritt das übrigens verstärkt in Kombination mit einem CDN auf. Für Javascript Dateien gilt Ähnliches.

Soweit so gut.

Alle Debug Meldungen waren nun verschwunden. Ich hatte nun also einen Blog mit dem aktuellsten Wordpress, einem modernen, neuen Theme, aktuellen Plugins und einer PHP7 Installation im Hintergrund. Nur der Blog sah natürlich noch komplett verändert und zerschossen aus.

Avada Theme konfigurieren

Was nun folgte, war eine Nachtschicht, in der ich Schritt für Schritt das Aussehen meines Live Blogs nachbaute und das Avada Theme entsprechend anpasste. Das war ein gutes Stück Arbeit, die sich aber lohnte. Mein geliebtes Layout inklusive gewohnten Farben etc. wollte ich natürlich behalten – allein schon aus dem Grund der Wiedererkennung.

Und ich denke, das ist mir ganz gut gelungen. Was meinst du?

Was ich dabei schnell lernte – Avada ist genial! Das Theme bietet allein schon durch die Integration mit Fusion Slidern und all seinen anderen Features eine völlig neue Welt an Möglichkeiten zur Gestaltung von Beiträgen und Seiten. Vorhandene Seiten anzupassen, zu verbessern geht intuitiv und schnell.

Ergo habe ich bei der Gelegenheit auch die ein oder andere Unschönheit, die mich schon immer geärgert hat, angepackt. Manche Seite ist ganz verschwunden, andere wurden fix überarbeitet. Ich habe außerdem auf besser lesbare und größere Fonts umgestellt und auch die Breite des Blog-Bereiches leicht erhöht. Vielleicht wechsel ich irgendwann auch auf ein Full Width Layout – all das ist jetzt sehr einfach für mich realisierbar.

Ich bin mir absolut sicher, dass ich meinen Blog dadurch über Jahre hinaus sehr zukunftssicher, modern und frisch gestalten kann.

Und das Beste: jetzt war wieder alles nicht nur up-to-date, sondern anhand entsprechender Messungen bestätigte sich auch eine weitere, insgeheim gehegte Hoffnung – mein Blog gewinnt deutlich an Geschwindigkeit! Rund 100-150% schneller erfolgte nun das Laden der Seiten, die ich üblicherweise für solche Tests verwende. Klasse!

Der einzige Haken – das galt bis jetzt natürlich nur für die Testumgebung.

Go Live

Die Änderungen mussten also nun noch live gehen. Ich wusste ja jetzt, was zu tun ist, dass alles funktionierte und wie ich vorgehen musste.

Folgendes Schritte unternahm ich also zur Vorbereitung des Go Live:

Mit WP Migrate DB habe ich nun erneut die Datenbank – dieses Mal der Testumgebung – exportiert. Die Pfade habe ich natürlich entsprechend nun umgekehrt. Außerdem habe ich alle vorgenommenen Custom CSS Code Schnipsel gesichert, ein Backup der Testumgebung gezogen und die Einstellungen des Avada Themes abgespeichert.

Sicher ist sicher, dachte ich mir!

Dann habe ich eine neue MySQL Datenbank angelegt für den Live Blog und hier nun die exportierte Datenbank der Testumgebung importiert. Die bisher benutzte Datenbank ließ ich unberührt, um im Notfall darauf zurückwechseln zu können.

Via FTP habe ich das Avada Theme schon mal an die richtige Stelle in der Live Umgebung kopiert, so dass ich es nur noch im Admin Bereich des Blogs später aktivieren musste.

Das Go Live habe ich dann sehr früh morgens (ich stand um halb 5 auf!) innerhalb einer halben Stunde durchziehen können!

Vorgenommene Schritte:

  1. Maintenance Mode im Live Blog aktiviert (Plugin: Maintenance).
  2. Alle Plugins, die noch im Testblog aktiviert waren, ebenfalls aktiviert. Rest deaktiviert.
  3. Alle Plugins aktualisiert.
  4. Wordpress geupdated.
  5. Avada Theme aktiviert.
  6. In der wp-config.php des Liveblogs auf die neue Datenbank verwiesen.
  7. Maintenance Mode im Live Blog deaktiviert.

Fertig!

Die als Backup angelegten css Änderungen, Theme Einstellungen etc. hat es gar nicht mehr gebraucht – denn klar, die liegen ja auch in der Datenbank, welche ich bereits komplett exportiert und wieder importiert hatte.

Was nun folgte, war noch ein wenig Feinschliff. Nach und nach entdeckte ich noch Kleinigkeiten am Blog, die noch nicht perfekt saßen oder die ich durch die neuen Möglichkeiten durch das Avada Theme sehr viel besser und einfacher gestalten konnte.

Bis zum Frühstück war aber auch das alles erledigt!

Fazit

Zukünftig kann ich nun auch weiterhin immer erst alle notwendigen Änderungen und Updates auf der Testumgebung, die quasi eine 1:1 Kopie meines Blogs ist, ausprobieren. Sobald ich weiß, was funktioniert und was zu tun ist, übernehme ich diese Änderungen dann einfach und ohne Risiko auf dem Live Blog. Updates für Wordpress, Plugins und das Theme werden nun immer sofort eingespielt. Theme Änderungen habe ich nur noch über Einstellungen oder Custom CSS vorgenommen, so dass mir ein Update nichts mehr zerschießen kann, was nicht leicht zu reparieren ist. Im Notfall kann ich auch jederzeit schnell wieder eine frische 1:1 Kopie des Blogs ziehen und in die Testumgebung einspielen.

Sicheren Wordpress Updates ohne Risiko und böse Überraschungen steht nun nie mehr etwas im Weg! Und meine Google Rankings werden durch die schnelleren Ladezeiten und die aktuellen Versionen von Wordpress nebst Plugins sicher auch positiv beeinflusst werden.

Sicherheit First!

Und um dem nun noch das i-Tüpfelchen aufzusetzen und die Sicherheit meines Blogs weiter zu erhöhen, habe ich zusätzlich zu dem bereits zuvor von mir verwendeten WP Hide Login, das den Standard Login Pfad umbiegt, noch das Clef Plugin mit seiner 2 stufigen, sehr einfach zu nutzenden Authentifizierung eingeführt. Dieses macht mein Smartphone zum Schlüssel für Logins. Ein Passwort ist nicht mehr notwendig! Es ist aktuell die vielleicht sicherste Login Variante! Die Einrichtung dauert keine 30 Sekunden!

Update 19.03.17: Leider hat das Team von CLEF inzwischen bekanntgegeben, das Plugin nicht weiter zu supporten. Das ist extrem schade!

So ist mein Blog nun auch gegen Brute Force Attacken und ähnlichen Hacking Versuchen, von denen ich in letzter Zeit immer mehr in der Blogger Community höre, komplett immun!

Automatisierte Backups des Blogs und der Datenbank laufen parallel aber natürlich auch noch (Plugin: BackWPub).

Ich bin grad echt happy. Mein Blog wird zwar erst Anfang 2017 zwei Jahre alt, aber Erkunde-die-Welt.de 2.0 beginnt damit schon heute.

I like that!

Zusammenfassung & Tipps

Das Ganze war jetzt in Teilen recht technisch und sehr auf meinen bei 1&1 gehosteten Blog bezogen. Die gleichen Schritte kannst du aber sicherlich auch auf ähnliche Art und Weise bei jedem anderen Webhoster durchführen. Zusammenfassend hier noch einmal die wichtigsten Erkenntnisse, die du aus meinem Artikel mitnehmen solltest:

  • Benutze ein Theme, das entweder kostenlos ist oder in der Premiumvariante zumindest nicht jährlich für Updates bezahlt werden muss.
  • Halte Plugins, Theme und Wordpress Version immer auf dem aktuellsten Stand, um Sicherheit und Funktionieren deines Blogs zu gewährleisten.
  • Lege dir eine Testumgebung an, die die gleichen technischen Bedingungen wie dein Live Blog besitzt und auf der du Updates, neue Plugins und andere technische Änderungen immer zuerst testen kannst, bevor du sie auf deinem Live Blog übernimmst.
  • Mache deinen Blog sicherer, indem du den Standard-Login Pfad umbiegst und möglichst eine Zwei-Faktor-Authentifizierung benutzt (Google Authentifizierung, CLEF etc).
  • Nützliche Plugins für Sicherheit, Wartung & Verwaltung deines Blogs:
  • Achte bei Plugins darauf, dass sie regelmäßig geupdated werden, gute Bewertungen haben und auf vielen Seiten bereits eingesetzt werden.

Wie wichtig ist dir Sicherheit für dein Blog? Hattest du schon mal Problemen mit Updates oder wurdest gar gehackt? Erzähl mir davon!

Update 12.12.2016:

Erst später habe ich bemerkt, dass, um PHP 7 wirklich effizient zu nutzen, noch der OPcache konfiguriert werden muss. Informationen dazu habe ich hier gefunden. Ich musste einfach nur noch den .opcache Ordner anlegen und die entsprechenden Befehle in der php.ini hinzufügen. Das gab dann noch einmal einen richtigen Boost!