Wechsel von WordPress zu Hugo

Seit 9 Jahren blogge ich mit WordPress auf diesem Blog. Auf meinem zweiten Blog, christoph.miksche.org blogge ich seit 7 Jahren mit WordPress. Zudem habe ich seit 2013 ebenfalls immer wieder eine Plattform (WebPage4.me) zum Erstellen eines eigenen WordPress-Blog betrieben und auch beruflich habe ich immer wieder WordPress Websites verwaltet.

Ich habe also eine ziemlich tiefe Beziehung mit WordPress. Allerdings habe ich in den letzten Jahren seit 2017 unter blog.m5e.de einen Blog ausschließlich mit statischen Generatoren betrieben. Hierbei war ich mit Jekyll zwar nicht so super zufrieden aber Hugo ist dafür wunderbar.

Nun will ich meinen zweiten Blog auf Hugo migrieren. Meine Hauptgründe dafür sind:

  • WordPress ist langsamer als Hugo
  • WordPress ist unsicherer als Hugo
  • WordPress benötigt mehr Aufwand (z.B. Aktualisierungen, …)
  • WordPress Hosting ist teurer und aufwändiger (da PHP und eine Datenbank benötigt wird)
  • Gerade bei Shared-Hosting kommt es öfter zu Problemen mit WordPress

Der letzte Punkt ist der heftigste. Denn ich habe mir z.B. für automatische Updates bei Shared-Hosting Anbietern, die keine automatischen Updates via JS möglich machen, ein Skript geschrieben: https://github.com/CMiksche/wp-remote-updater

Auch für automatische Backups habe ich ein Skript geschrieben: https://git.kernel.fun/cmiksche/php-sharedhost-backup

Trotz dieser beiden Skripte bleiben aber bei Shared-Hosting-Anbietern weitere Probleme. Aktuell funktioniert z.B. der Gutenberg-Editor bei meinem zweiten Blog nicht. Auch Updates von Plugins usw. müssen dort manuell gemacht werden, weil der Hosting-Anbieter anscheinend keine JS-Verbindungen zu WordPress zulässt.

Es gibt sogar einige Anbieter wie HelioHost, welche aktiv von dem Betreiben eines WordPress-Blogs auf der eigenen Plattform abraten. (Dieser Anbieter deaktiviert anscheinend sogar Kundenaccounts, deren WordPress-Instanz zu hohe Auslastungen haben)

Bei diesem Blog (blog.wronnay.net) und auch bei WebPage4.Me habe ich dieses Problem zwar nicht, weil ich die beiden Seiten auf eigenen Servern betreibe, allerdings will ich auch noch Online-Präsenzen haben, wenn mein Server mal ausfällt und deshalb setze ich bei meinem zweiten Blog auf einen anderen Anbieter.

Diese ganzen Probleme habe ich mit einer statischen Website aber nicht. Für statische Websites gibt es unzählige kostenlose Anbieter, statische Websites sind viel schneller und leichter umzuziehen. Typischerweise ist der größte Vorteil von WordPress zwar, dass man online von überall seine Beiträge schreiben kann und auch mehrere Autoren möglich sind aber alle meine aktuellen Blogs werden nur von mir geschrieben und es gibt auch Lösungen für statische Blogs, die das gleiche möglich machen.

Bei mir kommt dann noch hinzu, das ich als Softwareentwickler seit Jahren sehr gerne Markdown schreibe und meine Projekte in Git verwalte. Dies gibt es bei statischen Generatoren „out of the Box“ und ich fühle mich in so einer Umgebung richtig wohl.

Deshalb möchte ich nun versuchen, meinen persönlichen Blog (christoph.miksche.org) auf Hugo umzuziehen. Dieser Umzug wird vermutlich etwas aufwendig sein, da ich z.B. dort auch ein custom Theme verwende, allerdings werde ich danach unabhängiger von Hosting-Anbieter sein und muss mir keine Sorgen mehr machen, dass ein Update irgendwas kaputt macht.

Das Exportieren der Daten von WordPress

