Schlagwort: WordPress

Von WordPress zu Hugo Teil 1: Ausgangslage

· · · Kein Kommentar

Im Laufe der rund 25 Jahre, die ich im World Wide Web aktiv bin, wurden verschiedene Systeme zum Verwalten und zur Anzeige meiner Webpräsenzen eingesetzt:

Allererste Gehversuche wurden anfangs mit “handgemachtem HTML” unter der Domain “shadowfire.de” mit dem Editor HTML-Editor Phase 5 durchgeführt, bevor unter dem klangvollen Namen “shadowCMS” ein selbstentwickeltes Content Management System auf Perl-Basis in Betrieb genommen wurde. Auf Dauer war das direkte Erstellen und Bearbeiten von Beiträgen in der Datenbank aber mehr als lästig (und ich fand nie die Motivation, ein brauchbares Backend zu entwickeln) und so sah Joomla! nach einem vielversprechenden Ersatz aus.

Jahre später erfolgte dann die Umstellung von einer klassischen Website in ein Blog. Hier gab es ein kurzes Kopf-an-Kopf-Rennen zwischen Serendipity und WordPress, welches letztendlich von WordPress für sich entschieden wurde. Mit dieser Umstellung wurde ein Großteil der vorhandenen Beiträge in Form eines Blogs serialisiert und es änderten sich zum bisher letzten Mal die nach außen verwendeten URLs.

Im Laufe der letzten Jahre haben sich meine Bedürfnisse und WordPress immer mehr auseinanderentwickelt, weshalb nach reiflicher Überlegung und Sichtung einiger Alternativen die Migtation auf Hugo anstand. Inhalte, URLs und Blog-Struktur sollten hierbei bis auf einige wenige Korrekturen übernommen werden.

WordPress in Hugo

Zum Zeitpunkt der Umstellung war das Blog auf 1.069 Artikel (1.065 Beiträge und 4 Seiten) und 739 Kommentare angewachsen, die alle zur Übernahme anstanden. Gleichzeitig mit der Umstellung sollte auch das 3.192 Dateien umfassende “Uploads”-Verzeichnis aufgeteilt und die zu einem Beitrag gehörenden Medien zusammen mit dem jeweiligen Beitrag in einem Ordner abgelegt werden.

Auf der Hugo-Website werden einige Migrationswerkzeuge gelistet, die aber alle das geplante Einsatzszenario nicht vollständig abdecken konnten. Auch die Idee, mittels z.B. “wget” ein Abbild der fertig gerenderten Website zu erzeugen und weiterzuverarbeiten, wurde als unpraktikabel verworfen.

Als effektivster Weg blieb das Auslesen der Beitragsinhalte und Kommentare direkt aus der WordPress-Datenbank. Dabei sollte auf jeden Fall ein Teil der WordPress-Ausgabefunktionalität wie z.B. wpautop() erhalten bleiben, so daß die einzelnen Beiträge im HTML-Format abgelegt identisch mit den von WordPress dargestellten Beiträgen sein sollten. Weiterhin sollten auch Sonderfälle wie z.B. die Bildergalerien berücksichtigt werden, welche mittels Resources-Einträgen und einem Gallery-Shortcode von Hugo neu erstellt werden sollten.

Deutlich erleichtert wurde die Umsetzung dadurch, daß in meiner WordPress-Instanz keinerlei fremde Plugins aktiv waren und auch die Struktur der Artikel (jeder Beitrag in exakt einer Kategorie, aber dafür mit beliebig vielen Tags versehen) den Export und die Ablage im Dateisystem deutlich erleichterte.

Ebenfalls nervenschonend war die Tatsache, daß nach einem kurzen Ausflug zur 5.x-Schiene WordPress wieder in der Version 4.19.x aktiv war und somit beim Umsetzen der Beiträge nicht auf neuere Gutenberg-Funktionalitäten und -Besonderheiten Rücksicht genommen werden musste.


