Unser Blog wird heute acht Jahre alt und unsere neue Webseite ist auch schon seit einem Jahr online. Für uns ist damals ein lang gehegter Wunsch in Erfüllung gegangen. Höchste Zeit also die Geschichte dahinter zu erzählen.
Unsere Blogbeiträge haben wir damals natürlich von der alten Seite mitgenommen - aber sonst ist alles neu. Layout und Logo sind komplett neu gestaltet und wir nutzen das Content Management System Statamic um unsere Inhalte zu publizieren. Die vorherige Webseite hatte uns sieben Jahre lang begleitet, sie basierte auf WordPress als Content Management System und einem Layout von Elegant Themes.
Abgesehen von ein paar kleinen Anpassungen am Layout und etwas SEO-Optimierung hatte unser Web-Auftritt über all die Jahre in etwa gleich ausgesehen. Im Kontext des Internets ist das natürlich eine kleine Ewigkeit und alles andere als optimal. Denn das Web entwickelt sich rasend schnell weiter und die Herausforderungen eine Webseite zu betreiben sind immer komplexer geworden. Zudem haben sich auch unsere eigenen Anforderungen über die Jahre hinweg gewandelt. Zu Anfang haben wir mit unserer Seite den Einbau einer Wasserkühlung in einen PC dokumentiert - und heute schreiben wir (zum Teil sehr lange) Artikel zu einer Vielzahl von Themen.
Was wir verändern wollten
Wir waren mit der alten Webseite an einen Punkt gekommen, an dem es nicht mehr damit damit getan war, die alte Seite irgendwie zu modernisieren. Wir wollten eine komplett neue Webseite in Angriff nehmen. Denn schlussendlich konnten wir nur auf diesem Weg unsere gewünschten Veränderungen in die Tat umsetzen.
Aus technischer Sicht stand dabei unser Wunsch, WordPress durch ein anderes Content Management System abzulösen, im Zentrum. Warum das für uns so zentral war, erklären wir Euch im nächsten Kapitel ausführlich.
Aus inhaltlicher Sicht wollten ebenfalls wir ein paar grundlegende Dinge weiterentwickeln. Wir wollten weg vom klassischen Blog-Feed auf dem die alte Seite aufgebaut war. Zur Erinnerung haben wir nochmals einen Screenshot eingefügt.
Unser Ziel war es, Beiträge auch thematisch als Serie oder Projekt zu gruppieren und Inhalte auch zweisprachig publizieren können. Blogbeiträge, die wir länger gut sichtbar für den Leser auf der Frontseite halten wollten, mussten wir auf der alten Seite in der rechten Spalte unterbringen. Auch unser "Bild des Tages" konnten wir immer nur in Briefmarkengrösse dort anzeigen. Um dies aufzubrechen wollten wir neu eine Frontseite mit Teasern, bei denen wir selber bestimmten konnten, welche Themen wo platziert sind. Serien, Projekte und die Rubrik "Bild des Tages" sollten zudem ihren festen Platz auf der Frontseite bekommen.
Dafür brauchten wir ein Layout, welches genau diese neue Content Präsentation umsetzt und nicht nach WordPress mit allen Standard-Elementen eines Blogs oder nach einer eingekauften Template-Vorlage aussah. Es sollte ansprechend wirken, hell und offen sein und ein angenehmes Schriftbild haben um auch längere Texte problemlos lesen zu können. Als Verbesserung gegenüber der alten Webseite sollte es zudem "responsive" sein, also für Smartphones und Tablets geeignet sein, da ein grosser Teil der Internetnutzer heute Mobil-Geräte benutzt, um online zu gehen.
Daher brauchten wir ein Logo, das in verschiedenen Grössen dargestellt werden konnte, denn das alte existierte nur als Bild in einer fixen Grösse. Technisch ausgedrückt hiess dies, das neue Logo sollte als Vektorgrafik vorhanden sein. Unten seht ihr eine direkte Gegenüberstellung von alten Schriftzug und der neuen Kombination aus Logo und Schriftzug. Die Zweifarbigkeit und Rot als Hauptfarbe im Wort "Hitzestau" haben wir beibehalten, um einen gewissen Wiedererkennungswert zu haben.
Die neue Kombination von Logo und Schriftzug passt auch besser, wenn es eher in quadratischer Form dargestellt werden soll. Dann lassen sich HS und der Schriftzug einfach untereinander anordnen. Zudem kann das HS auch separat verwendet werden, zum Beispiel als Icon oder Avatar.
In diesem Kapitel wollen wir nun wie angekündigt etwas detaillierter auf das Thema Content Management System eingehen. Danach geht es dann weiter mit der Umsetzung der neuen Webseite und der Migration der bestehenden Blogbeiträge.
Zu Beginn unserer Planung hatten wir uns natürlich auch überlegt, bei WordPress zu bleiben und einfach unser altes Theme namens Polished von Elegant Themes durch ein anderes Template auszutauschen, um ein neues Layout zu haben. Aber nur schon das wäre viel komplizierter und aufwendiger zum umsetzen gewesen, als es klingt. Denn unser altes Template enthielt spezielle Zusatzfeatures, welche über die WordPress-eigenen Funktionen hinausgingen. Mit einem Template-Wechsel wären diese verloren gegangen, was das Konzept unserer Seite auf den Kopf gestellt hätte. Als Erkenntnis aus diesen Überlegungen nehmen wir mit, dass ein WordPress-Template mit speziellen Zusatzfeatures immer auch eine "Fussfessel" ist, weil ein späterer Wechsel nicht mehr so ohne weiteres machbar ist.
Ein etwas anderer Ansatz, aber immer noch mit WordPress, bot sich mit Divi an. Bei der ebenfalls von Elegant Themes entwickelten Lösung handelt es nicht um ein einfaches WordPress-Theme, sondern es ist ein komplettes Framework um Layouts und Seiten zu bauen.
Wir haben eine Testinstallation eingerichtet und als erstes festgestellt, dass die Einarbeitungszeit recht hoch ist, da das Arbeiten mit Divi alles andere als selbsterklärend war. Zudem wäre auch nicht möglich gewesen, unsere bestehende Datenbank mit den vorhandenen Blogbeiträgen zu übernehmen, denn die Struktur der Seite und die Organisation der Inhalte wäre mit Divi komplett anders gewesen. Was uns ebenfalls nicht gefallen hat, war der "aufgeblähte" Sourcecode, denn wir wollten für unsere neue Seite eigentlich einen möglichst "schlanken" Sourcecode haben.
Also war Divi für uns auch keine echte Option. Wir wären vom Regen in die Traufe gekommen, denn schlussendlich waren es mehrere verschiedene Aspekte, warum wir nicht mit WordPress weiterfahren wollten. Auf diese gehen wir im folgenden näher ein.
Unter dem Aspekt der Sicherheit lassen sich einige für uns wichtige Argumente zusammenfassen. WordPress ist mit Abstand das meistgenutzte Content Management System im Internet und damit auch ein beliebtes Angriffsziel. Es hat einen Marktanteil von über 60 Prozent im weltweiten CMS-Markt und ist damit unangefochtener Spitzenreiter auf Platz eins. Das bedeutet, dass rund ein Drittel aller Webseiten auf WordPress basieren. Auf Platz zwei liegt Joomla mit einem Anteil von 5.2 Prozent. Drupal bringt es auf Platz drei mit 3.4 Prozent.
Angriffe auf WordPress-Installationen erfolgen über viele verschiedene Einfallstore. Dabei werden Schwachstellen im CMS und der Datenbank, aber auch in Templates oder Plugins ausgenutzt. Begünstigt wird dies zu einem gewissen Grad auch durch Installationen, die nicht auf dem aktuellen Stand gehalten werden, weil die Seite nicht mehr gepflegt wird oder weil alte Plugins im Einsatz sind, die mit neueren Versionen von WordPress nicht kompatibel sind.
Das Ziel ist es Viren, Trojaner oder Schade-Code einzuschleusen um beispielsweise den Server für Crypto-Mining oder DOS-Attacken zu missbrauchen, gezielt Inhalte auszuwechseln oder den Administrator auszusperren und die Kontrolle über die Webseite zu übernehmen. Für den Betreiber der Webseite kann so ein Eingriff sehr schnell böse Folgen haben. Das reicht von einer Verschlechterung des Rankings in Suchmaschinen bis hin zu einer Beschädigung der Online-Reputation und negativen Medienberichten. Den Angreifern geht es in den seltensten Fällen darum, gezielt eine bestimme Webseite zu schädigen, sondern sie nutzen einfach die vorhandenen Schwachstellen aus. Aus eigener Erfahrung wissen wir, dass die Gefahr durchaus real ist: Unsere Hitzestau-Webseite ist zwar nie gehackt worden, aber zwei andere WordPress-Blogs aus unserer Vergangenheit waren schon bösen Jungs zum Opfer gefallen.
Unterm Strich ist der Zeitaufwand relativ gross um laufend informiert zu bleiben und alle Aktualisierungen für die komplette WordPress-Installation inklusive aller Plugins immer auf dem neusten Stand zu halten. In unserer WordPress-Installation hatten wir zudem ein paar spezielle Anpassungen, die auch bei jedem neuen Release wieder manuell nachgeführt werden mussten. Wir hatten unter anderem die Login-Seite für das Backoffice angepasst, das Editieren von Plugins deaktiviert und die Author-ID sowie die Content/Page-ID aus dem Template entfernt. Es ist aus unserer Sicht ein Sicherheitsrisiko, dass WordPress solche Informationen im Sourcecode preisgibt, denn es bietet damit Angriffsmöglichkeiten. So ist etwa der Autorenname auch der User Name, der für den Login verwendet wird.
Um unser WordPress besser abzusichern, hatten wir in den letzten Jahren als "Wachhund" auf die Dienste des Plugins Wordfence gesetzt. Aus unserer Sicht als problematisch erwies sich jedoch die Tatsache, dass das Plugin auf dem Webserver mit einer hohen I/O- und CPU-Leistung sehr viel Ressourcen frisst. Zudem hatten wir mehrmals Rückmeldungen von Lesern bekommen, die durch das Plugin vom Lesen unserer Seite ausgesperrt worden waren. Wordfence warnt unter anderem auch vor neu bekanntgewordenen Schwachstellen in Plugins. Je nach Plugin können dann mehrere zehntausend aber auch mehrere Millionen Webseiten potentiell gefährdet sein.
Wenn man eine WordPress-Installation nutzt, kommt man um Plugins von Drittanbietern nicht herum. Man ist also für den kontinuierlichen Betrieb der eigenen Webseite nicht nur von den WordPress-Entwicklern abhängig, sondern von vielen anderen Entwicklern und Programmieren, die selbständig oder in Teams arbeiten und ihre Plugins zum Download anbieten. Plugins sind damit auch ein Kostenfaktor, denn nicht für alle benötigten Funktionen gibt es brauchbare kostenlose Lösungen.
Mit diesem Konzept ist über die Jahre ein beachtliches Öko-System um WordPress herum entstanden. Für Nutzer wie uns können jedoch Probleme entstehen, wenn die Entwicklungs-Arbeit an einem bestimmten Plugin eingestellt wird, was auch ohne Ankündigung passieren kann. Das bedeutet, dass man sich auf die Suche nach einer Alternative machen muss, wenn das Plugin mit einer neueren Version von WordPress nicht mehr kompatibel ist oder Sicherheitslücken bekannt werden. Was auch passieren kann, ist dass ein anfangs kostenloses Plugin mit einer neueren Version plötzlich kostenpflichtig wird.
Neben dieser Abhängigkeit geht es aber auch um die Performance des Gesamtsystems aus Content Management System und Plugins. Jedes einzelne Plugin vergrössert den Rechenaufwand und die Bearbeitungszeit auf dem Server, wenn die Seite aufgerufen wird. Gerade wenn man seine WordPress-Installation in einer so genannten Shared Hosting-Umgebung betreibt, kann dies relativ schnell zum Problem werden. Wenn man dann Caching-Techniken einsetzen will um die Auslieferung der Webseite wieder zu beschleunigen, kann man an den Beschränkungen des Shared Hosting scheitern. Mit unserer alten Seite hatten wir diese Erfahrung auch gemacht und deshalb auf einen Virtual Server bei Microsoft Azure gewechselt. Dort hatten wir natürlich serverseitig mehr Leistung zur Verfügung, waren aber auch für den kompletten Betrieb selber verantwortlich, was auch wiederum mehr Aufwand bedeutete.
Ein weiterer Grund, der aus unserer Erfahrung gegen eine Weiterarbeit mit WordPress sprach, war unser hoher Zeitaufwand, um einen neuen Blogbeitrag zu erfassen und zu veröffentlichen. Das lag daran, dass wir sehr viel manuell gemacht haben: Unsere Artikel waren oft sehr komplex aufgebaut mit verschiedenen Formatierungen wie Zwischentiteln, Zitaten und Aufzählungen. "Gebaut" wurden diese immer im WYSIWYG-Editor.
Dabei mussten wir auch darauf achten, dass immer der gesamte Inhalt gleich sauber formatiert aussieht. Besonders der Umgang mit Bildern war eine sehr zeitraubende Angelegenheit, denn auch hier haben wir auf den Einsatz von einem Galerie-Plugin oder den WordPress-eigenen Funktionen verzichtet, da uns die Darstellung auf der Webseite nie wirklich gefallen hat. So haben wir uns sicher die Arbeit schwerer gemacht, als es eigentlich hätte sein müssen. Thumbnail-Galerien und einzelne Bilder zum Vergrössern mit Lightbox haben wir direkt in der Sourcecode-Ansicht gebaut. Dafür mussten wir jedes Bild in allen benötigten Grössen separat bereitstellen und hochladen, in den Beitrag einsetzen und die Verlinkung zwischen den verschiedenen Grössen wiederum im Sourcecode anpassen, da es abhängig von der WordPress-Version für verschiedene Einstellungen im WYSIWYG-Editor keine Eingabe-Maske mehr gab.
Die beschriebenen Erfahrungen mit dem hohen Zeitaufwand führten über die Zeit auch zu einem stetig steigenden Frustlevel bei uns, so dass wir uns definitiv für einen Wechsel des Content Management Systems entschieden.
Aus diversen Newsbeiträgen war uns die Bezeichnung "Flat File CMS" schon ein Begriff und damit haben wir uns dann näher auseinander gesetzt.
Das Konzept Flat File CMS unterscheidet sich von einem CMS wie WordPress darin, dass es keine Datenbank wie beispielsweise MySQL oder MariaDB benötigt. Alle Inhalte werden in einfachen Text-Files auf dem Webserver abgelegt. Damit werden nicht nur ein paar Sicherheitsprobleme vermieden, sondern auch die Performance verbessert, da nicht für jeden einzelnen Aufruf der Webseite ein Zugriff auf die Datenbank stattfinden muss. Zudem ist es möglich, für das CMS selbst und die erfassten Inhalte eine Versionierung zu führen.
Diese Eigenschaften passten zur Richtung, die wir mit der neuen Webseite einschlagen wollten. Wir haben uns deshalb verschiedene Flat File CMS-Anbieter näher angeschaut. Dabei sind wir zum Teil auf Lösungen gestossen, die "verwaist" sind, also nicht mehr weiterentwickelt werden oder zu denen es keine technische Dokumentation gibt.
Eines der Systeme, das wir uns näher angeschaut haben, war Statamic. Dahinter steht ein Team von Entwicklern, welche die Software pflegen und weiterentwickeln und Support anbieten. Zudem gibt es zu Statamic eine aktive Community. Allerdings handelt es sich nicht um eine kostenlose, sondern um eine kommerzielle Lösung mit Lizenzkosten.
Wir hatten uns eine Testversion heruntergeladen, installiert und das System genau unter die Lupe genommen. Das Backoffice wirkte schlank und aufgeräumt und es bestand die Option, ohne WYSIWYG-Editor Inhalte zu erfassen. Damit war es auch einfacher, Elemente wie beispielsweise Überschriften immer gleich zu formatieren und darzustellen. Die Formatierungs-Vorgaben sind nicht im Content, sondern zentral im Template hinterlegt. Die Trennung von Content und Layout schien uns hier besser umgesetzt zu sein als bei WordPress. Sicherheitsmässig bedeutete Statamic ebenfalls einen Fortschritt, da viele Einfallstore, die wir bei WordPress bemängelt hatten, hier nicht vorhanden sind. Zudem ist die Auslieferung vom Webserver um einiges schneller.
Mit Statamic hatten wir also eine Alternative zu WordPress gefunden, die unseren Vorstellungen von unserem zukünftigen Content Management System entsprach.
Als nächstes stand für uns die Frage im Raum, wie wir unser Projekt einer neuen Webseite umsetzen wollten. Wir verfügten zwar persönlich über einiges an Erfahrung mit der Gestaltung und Erstellung von Webseiten, aber nach reiflicher Überlegung war uns klar, dass wir uns nicht selber in die Arbeit mit Statamic oder den aktuellen technischen Stand der Web-Entwicklung einarbeiten wollten. Denn wie bereits gesagt, eine Webseite ist heute keine triviale Angelegenheit mehr. Es ist eine Aufgabe für Profis, die sich mit aktuellen Webtechnologien und -standards auskennen und wissen, worauf man achten muss und was man auf keinen Fall tun sollte. Unsere eigenen Kernkompetenzen liegen unterdessen in anderen Bereichen. Deshalb wollten wir die Umsetzung nicht selber an die Hand nehmen.
Eine einfache Google-Suche mit den Begriffen "Statamic Agentur Schweiz" führte uns zur Agentur subpixel, die heute zu Apps with love gehört. Sie war unter anderem explizit auf Projekte mit Statamic spezialisiert und sogar in unserer Region beheimatet.
Gemeinsam mit ihnen haben wir unser gesamtes Vorhaben Schritt für Schritt umgesetzt. Das Logo und das Konzept für das neue Layout stammten von uns. Apps with love war für die Entwicklung der Layout-Templates und die Anpassungen im Content Management System verantwortlich. Die Zusammenarbeit mit ihnen war eine intensive Zeit. Entwicklung, Testing und die Umsetzung von Anpassungen fanden in einem engen Austausch miteinander statt und waren auch für uns sehr lehrreich, denn mit Apps with love hatten wir wirklich Leute gefunden, die ihr Fach beherrschten. Wir wollen an dieser Stelle uns nochmals für die ganze Zusammenarbeit bedanken und können die Agentur wirklich nur wärmstens weiterempfehlen.
Als dann alle Anpassungen im Statamic und das Layout langsam auf die fertige Version zugingen, mussten wir noch entscheiden, was wir genau mit den damals über 700 Blogbeiträgen tun wollten, die wir im Verlauf der Jahre veröffentlicht hatten. Theoretisch gab es die Möglichkeit, die alte Webseite weiterlaufen zu lassen und nur neue Beiträge auf der neuen Seite zu veröffentlichen. Da unsere Inhalte sozusagen unser Kapital verkörpern, haben wir uns dafür entschieden, die alten Beiträge auf die neue Seite mitzunehmen. Also mussten wir eine Lösung finden, die über 700 Texte inklusive aller Bilder und eingebundenen Videos aus der WordPress-Datenbank ins Statamic zu übertragen.
Als einfachster Weg bot sich dafür der Statamic-WordPress-Importer an. Diesen wollten wir schlussendlich aber nicht benutzen, weil dieser einfach alle Elemente eines Blogbeitrags in ein einziges Eingabefeld hineingeschrieben hätte, und zwar unabhängig von der Struktur des jeweiligen Artikels.
Also haben wir uns für ein zweitstufiges Vorgehen entschieden: Wir haben uns zuerst ein webbasiertes Tool geschrieben, um unseren bestehenden Content neu zu organisieren, ohne dabei auf der aktuellen Seite etwas zu ändern. So konnten wir beispielsweise einzelne Texte zu einer Serie oder einem Projekt zusammenfassen, einen zu langen Titel anpassen oder Beiträge, die in Deutsch und in Englisch vorhanden waren, miteinander verknüpfen.
Der zweite grosse Schritt war dann der effektive Import. Um es nicht in eine monatelange "Copy-and-Paste Orgie" ausarten zu lassen, haben wir ein Import-Tool geschrieben, welches für jeden Blogbeitrag den entsprechenden Eintrag im Statamic generiert hat. Dieses Script hat die Anpassungen aus dem ersten Tool mit den Inhalten von der Live-Webseite kombiniert und dabei gleichzeitig alle benötigten Bilder heruntergeladen und in die neue Ablage-Struktur eingefügt. Auf diesem Weg haben wir erreicht, dass auch unsere alten Beiträge in die von uns gewünschte neue Art der Content-Präsentation gepasst haben. Da jeder Beitrag auf der neuen Seite zwingend ein Header- und ein Teaserbild brauchte, haben wir per Zufallsgenerator Bilder mit Farbverläufen generiert und diese vom Script beim Import als Platzhalter einfügen lassen.
Um grobe Schnitzer in der Darstellung im neuen Layout zu vermeiden, haben wir vorher in der WordPress-Datenbank bei einigen Beiträgen direkte Anpassungen im Quellcode vorgenommen. Am meisten Anpassungen waren dabei bei den Beiträgen aus den ersten zwei oder drei Blog-Jahren notwendig, da wir damals Sachen wie Bildergalerien oder Zwischentitel noch anders formatiert hatten als im späteren Verlauf. Am Schluss mussten wir dann noch ein paar Anpassungen manuell direkt im Statamic vornehmen. Auch wenn es viel Arbeit war die beiden Tools zu schreiben, haben sie uns schlussendlich viel Arbeit abgenommen und die ganze Migration deutlich beschleunigt.
Anfangs März im vergangenen Jahr kam dann der grosse Moment, als wir den "Schalter umlegen" konnten und die neue Webseite online ging. Unsere Freude war entsprechend gross und wir waren stolz, endlich am Ziel zu sein.
Aber wenn eine neue Webseite online geht, heisst es natürlich noch lange nicht, dass alle Arbeiten daran abgeschlossen sind. Bug-Fixing oder Verbesserungen am Caching auf dem Webserver für eine schnellere Auslieferung haben uns und Apps with love auch danach weiter auf Trab gehalten. Und selbstverständlich sind immer Ergänzungen und Verbesserungen denkbar, denn an einer Webseite gibt es eigentlich immer etwas zu tun.
Für uns können wir eine positive Bilanz ziehen. Was sich auf jeden Fall verkürzt hat, ist unser Zeitwand um einen neuen Beitrag zu publizieren. Insbesondere der Umgang mit Bildern ist erheblich einfacher als früher. Auch punkto Sicherheit, also zum Beispiel der Zugriff von Unbefugten auf das Backoffice der Webseite, stehen wir mit der neuen System besser da.
Im Moment konzentrieren wir uns darauf, neue Beiträge zu schreiben und gewisse Themen "abzuarbeiten", die wir während der Arbeit an der neuen Webseite zurückgestellt hatten. Denn die Planung des neuen Layouts und insbesondere die ganze Vorbereitung für die Migration der alten Beiträge haben uns über mehrere Monate sehr absorbiert.
Aber wir sind sehr froh, dass wir mit der Unterstützung von Apps with love eine neue Webseite bekommen haben, mit der wir den Blog für uns selbst aber auch für Euch Leserinnen und Leser weiterentwickeln können. Denn mit dem neuen Layout kommen wir auch Euren Bedürfnissen entgegen: Schriftbild und Lesbarkeit der Texte sind besser, die Gliederung der Inhalte ist übersichtlicher und die Webseite kann problemlos auf Smartphones und Tablets dargestellt werden.