Bevor man irgendwas mit Hugo macht, sollte man die Daten von WordPress exportieren.

Für Hugo gibt es z.B. WordPress Plugins wie wordpress-to-hugo-exporter, dieses hat bei meinem Hoster aber leider wegen einer Zeitüberschreitung bzw. Netzwerkfehlers nicht geklappt.

Es gibt auch den wordpress-to-jekyll-exporter, den man nach dem Export dann mit dem Jekyll Importer von Hugo importieren könnte, allerdings war ich mit dem Export von dem Plugin nicht zufrieden. Oft war in den Posts z.B. noch HTML vorhanden…

Deshalb habe ich eine andere Methode gewählt: Man kann man einfach via “Werkzeuge“ > „Daten exportieren“ > „Alle Inhalte“ > „Export-Datei herunterladen“ eine XML-Datei mit den WordPress-Daten herunterladen, die man anschließend konvertieren kann.

Das Exportieren

Konvertieren in Hugo Format

Es gibt verschiedene Tools zum Konvertieren. Von WordPress-Plugins bis zu CLI-Tools. Wie schon beschrieben, habe ich keine guten Erfahrungen mit den WordPress-Plugins gemacht.

Die Ausgabe von blog2md war jedoch besser, auch wenn dort keine Bilder exportiert werden und es bei manchen Posts z.B. an Absätzen fehlt.

D.h. jetzt gehen wir jeden Beitrag durch und prüfen, ob alles passt. Wir fügen Absätze hinzu, korrigieren evtl. URLs und Bilder usw…

Erstellen des Hugo-Projekts

Mit dem folgenden Befehl legt man eine neue Website mit Hugo an:

hugo new site mein-toller-blog

Nun kann man die konvertierten Dateien in den /content Ordner verschieben. Die Bilder habe ich nach /static verschoben.

Erstellen / Anpassen des Theme

Unter /themes legen wir einen neuen Ordner für unser Theme an. Als Vorlage kann man so einfache Themes wie https://github.com/J-Siu/hugo-theme-sk1 oder https://github.com/yanlinlin82/simple-style verwenden.

Anschließend musste ich mühsam mein WordPress-Theme auf die Hugo Syntax anpassen…

Fazit

Trotz der Mühe hat sich das gelohnt! Meine Seite lädt nun viel schneller und hat weniger Wartungsaufwand. In Zukunft werde ich wohl eher Hugo-Seiten als WordPress-Instanzen aufsetzen.

WordPress: Kann Kategorie nicht bearbeiten bzw. setzen

Vor Kurzem hatte ich das Problem, das ich auf einem WordPress Blog eine bestimmte Kategorie nicht setzen konnte. Nach eine Suche bin ich auf https://stackoverflow.com/questions/41880458/wordpress-sorry-you-are-not-allowed-to-edit-this-item gestoßen und ein Post konnte mir wirklich helfen.

Anscheinend trat der Fehler bei mir auf, weil ein Begriff für eine Kategorie gleichzeitig auch als Schlagwort gesetzt war. Das ist wohl nicht möglich / erlaubt. Daher war die Lösung, sich entweder für die Kategorie oder dem Schlagwort zu entscheiden.

Zuerst sollte man in der Datenbank nach den doppelten Einträgen suchen:

SELECT term_id, COUNT(term_id) FROM wp_term_taxonomy GROUP BY term_id HAVING COUNT(term_id) > 1;

Anschließend habe ich die Einträge mit der term_id in der Tabelle anschaut und den Eintrag für den Tag gelöscht.

Debian 9 Upgrade mit nginx und PHP 7.2

Ich habe nun alle meine Debian Systeme auf die neueste Version „Stretch“ ohne größere Probleme aktualisieren können.

Da ich in den letzten Jahren allerdings immer größere Probleme hatte und weiß, dass eine gute Anleitung hilfreich sein kann, möchte ich hier meine Vorgehensweise anhand eines Webservers mit Debian 8 beschreiben.

Hintergrund

Gerade bei Webservern ist eine Aktualisierung wichtig, da Sicherheitslücken den Server schnell zu einer Virenschleuder verwandeln können.