Tschüss WordPress, Hallo Hugo

· · · Kein Kommentar

Seitdem ich vor mehr als 10 Jahren von einer klassischen Website auf ein Blog umgestellt habe, war im Backend WordPress im Einsatz. Leider haben sich meine Bedürfnisse und WordPress in den letzten Jahren immer mehr auseinanderentwickelt, ein paar Gedanken hierzu habe ich im Beitrag “Gedanken aus dem Maschinenraum” festgehalten.

Dieser Beitrag ist nun der erste, der mit Hilfe eines neuen Backends erzeugt wurde. Die Wahl fiel auf Hugo, einen statischen Websitegenerator. Gerade im Hinblick auf die Tatsache, daß hier im Blog maximal 1-2 Beiträge pro Woche erscheinen, reicht es, wenn die Inhalte nicht bei jedem Aufruf einer Seite neu erzeugt werden, sondern eben nur dann, wenn sich am Inhalt auch tatsächlich etwas ändert.

Alle Beiträge wurden umgezogen und die URLs auch - bis auf einige wenige technisch begründete Ausnahmen - wie von WordPress vergeben beibehalten. Auch alle bisher abgegebenen Kommentare wurden übernommen und sind weiterhin den jeweiligen Beiträgen zu sehen, auch wenn aktuell Antworten nicht direkt als solche ersichtlich sind. Das Kontakt- und Kommentarformular sowie die Suche sehen leicht anders aus und sind der einzige dynamische Teil der Website. In hoffentlich nicht allzu ferner Zukunft wird noch ein detaillierter Blick auf die Migration und den Einstieg in Hugo erscheinen, dieser ist aber noch in Arbeit.

Sollte irgendwo noch irgendetwas klemmen, so bitte ich um entsprechende Nachricht.


WordPress-Wartungsmodus manuell aktivieren

· · · Kein Kommentar

Bei einer Aktualiserung schaltet WordPress die Website automatisch in den Wartungsmodus, ein Mechanismus, den man auch für manuelle Wartungen aktivieren kann.

Zum Aktivieren wird eine Datei “.maintenance” mit folgendem Inhalt im Hauptverzeichnis der WordPress-Installation angelegt, welche den Wartungsmodus bis zum Entfernen (oder Umbenennen der Datei) aktiviert.

<?php $upgrading = time(); >

Die Erklärung der Funktionsweise findet sich im WordPress-Quellcode innerhalb der Datei load.php

