Erste Version von netzalben.de mit WordPress

Mit WordPress hatte ich langjährige Erfahrungen. Daher erschien die Wahl naheliegend.

Bisher hatte ich mit dem klassischen Editor gearbeitet (TinyMCE), der auch bei Joomla, Drupal und anderen Systemen zum Einsatz kommt. Die heute verbreitetsten Systeme haben alle ca. 20 Jahre auf dem Buckel. Das bedeutet, dass der Ruf, den sich WordPress erarbeitet hat, einfach handhabbar zu sein, sich nicht auf das Erstellen von Inhalten beziehen kann, da der Editor kein Alleinstellungsmerkmal darstellt.

Tatsächlich würde ich sagen, dass es WordPress gelungen war, eine geschickte Anbindung der Datenbank zu implementieren, die auch die Verwaltung des Systems und die Entwicklung von Erweiterungen einfach machte. Darüber hinaus hatten sie bestimmt ein gutes Marketing.

Am 6.12.2018 veröffentlichte WordPress mit Version 5.0 einen neuen auf Blöcken basierenden Editor namens Gutenberg. Das Netz füllte sich daraufhin mit Artikeln frustrierter Altanwender. Viele bestehende Seiten blieben mittels Plugins beim bisherigen Editor.

Am 25.1.2022 erschien mit Version 5.9 erstmals ein Softwarestand, bei dem ich persönlich den Eindruck hatte, ein mit Blöcken produktiv einsetzbares System in Sichtweite zu haben.

Die Version 6.3 vom 9.8.2023 fiel zeitlich mit den ersten Arbeiten zu netzalben.de zusammen. Ich hatte die Vorstellung, für den Blog und evtl. einzelne Alben Block-Themes einzusetzen, während andere Alben weiterhin klassische Themes als Basis hätten.

Nach der Veröffentlichung von Version 6.7 am 14.10.2024 erscheinen immer noch Artikel, die Altanwendern die Vorteile von Block-Themes schmackhaft machen wollen.

Um zunächst einmal die Inhalte der Website, von denen ich in groben Zügen eine Vorstellung hatte, konkret zu erstellen, verzichtete ich auf ein eigenständiges Layout und beschloss, weitgehend bestehende Themes zu nutzen.

Child-Themes

Für die neue Site wollte ich das neueste Theme verwenden, also TwentyTwentyThree. In den letzten fünf Jahren war seitens WordPress verbreitet worden, dass bei Block-Themes die Datei style.css keine Style-Angaben mehr enthalten sollte, sondern nur einen Kommentar, der dem System Informationen über das Theme gibt. Auch ob es Child-Themes zu Block-Themes geben sollte, blieb lange Zeit fraglich. Da ich dennoch Interesse an einer kleinen (Style-)Änderung hatte (automatische Silbentrennung) fand ich heraus, wie sich beide Bestandteile des bisherigen WordPress-Systems weiter nutzten lassen. Das genaue Vorgehen habe ich im Artikel Child Theme für Twenty-Twenty-Three beschrieben.

Als abweichendes Theme für das Album der Alpenüberquerung kam Intenso, ein klassisches Theme, meinen Vorstellungen entgegen. Erfreulich ist in diesem Zusammenhang, dass auch in klassischen Themes Blöcke eingesetzt werden können.

Gegenüber der ausgelieferten Version der ausgewählten Themes waren umfangreichere Anpassungen nötig, z.B. sollte die Breite des Inhalts als auch Header und Footer aller Seiten identisch sein.

Block-Editor

Ich möchte mich jetzt nicht den Lobhudeleien der Befürworter noch den Verteuflungen der Gegner anschließen. Es gibt einfach Licht und Schatten, und man muss sich in das System einarbeiten. Was für sowohl klassische als auch Block-Themes auffällt, ist die im Vergleich zu früher gesunkene Unterstützung bei der Handhabung von Medien. Möglicherweise vertraut man seitens WordPress darauf, dass Nutzer für fehlende Funktionalität Plugins spezialisierter Zulieferer einsetzen.

In Textverarbeitungssystemen kennt man bei den Formatvorlagen Absatz- und Zeichenvorlagen. Im Block-Editor entsprechen Blöcke Absätzen, z.B. Fließtext, Zitate, Programmcode, aber auch komplexere Gebilde. Inline-Blöcke entsprechen Zeichenvorlagen. Im Blockeditor lassen sich Inline-Blöcke oder auch spezielle Zeichen wie z.B. geschütztes Leerzeichen zum Großteil erst nach der Installation von Plugins einsetzen.

Der Inhalt der Website mit einigen Seiten, einigen Blog-Beiträgen, einem Album im allgemeinen Layout und einem Album mit individuellem Theme waren kaum fertig gestellt, als es seitens WordPress die nächsten Updates gab. Hier zeigten sich verschiedene Nachteile der gewählten Vorgehensweise.