Sollte PHP auf dem Webserver verwendet werden, führt kaum ein Weg an einem Upgrade vorbei, da Debian 8 keine aktuelle PHP-Version ausliefert. (Debian 9 zwar auch nicht wirklich aber dazu später mehr …)

Vorbereitung

Folgende Punkte führe ich immer vor einer Webserver-Aktualisierung durch:

  • Wartungsmodus in WordPress / anderen CMS aktivieren
    • Bei größeren Projekten die Nutzer über das Upgrade informieren
  • Wichtige Verzeichnisse sichern (sollte man generell regelmäßig machen), z.B.:
    • Webserver-Verzeichnis (/var/www)
    • /opt Verzeichnis (bei manuell hinzugefügter Software)
    • /home Verzeichnisse (Daten der Unix-Nutzer)
  • Wichtige Dateien sichern
    • z.B.: /etc/crontab mit regelmäßig ausgeführten Skripten
  • Alle Datenbanken sichern

Aktuelle Pakete herunterladen

Mit

apt update

und danach

apt upgrade

aktualisiert man die aktuellen Pakete.

Alte Sources sichern

Damit man bei Problemen schnell wieder auf Debian Jessie wechseln kann, ist eine Sicherung der alten Sources List hilfreich:

cp /etc/apt/sources.list /etc/apt/sources.list_backup

Wichtig: Sollte es auch Dateien unter /etc/apt/sources.list.d geben, ist auch eine Sicherung dieser Dateien nicht überflüssig!

Neue Sources pflegen

Nun sollte man den Namen der alten Version durch den Namen der neuen Version in der Sources.list und allen anderen Dateien unter z.B.: /etc/apt/sources.list.d aktualisieren. sed ist für solche Aufgaben perfekt geeignet:

sed -i 's/jessie/stretch/g' /etc/apt/sources.list

Pakete aktualisieren

Nachdem wir nun die Quellen auf die neue Version geändert haben, können wir die Paketquellen mit den folgenden Befehl aktualisieren:

apt update

Anschließend aktualisieren wir die Pakete wieder mit:

apt upgrade

Hier kann es sein, dass wir den Befehl mehrmals ausführen müssen und gefragt werden, ob wir die aktuellen Konfigurationsdateien behalten wollen oder neue Konfigurationsdateien übernehmen (letzteres sollte nur gemacht werden, wenn nichts an den Konfigurationen geändert wurde).

Systemupgrade abschließen

Mit den bisherigen Befehlen wurden noch nicht alle Pakete aktualisiert. Um das Systemupgrade abzuschließen, benötigen wir eine Ausführung des folgenden CLI-Befehls:

apt dist-upgrade

Systemupgrade prüfen

Nach einem großen Upgrade empfiehlt sich ein Neustart, welcher mit

reboot

durchgeführt werden kann.

Um festzustellen, ob wir die gewünschte Version haben, kann man diese mit cat ausgeben lassen:

cat /etc/issue

PHP aktualisieren

Zum Zeitpunkt dieses Posts gibt es noch keinen mir bekannten Weg, um PHP direkt von den Debian Sources zu beziehen. Deshalb müssen für PHP 7.2 Fremdquellen genutzt werden. Bei Fremdquellen sollte immer auch auf das Sicherheitsrisiko geschaut werden.

Vorerst sollten wir PHP deinstallieren:

apt purge php*

Anschließend den Schlüssel des fremden Repos importieren:

wget -qO - https://packages.sury.org/php/apt.gpg | sudo apt-key add -

Um dann die Quelle in eine Sources List zu speichern:

sudo echo "deb https://packages.sury.org/php/ $(lsb_release -sc) main" | sudo tee /etc/apt/sources.list.d/php.list

Die Paketquellen aktualisieren wir wieder mit:

apt update

Nun können wir endlich die neue Version von PHP installieren:

sudo apt install php7.2

(hier können natürlich auch noch weitere Pakete wie php7.2-imap gewählt werden)

nginx anpassen