...
303	function wp_is_maintenance_mode() {
304	        global $upgrading;
305	
306	        if ( ! file_exists( ABSPATH . '.maintenance' ) || wp_installing() ) {
307	                return false;
308	        }
309	
310	        require ABSPATH . '.maintenance';
311	        // If the $upgrading timestamp is older than 10 minutes, consider maintenance over.
312	        if ( ( time() - $upgrading ) >= 10 * MINUTE_IN_SECONDS ) {
313	                return false;
314	        }
...

Im ersten Schritt wird das Vorhandensein einer Datei “.maintenance” im Hauptverzeichnis der WordPress-Installation geprüft. Ist diese vorhanden, so wird vom aktuellen Zeitstempel der Wert der Variablen “$upgrading” subtrahiert. Ist der Rest größer oder gleich 10 Minuten, so wird der Wartungsmodus deaktiviert.

Durch das Setzen der Variable “$upgrading” auf den aktuellen Zeitstempel bleibt die Differenz immer 0, die 10 Minuten werden nie überschritten und der Wartungsmodus kann manuell gesteuert werden.


Der knackige Editor, der aus der Reihe tanzt

· · · Kein Kommentar

Beim Lesen des Begrüßungstexts von WordPress 5.7 fühle ich mich in meinen Gedanken bestätigt:

Vielleicht liegt es aber auch nur an der unglücklichen Übersetzung des englischen Texts:

Jazz up your stories in an editor that’s cleaner, crisper, and does more to get out of your way.


Gedanken aus dem Maschinenraum

· · · Kein Kommentar

WordPress 5 und der Block-Editor

Es ist viel geschrieben worden über Gutenberg, den nicht mehr ganz so neuen Editor, der mit WordPress 5 zum Standard wurde. WordPress Version 5 liefert aber nicht nur einen neuen Editor im bekannten Umfeld, sondern einen Wechsel der Philosophie.

Einer der Hauptvorteile eines Content Management Systems ist die klare Trennung von Inhalt und Präsentation. In einer Analogie zu Office ist ein CMS-Design das, was ein Folienmaster in einem Präsentationsprogramm oder eine Formatvorlage in einer Textverarbeitung ist. Im Text wird lediglich markiert, was ein Textabschnitt, eine Liste oder was eine Überschrift ist - die optische Repräsentation wird vom Design bestimmt. Dies ergibt sich auch aus der Definition von HTML:

HTML dient als Auszeichnungssprache dazu, einen Text semantisch zu strukturieren, nicht aber zu formatieren. Die visuelle Darstellung ist nicht Teil der HTML-Spezifikationen und wird durch den Webbrowser und Gestaltungsvorlagen wie CSS bestimmt. [Quelle]

Genauso, wie Markdown als vereinfachte Auszeichnungssprache diesen Gedanken in eine Richtung weiterentwickelt, weicht WordPress spätestens seit Version 5 diese Trennung immer mehr auf. Die WordPress-Gutenberg-Seite wirbt

Das gesamte Bearbeitungs-Erlebnis wurde für medienreiche Seiten und Beiträge neu konzipiert. [Quelle]

und verspricht

Verlass dich darauf, dass dein Editor wie deine Website aussieht. [Quelle]

Je nachdem, was der Entwickler eines Designs an Blöcken oder Bearbeitungsmöglichkeiten vorgesehen hat, kann ein Redakteur auch in die optische Gestaltung eingreifen und diese für einen Block (oder mehrere Blöcke) anpassen. Natürlich war dies vorher (in einem engeren Rahmen) auch schon mit TinyMCE möglich, mit WordPress 5 wird dieser Philosophiewechsel aber von der Ausnahme zur Regel befördert. Ein Wechsel auf ein alternatives Design wird deutlich erschwert und mit erhöhtem Aufwand verbunden sein, wenn Blöcke oder deren Anpassungsmöglichkeiten nicht mehr zur Verfügung stehen.

Nachdem hier seit dem Update auf WordPress 5 das “Classic Editor”-Plugin zum Erstellen und Bearbeiten von Beiträgen zum Einsatz kam, habe ich mich nebenbei mit Gutenberg auseinandergesetzt und Erfahrungen gesammelt. Manche Dinge werden Dank der Aufteilung in Blöcke einfacher - mal schnell einen Abschnitt verschieben oder die über dem aktuell bearbeiteten Abschnitt verfügbare Werkzeugleiste machen das Arbeiten angenehmer und flüssiger, es gibt aber auch Schattenseiten.

Um den neuen Anforderungen gerecht zu werden, muß - zwangsweise - auch innerhalb von WordPress viel geändert werden. WordPress und Gutenberg sind im permanenten Wandel, was den benötigten Zeiteinsatz spürbar erhöht um mit dem vorgelegten Tempo Schritt zu halten - bei einem reinen Hobbyprojekt fast unmöglich.

Child Themes

Mit TwentyTwenty war hier seit November 2019 erstmals kein selbstentwickeltes Design, sondern ein WordPress-Standarddesign im Einsatz. Eine gängige (und die empfohlene) Möglichkeit, fremderstellte Designs an eigene Bedürfnisse anzupassen, sind sogenannte Child-Themes.

Statt an den vorhandenen Dateien herumzubasteln, wird ein sog. Child erzeugt, welches im ersten Schitt bis auf den Namen alles vom Parent übernimmt. Dann können entweder PHP-Dateien des Parents kopiert und angepasst oder in der “style.css” des Childs Einstellungen des Parents überschrieben werden.

Wie die Ankündigung des Designs unterstreicht, wurde TwentyTwenty insbesondere als Vorzeige-Design für WordPress 5 und Gutenberg erstellt

Unser Standard-Theme für 2020 ist so konzipiert, dass es die Flexibilität des Block-Editors voll ausschöpft. [Quelle]

Dies wirkt sich direkt auf die Größe und Anzahl der mitgelieferten Styles aus, denn mit rund 125kb war bereits die “style.css” von TwentyTwenty alles andere als schlank, hinzu kamen nochmal rund 15kb an Style-Anpassungen durch das Child-Theme. Dies mag auf den ersten Blick nicht dramatisch klingen, letztendlich bedeuten Anpassungen im Child aber immer, daß diese nicht auf magische Weise optimiert und kombiniert zusammen mit den Parent übertragen werden, sondern sich der ausgebende Browser damit herumschlagen darf. Im Endeffekt wird viel übertragen und interpretiert, was dann doch nicht verwendet wird.

Dazu kommt noch der Unsicherheitsfaktor bei Aktualisierungen des Parent-Themes. Aktualisierungen sind meist gut und wichtig, sie bergen aber jedesmal die Gefahr, daß irgendetwas anschließend nicht mehr funktioniert. Die Folge ist ein erhöhter Aufwand an Tests und Anpassungen bei jeder Aktualisierung.

Zurück zum Start

Letztlich bleibt das Gefühl, daß WordPress mit Version 5 jede Menge nicht benötigte und “nebenbei” nur schwer überschaubare Funktionalität eingeführt hat. Deutlich mehr auf Javascript (und im Backend auch auf React) setzend und mit vielen hier nicht verwendeten Möglichkeiten wurde mit jeder neuen Version klarer, daß die Plattform nicht mehr so richtig zum Einsatzzweck passt. Vieles ist abschalt- und konfigurierbar, aber die Verwendung eines Systems, bei dem man immer mehr Standard-Funktionalität abschaltet und durch zusätzlich zu installierende Alternativen ersetzt, ist aus meiner Sicht der falsche Ansatz.

Glücklicherweise werden alte WordPress-Versionen noch weiter gepflegt (aktuell sogar bis zurück zur Version 3.7 aus dem Oktober 2013) und so habe ich ein Downgrade der WordPress-Installation vorgenommen. Seit ein paar Tagen gehört dieses Blog (wieder) zu den rund 8% aktiven WordPress 4.9 Installationen.

Alternativen und Aussichten

Zu einer interessanten Alternative scheint sich ClassicPress zu entwickeln, ein Fork der Version 4.9 von WordPress, der mit den Schlagwörtern “Stable. Secure. Instantly Familiar.” wirbt. ClassicPress 1 ist aus Gründen der Abwärtskompatibilität noch recht eng mit WordPress 4.9 verbunden, es wurden lediglich die mitgelieferten Plugins entfernt und Security-Fixes hinzugefügt. Eine Migration sollte problemlos möglich sein.

Für Version 2 ist geplant, Teile wie z.B. die Gravatar- oder Emoji-Unterstützung aus dem Core zu lösen und in in Plugins auszulagern und mit einem Sprung auf die Mindestanforderung PHP 7 alte Code-Teile zu entrümpeln.

Vielleicht wird der Weg nach rund 10 Jahren WordPress aber auch in eine ganz andere Richtung zu einem Flat-File-Content-Management-System führen. Hier gibt es vielversprechende Kandidaten und der Gedanke, Mediendateien statt in einem großen “Upload”-Ordner zu suchen vielleicht mal wieder zusammen mit dem auf sie referenzierenden Text aufzubewahren, klingt verlockend.