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.

Manche Funktionsbezeichnungen lassen Interpretationsspielraum, wo besser keiner sein sollte. Die WordPress-Funktion “is_admin()” ist so ein Fall, denn wie die WordPress Code Refernce erklärt

Does not check if the user is an administrator

“is_admin()” prüft lediglich, ob der Aufruf innerhalb der Administrations-Oberfläche erfolgte. Wer sich für die tatsächlichen Berechtigungen des angemeldeten Benutzers interessiert, sollte “current_user_can()” verwenden.

Problematisch bei Beiträgen zu Technik ist, daß sie meist ein Verfallsdatum haben. Was heute prima funktionert, kann bereits in der nächsten Softwareversion entweder an ganz anderer Stelle versteckt sein oder wurde komplett gestichen. So häufen sich auch hier im Blog die Kommentare von Lesern, die übersehen, daß ein mit “Windows 7” gekennzeichneter Beitrag unter Windows 10 wohl nur noch durch Zufall so nachvollziehbar sein wird.

Aus diesem Grund wird nach und nach in älteren Beiträgen ein entsprechender Hinweistext eingebaut. Um nicht die Beitragstexte selbst ändern zu müssen, wird dies über ein paar Zeilen Code in der “functions.php” realisiert:

Der Code richtet einen Wordpress-Filter ein, der jedesmal, wenn der Inhalt eines Beitrags über die Funktion “the_content” angefragt wird, den Beitragsinhalt vor Verwendung durch die Funktion “outdated_notification” schickt.

Diese prüft zuerst, ob es sich um eine Einzeldarstellung des Beitrags handelt (“is_single()”) und im Erfolgsfall, ob für den Beitrag das Feld “veraltet” gesetzt wurde. Ist dies der Fall, wird ein HTML-Paragraph mit einem Hinweistext vor den Beginn des eigentlichen Beitragsinhalts gestellt.

Der oben skizzierte Code funktionert allerdings nur, solange der Inhalt über die Funktion “the_content” angefragt wird. Wird vom gewählten Thema hingegen die Funktion “get_the_content” verwendet, ist etwas mehr Bastelarbeit notwendig, denn hier sind keine Filter vorgesehen.

Standardmäßig speichert WordPress neben dem eingegebenen Kommentar auch die IP-Adresse, von welcher der Kommentar übermittelt wurde.

Diese Speicherung lässt sich durch Einsatz eines Filters deaktivieren. In der “functions.php” des Themes die Zeilen

hinzufügen, damit bei allen neuen Kommentaren statt der tatsächlichen IP-Adresse des Autors die Adresse “localhost” gespeichert wird.

Sofern bereits Kommentare in der WordPress-Datenbank vorhanden sind, werden diese durch das Hinzufügen des Filters nicht geändert. Hier hilft ein SQL-Statement:

Standardmäßig setzt WordPress beim Absenden eines Kommentars ein Cookie, welches als Komfortfunktion die eingegebenen Daten (i.d.R. Name und E-Mail-Adresse) des Kommentierenden enthält und fügt diese Daten in allen weiteren Kommentarfeldern als Vorbelegung ein.

Dank der Hooks und Actions in WordPress ist die Deaktivierung des Cookies schnell erledigt:

In der “functions.php” des Themes die Zeile

hinzufügen und schon wird beim Kommentieren kein Cookie mehr gesetzt.