Update von Parent-Themes

Child-Themes werden propagiert, um von Weiterentwicklungen der Themes zu profitieren, ohne die eigenen Änderungen zu verlieren. Das hört sich erst einmal gut an. So wurde z.B. aus dem Theme TwentyTwelve, zu dessen Entstehung das Wort responsive wahrscheinlich noch unbekannt war, im Laufe der Zeit ein responsibles Theme. Im konkreten Fall fanden aber Änderungen beim Theme Intenso statt, durch die sich Abstände änderten. Als Folge entstanden unansehnliche Umbrüche, die einzeln bereinigt werden mussten.

Zu dem Zeitpunkt, als das Theme TwentyTwentyFour veröffentlicht wurde, kam es auch beim The­me TwentyTwentyThree zu Änderungen, die Einfluss auf Abstände hatten. Für mich zeigt sich hier ein weiterer großer Nachteil der Strategie von WordPress: statt Layout-Angaben transparent und regelbasiert in CSS-Dateien zu speichern, verlagert man diese Informationen in die Datenbank und lässt die Anwender jeden Block einzeln interaktiv optimieren. Bei dem genannten Update bedeutete das für die Reparatur der unschön gewordenen Stellen eine größere Anzahl Interaktionen verbunden mit Wartezeiten beim jeweiligen Seitenaufbau.

Wechsel von Blockthemes

Ein weitere Nachteil der Speicherung von Layoutinformationen in der Datenbank statt in Dateien besteht darin, dass sich aus dem TwentyTwentyThree-Child nicht einfach ein TwentyTwentyFour-Child machen ließ. Bei den klassischen Themes blieben Eingaben im Customizer beim Wechsel des Themes erhalten. Eine vergleichbare übergreifende Einstellmöglichkeit ist bei den Block-Themes leider nicht vorhanden. In einfachen Worten:

• in Dateien lassen sich die Änderungen mit einem Editor vornehmen

• beim Customizer handelt es sich um einen Baustein, um für klassische Themes globale Einstellungen vorzunehmen, die in der Datenbank gespeichert werden

• bei Block-Themes werden die Informationen scheinbar Theme-spezifisch in der Datenbank abgelegt

Das nächste Album sollte ein eigenes individuelles Theme erhalten. Glücklicherweise hat WordPress etwa zeitgleich mit der Veröffentlichung der Version 6.4, also ca. 5 Jahre nach der ersten Veröffentlichung des Block-Editors, eine Dokumentations-Offensive hinsichtlich der Erstellung eigener Themes gestartet. Ich habe einen Online-Kurs absolviert, bei dem ich gelernt habe, dass klassische und Block-Themes letztendlich denselben Unterbau verwenden. Das Theme-Entwickler-Handbuch wurde ebenfalls mit Informationen zu Block-Themes angereichert. Lediglich die möglichen Varianten der HTML-Kommentare, in denen die Parameter der Blöcke gespeichert sind, bleiben undokumentiert.

Im Endeffekt lernt man, dass man als Layout-Entwickler klassische Themes so einrichten kann, dass sich jede einzelne Style-Angabe selbst vorgeben lässt. Im Gegensatz dazu ist ein Block-Theme nicht so weit reduzierbar, dass nur noch die allernötigsten Style-Informationen aus dem System kommen, wie z.B. ein display:flex; beim Bild-Text-Block. Schlimmer noch: selbst Brechpunkte für Media-Queries, also grob gesagt die Grenzen zwischen Smartphone und Tablet sowie Tablet und Desktop sind fest vorgegeben. Kleine Ergänzung: ein Jahr später sind wir bei Version 6.6 und der Bild-Text-Block gibt u.a. display:grid; aus.

Immerhin kann man das System so einrichten, dass sich auch bei Block-Themes die Systemvorgaben überschreiben lassen. Aber je mehr „Falsches“ aus dem System kommt, umso mehr muss durch Überschreiben repariert werden. Trotzdem sehe ich langfristig bei WordPress kein Vorbeikommen an Blöcken und dem Block-Editor.

Ich versuchte Klarheit zu bekommen, ob die Ergebnisse meiner Experimente zu den StyleSheet-Dateien in WordPress auch zukünftig Bestand haben werden. Leider habe ich sowohl im deutschen als auch im internationalen Forum keine zufriedenstellenden Antworten bekommen. Im Grunde genommen wurde mir das mitgeteilt, was man auch schon überall lesen kann. Es wurde darauf hingewiesen, wie toll das System eigentlich ist. Auf meine gewünschte Vorgehensweise, dass ich gerne transparente Dateien hätte, die ich einfach mit FTP auf den Server laden kann, wurde nicht eingegangen.