Da ich gerne nginx als Webserver verwende, musste ich für die neue PHP-Version auch den Socket in den sites-available aktualisieren.

Dafür wechseln wir erst in das Verzeichnis der virtual Hosts:

cd /etc/nginx/sites-available/

Danach bearbeiten wir die gewünschte Website mit einem Editor unserer Wahl – z.B.: nano.

Wir suchen erst nach fastcgi_pass und passen die Zeile dann wie folgt an:

fastcgi_pass unix:/var/run/php/php7.2-fpm.sock;

Um die Änderung aktiv zu schalten, müssen wir den Webserver noch neu starten:

systemctl restart nginx.service

Ich hoffe, meine Erklärung des Debian Upgrades war hilfreich. Wenn ihr zukünftig Tutorials zu Themen wie Debian Webserver erhalten möchtet, könnt ihr mir gerne auf Twitter folgen.

nginx: upstream sent too big header

Beim Einloggen in einen WordPress Blog hatte ich vor Kurzem nach einem Upgrade von Debian und PHP einen 502 Bad Gateway Error. Dieser wurde von einem „upstream sent too big header“ Fehler ausgelöst.

Da ich zu diesem Fehler nur englische Beiträge gefunden habe, möchte ich hier mal einen Lösungsweg auf Deutsch teilen.

In der nginx Error Log, welche man unter Debian unter /var/log/nginx/error.log finden kann, fand ich die folgende Zeile:

[error] upstream sent too big header while reading response header from upstream, client: ***.***.***.***, server: *****.***, request: "GET /wp-login.php

(Domain und IP-Adresse aus Datenschutzgründen unkenntlich gemacht)

Eine Lösung, um diesen Fehler zu beheben, ist unter Debian die /etc/nginx/fastcgi.conf zu bearbeiten und die folgenden Zeilen hinzuzufügen, um die Buffer Size festzulegen:

fastcgi_buffers 16 16k;
fastcgi_buffer_size 32k;

(Stack Overflow Post dazu)

Natürlich muss man selbst ermitteln bzw. wissen, welche Buffergrößen notwendig sind. Nginx selbst hat hierzu auch eine gute Dokumentation online: http://nginx.org/en/docs/http/ngx_http_fastcgi_module.html#fastcgi_buffer_size

Wronnay Pics eingestellt

Seit 2013 konnte man unter pics.wronnay.net kostenlos Bilder hochladen.

Ich habe heute nach einer Neuinstallation eines Webservers den Dienst erneut geprüft und festgestellt, dass das Hosting in letzter Zeit für unseriöse Dinge missbraucht wurde. Zudem wird die verwendete Software nicht mehr weiterentwickelt.

Deshalb habe ich nun, nach fast 5 Jahren, den Dienst eingestellt. Da dieser allerdings nicht wirklich populär war, wird es wenige tote Bilder geben.

Der ursprüngliche Zweck war das Anbieten einer Möglichkeit zum Hochladen von Bildern für Nutzer von WebPage4.Me, ForenHosting.net und Homepage-versammlung. Unter WebPage4.Me kann man allerdings jetzt direkt Bilder hochladen und die anderen Dienste existieren aktuell nicht mehr.

WebPage4.Me Relaunch

WebPage4.Me war ab 2013 ein Portal zum Erstellen einer Website mit verschiedenen CMS. Man konnte dort unter anderem WordPress Blogs oder Webseiten mit meinem eigenen CMS („WronnayCMS“, aktuell nicht verfügbar) erstellen.

Das Portal wurde ca. 2014 geschlossen, da der Wartungsaufwand zu hoch war (damals hatte ich für die Verwaltung noch ein eigenes System genutzt, jeder Nutzer bekam eine eigene Datenbank und Subdomain und konnte externe Domains aufschalten, dadurch musste mit jeder neuen WordPress / Joomla, etc Version der (sehr aufwendige) Installationsvorgang angepasst werden).