Es erwies sich als unerwartet schwierig, das eigene Theme so hinzubekommen, dass es zu den bisher verwendeten Themes passte. So erforderte es für eine gleich aussehende Fußzeile einen ziemlich hohen Aufwand, und ich empfand die nötigen Interaktionen als umständlich. Dazu trug auch die gewählte Struktur mit der Multisite-Installation bei. Durch diese verliert man leider Teile des Vorteils eines CMS, weil z.B. Menüerweiterungen in allen einzelnen Sites von Hand nachgezogen werden müssen. Das ist dann ähnlich wie früher, als in den einzelnen Dateien immer alle Rahmendaten synchron gehalten werden mussten.

So langsam schlich sich der Gedanke ein, dass es vielleicht von vorne herein günstiger gewesen wäre, Joomla! als CMS einzusetzen, da man dort jedem Artikel ein eigenes Template zuweisen kann. Ich begann mich also ernsthaft mit einem Systemwechsel zu beschäftigen.

Inhalte strukturieren

Als erstes fand ich heraus, dass Joomla! Inhalte in Kategorien und Beiträge aufteilt, im Gegensatz zu Seiten und Beiträgen bei WordPress. Bei letzterem gibt es zwar auch Kategorien, diese haben aber nur eine Ordnungsfunktion. Bei Joomla! hat man im Editor bei einer Kategorie (fast) dieselben Möglichkeiten wie bei Beiträgen, so dass sich Kategorien als Beiträge mit Unterbeiträgen einsetzen lassen. Günstig für mein Vorhaben erweist sich, dass dadurch die URLs der beabsichtigten Struktur entsprechen, indem eine Kategorie einem Album entspricht und ein Albumblatt in der URL erst den Namen der Kategorie und dann den Namen des Blattes hat.(Anmerkung: im Nachhinein fand ich noch kleine Einschränkungen, die zu einer anderen Vorgehensweise bei gleichen URLs führten).

Unterstützung für responsible Bilder

Ich hielt es für selbstverständlich, dass wenn ich ein eigenes Template schreibe, bei dem ich die Layoutdaten komplett vorgeben kann, es mir auch gelingen wird, ein responsives Design herzustellen. Wichtig war in diesem Zusammenhang die Frage, ob auch die Bilder responsiv werden, d.h. dass zu den Geräten nur die notwendige Bildgröße übertragen wird. Bei WordPress wurde diese Eigenschaft bereits vor einigen Jahren zusätzlich zu den schon immer vorhandenen drei Bildgrößen hinzugefügt, wobei die Nutzer keine neuen Einstellmöglichkeiten bekamen. In der Standard-Installation von Joomla! ist das nicht der Fall. Es gibt aber glücklicherweise eine Erweiterung namens „Responsive Images“, die die fehlende Funktionalität hinzufügt. Im Gegensatz zu WordPress lässt sich damit selbst einstellen, welche weiteren Bildgrößen abgeleitet werden sollen. Die freie Wahl des Kompressionsfaktors ermöglicht eine bessere Bildqualität. 

Zusatzfunktionen

Ein Plugin, dass ich bei WordPress schätze, ist der „Broken Link Checker“. Auch wenn es Autoren gibt, die davon abraten und „bessere“ Lösungen anbieten, ist es für Betreiber kleiner Seiten äußerst praktisch. Es überprüft regelmäßig, ob insbesondere externe Links noch existieren und man erhält eine Mail, wenn ein Ziel nicht mehr gefunden wurde. Günstigerweise gibt es dieses Plugin auch für Joomla.

Für ein Backup gibt es bei beiden Systemen kostenlose und bewährte Erweiterungen / Plugins. Bei anderen Funktionalitäten ist es so, dass es in einem System enthalten ist, im anderen wird eine Ergänzung benötigt.

Entscheidungsfindung

Dennoch tat ich mich einigermaßen schwer mit dem Gedanken, mich von einem System zu verabschieden, mit dem ich mehr als 10 Jahre Erfahrungen habe, und bei dem ich auch weiß, wie ich Systemfunktionalität erweitere und eigene Funktionen ergänzen kann. Auf der anderen Seite passt das flexiblere Design bei Joomla! besser zu meinen Anforderungen. Auch fand ich keine K.‑o.-Kriterien, wie z.B. bei Drupal.

Ich begann damit, eine Joomla! Testinstallation aufzubauen, in die ich Teile der bisherigen Inhalte übernahm, um ein Template zu erstellen, dass meinen Vorstellungen mehr entsprach, als ich in WordPress hatte umsetzen können. Das führte immer wieder zu Punkten, an denen ich aufgrund meiner begrenzten Joomla!-Kenntnisse an meine Grenzen stieß. So stand immer wieder der Gedanke im Raum, es doch weiter mit WordPress zu versuchen. Letztendlich waren die parallelen Experimente mit WordPress aber wieder so ernüchternd, dass der Gedanke zum Umstieg auf Joomla! die Überhand gewann.