Gestern habe ich auf Basis von WordPress Multisite das Projekt mit einem für mich viel geringeren Wartungsaufwand neu gestartet. Das neue Webdesign kann man durchaus den Minimalismus zuschreiben. Mein Ziel ist es, den Wartungsaufwand so gering wie möglich zu halten, d. h. es werden alle wiederholenden Vorgänge automatisiert.

Vorerst keine Suche mehr

Die bisherige Suchmaschine unter „Wronnay.net“ gibt es vorerst nicht mehr. Das dürfte allerdings auch kaum jemanden interessieren, da die Suche sowieso sehr unbekannt war.

Weil die Funktion so unbekannt war, habe ich auch auf dem Server ein Upgrade auf Debian Jessie („8“) ausprobiert, was allerdings schief lief. Deshalb gibt es seit gestern unter „Wronnay.net“ meine ehemalige Projektübersicht.

Die Suche wird vielleicht bald wieder auferstehen, wenn ich eine Lösung gefunden habe, wie ich meine Anpassungen am Server auf die neue Version von Debian umstellen kann. Vielleicht werde ich die Suche aber trotzdem nicht wieder aktivieren – der Dienst wurde so gut wie nie genutzt, hatte allerdings eine sehr hohe Serverauslastung …

Vorschau: 2015

Hier eine kurze Übersicht, was 2015 alles passieren könnte bzw.: wird:

Umzüge

ForenHosting.net und WebPage4.Me sind schon auf einem neuen Server umgezogen, Wronnay.net wird wahrscheinlich um Februar auf einen neuen Server umziehen. Grund dafür sind die billigeren Preise eines neuen Anbieters und die gleichbleibenden Preise des alten Anbieters. Der Speicherplatz wird mehr als dreimal so groß wie vorher und der RAM mehr als doppelt so groß wie bei dem alten Server.

Werbenetzwerk

Ich arbeite schon längere Zeit an ein System für ein neues Werbenetzwerk namens AnaAds.de, dieses Jahr könnte dies veröffentlicht werden.

Aktien

Es könnte sein, dass „Wronnay Shares“ – ein System zur Analyse von Aktien veröffentlicht wird.

Hosting

Wie schon erwähnt, gibt es 2015 mehr Speicherplatz für Projekte – es könnte sein, dass die Hosting-Plattform „Wronnay Hosting“ erstellt wird.

Gründung einer Firma

Damit kostenpflichtige Leistungen (z.B.: „Verkauf von Werbeplätzen“ oder „Verkauf von Domains“) angeboten werden können, könnte es sein, dass eine Firma gegründet wird.

Bestehende Projekte werden natürlich auch dieses Jahr verbessert werden.

PS: Das ist der 100. Beitrag auf diesem Blog.

Änderungen an der Infrastruktur

Da die beiden wichtigsten Server im Wronnay.net / ForenHosting.net / WebPage4.Me – Netzwerk in letzter Zeit immer wieder Schluckauf hatten, werden jetzt mehrere Änderungen durchgeführt, die die Zuverlässigkeit verbessern sollen:

  • CloudFlare wurde schon die ganze Zeit zur DNS-Verwaltung genutzt, jetzt wird der Dienst auch teilweise als DDoS-Schutz eingesetzt.
  • Wenn die Server ausfallen, sendet ein externer Dienst jetzt automatisch eine E-Mail an die Administration
  • Die Domains waren hauptsächlich bei einem Provider, jetzt werden sie auf mehrere Provider aufgeteilt

Wronnay.net: Verbesserte HTML-Anzeige

Die Suchergebnisse unter Wronnay.net werden jetzt besser dargestellt. Grund dafür ist eine Änderung an der Darstellung von HTML-Zeichen. Bisher wurden (aus Sicherheitsgründen) keine HTML-Zeichen dargestellt, jetzt werden bestimmte HTML-Zeichen, die als ungefährlich gekennzeichnet sind, angezeigt.

Der aktuelle Index der Wronnay.net Suchmaschine umfasst mehr als 70.000 (siebzigtausend) Webseiten. Unter http://wronnay.net/do:addsite können Seiten hinzugefügt werden. (Der Wronnay.net Search Bot sucht aber auch selbstständig nach neuen Seiten)