WordPress 5.9: Umstellung auf Full-Site Editing


WordPress Full-Site-Editing

Das Content-Management-System WordPress wird seit 2019 von einem Drittel der Top 10 Millionen Webseiten weltweit genutzt. Und hier auf MarcTV. Seit einigen Releases liegt der Fokus des Open-Source Projektes auf Blöcken. Mit WordPress 5.9 werden damit nicht nur die Artikel, sondern die gesamte Seite gebaut. Das bedeutet, dass man die Seite statt mit Themes aus Blöcken oder einer Sammlung aus Blöcken („Patterns„) zusammenbaut. Und zwar mit dem Block Editor Gutenberg.

Demokratisierung der Webseitengestaltung

Den mächtigen Editor Gutenberg aus dem WordPress Core als „Klickibunti“ zu bezeichnen, grenzt an Blasphemie. Letztendlich gibt man dem Redakteur die Kontrolle über das Layout des Artikels und über die gesamte Seitengestaltung. Entwickler erstellen in Zukunft hauptsächlich Plug-ins, die Blöcke bereitstellen. Damit kann dann jeder Menschen ohne Vorkenntnisse von PHP, CSS oder Webseiten allgemein die Webseite umfassend gestalten.

Twenty-Twenty-Two statt einem angepassten Child Theme

In den 15 Jahren MarcTV habe ich immer mehr auf Standards gesetzt und dabei Code zurückgebaut. Somit waren meine Child Themes A Field of Flowers (2019) und Anor Londo (2017) ein Prozess zur Vereinfachung. Mit dem Block Thema Twenty-Twenty-Two verzichte ich auf den Einsatz eines Child-Themes. Dafür mussten Funktionen in Plug-ins umgewandelt werden, die Blöcke unterstützen. Das heißt, neben PHP musste ich mir React beibringen.

Gruppen in Gutenberg sind das Wundermittel

Viele Blöcke erlauben keine Anpassungen der Farben und Typografie. Steckt man sie in eine Gruppe, kann man Eigenschaften wie die Hintergrundfarbe plötzlich bequem anpassen. Selbst die Farbe der Links separat ist anpassbar.

Die Gutenberg Stile sind versteckt aber mächtig

Oben rechts im Editor ist ein Symbol, dass eher nach einem Schalter für einen Dark Mode aussieht. Jedoch steckt dahinter der Stile-Editor. Damit können weiter unten die Stile der einzelnen Blöcke angepasst werden. Anpassungen in Gutenberg im Artikel werden trotzdem bevorzugt. Beispiel: Die Submit-Buttons für das Kommentarformular können dort farblich angepasst werden. Oder die Farbe aller Überschriften. Für Letztere fehlt noch die Auswahl der Schriftfamilie. In WordPress 6.0 wird beides aber noch detailliert anpassbar sein.

Custom CSS ist noch erlaubt

Die WordPress Funktion „Zusätzliches CSS“ wurde uns nicht genommen. So kann man trotzdem schnell mal für alle Überschriften im Artikelbereich mit den CSS Variablen von Twenty-Twenty-Two die Schriftart ändern. Man muss ja nicht päpstlicher als der Papst werden.

.entry-content h1,
.entry-content h2, 
.entry-content h3,
.entry-content h4,
.entry-content h5 {
  font-family: var(--wp--preset--font-family--system-font);
}

Ich sprüh's auf jede Wand
Ich sprüh’s auf jede Wand

Neue Blöcke braucht das Land

Einige Funktionen im Blog hatte ich bereits als Plug-in ausgelagert. Nun mussten diese auch als Block im Full-Site Editing funktionieren. Dabei ist die Entwicklung von WordPress Entwicklung mit React deutlich komplexer als nur mit PHP. Plötzlich findet man sich in einer Welt mit JSX und Build-Prozessen wieder.

Mein erstes Block Plugin SimpleTOC nutze ich weiterhin für die Inhaltsverzeichnisse. Das ist auch bislang das einzige Plug-in, dass noch andere Leute außer mir nutzen.

Auf der Startseite werden unten zufällige Spieletitel angezeigt, zu denen es hier im Blog einen Review gibt. Und die Liste der Top 100 Spiele ist genau so Block wie die Reviewbox am Ende eines Artikels.

Auch die Darstellung der ähnliche und neuen Artikel am Ende eines Artikels musste nun auch als Block funktionieren und war eine Neuentwicklung in Absprache mit dem Entwickler des Elternplugins YARPP.

Ein kleines aber für mich wichtiges Detail ist die Liste der zuletzt kommentierten Artikel unten im Footer. Mein Plugin listet bewusst nicht die letzten Kommentare und verlinkt deswegen keine Artikel doppelt.

Änderungen gehen nun schnell

Was vorher Änderungen am Template oder Anpassungen am Template bedeutet hat, ist nun ein Klick entfernt. Die Lernkurve ist Steil weil alles aufeinander aufbaut. Nur eine Stunde am Abend hat das Zusammenklicken gedauert.

Auswirkungen auf die Core Web Vitals

Webseiten müssen auf jeden Gerät gut lesbar sein und rasant laden. Google fasst das als Core Web Vitals zusammen. Vorher hatte ich im Chrome Lighthouse Test durch diverse Tweaks in allen Bereichen die volle Punktzahl von 100. Das erreiche ich mit dem jungfräulichen Twenty-Twenty-Two Theme nicht mehr. Allerdings liegen die Werte alle im sprichwörtlich grünen Bereich. Wenn ich mir dann die Warnmeldung „Avoid an excessive DOM size“ anschaue, habe ich sogar meinen Frontend-Mentor Nico Brünjes im Ohr: „DIV-teritis“. Denn die Kehrseite von Flexibilität ist die damit verbundene Komplexität.

Full-Site Editing mit Gutenberg ist die Zukunft

Als WordPress den klassischen WYSIWYG-Editor gegen Gutenberg ersetzt hat, war wahrscheinlich jeder WordPress Nutzer skeptisch. Mich eingeschlossen. Aber was zum Standard im Core geworden ist, sollte man meiner Meinung nach umarmen. Sonst verbiegt man sich und die Software. Nun sind wir mit Full-Site Editing erst in der zweiten Phase von insgesamt vier:

Meiner Ansicht nach wurde der wichtigste Schritt nun getan. Das Konzept funktioniert und ist die Zukunft für WordPress. Glückwunsch an das gesamte WordPress 5.9 Projektteam! Solche Entscheidungen in einem Open-Source-Projekt mit Menschen auf der ganzen Welt umzusetzen ist etwas, auf das die Beteiligten stolz sein dürfen. Und die haben schon lange vor Covid-19 in „Heimarbeit“ entwickelt. Da kann man einiges lernen.


Beitrag veröffentlicht

in

von

Kommentare

4 Antworten zu „WordPress 5.9: Umstellung auf Full-Site Editing“

  1. Avatar von ben_
    ben_

    Ich hab mir das latürnich auch angesehen, bin bisher aber nur mässig begeistert. Gutenberg war als Artikel- und Landingpage-Editor schon in einer Dimension abstrakt, die für viele Nicht-Programmierer ein Level zu hoch ist. Die jetzige Abstraktion ist ohne Programmierkenntnisse zwar bedienbar, aber ich bezweifele, dass viele Nicht-Programmierer a) verstehen, was sie da tun und b) mit den Ergebnissen glücklich werden.

    Viel schlimmer aber ist die Verlagerung von tragenden Säulen einer Site, raus aus dem Code, rein in die Datenbank (oder absurde Textdateien). Das atomisiert nachhaltig die meisten Versuche eine professionelle Qualitätsicherung zu machen und vervielfacht die Aufwände in der Entwicklung. Das wird echt noch einiges an Zeit und eigene Arbeit brauchen, bis die Entwicklungen von 5.9 sich als Vorteil im Agenturalltag herausstellen. Befürchtungsweise bleibt es ein Pain-in-the-Allerwertestens.

    1. Avatar von ben_
      ben_

      Ah und … ich bezweifele auch, dass das selbst für alle Endbenutzer das ist, was sie wollen. Die definierte Anmutung und Meinung, die ein eigenes, richtiges Theme bedeutet, ist halt ein Wert an sich. Ich sehe schon Gespräche vor mir der Art …
      „Und wie sieht das dann aus?“
      „Na, wie immer Du willst.“
      „Toll! Aber darunter kann ich mir nichts vorstellen.“
      „Du musst Dir einfach nur alles zusammenklickern. Da bitte!“
      „Äh …“

      Weisste, was ich meine … der Gestaltungspielraum, den Full-Site-Editing (und weite Teile von Gutenberg zuvor schon) bietet, ist a) mehr als die meisten Leute wollen und b) führt bei nicht-diszipliniertem Umgang mit allen Werkzeugen zu Augenkrebs. Selbstverwirklichung durch Laientypographie. Webseiten werden die neuen Word-Dokumente und Powerpoint-Präsentationen …

    2. Avatar von Marc
      Marc

      Ah, schön, dass du was schreibst. Danke ben_ Denn was für mich nur noch ein Hobby ist, betrifft euch ja direkt als Agentur. Wie immer im Leben ist das ja nicht alles schwarz-weiß. Der Artikel war natürlich bewusst sehr Pro-Gutenberg und FSE, weil es sonst langweilig wird. Normale Themes und Plug-ins können ja weiterhin genutzt werden und jede Agentur kann ihre Kundenprojekte so umsetzen, wie sie will.

      Und ja, Augenkrebs ist vorprogrammiert. Im wahrsten Sinne des Wortes. Ich bin gespannt, was Leute aus Twenty-Twenty-Two mit Pattern so herausholen. Ich bin in dieser Hinsicht leider leidenschaftslos geworden. Je näher man an die „Reader“-Ansicht von iOS kommt, desto besser ist es in meinen Augen.

      Ich denke trotzdem, dass sich die Nutzer schnell daran gewöhnen, vorhandene Blöcke, Gutenberg Site-Templates und Patters zu nutzen. Ich denke nicht, dass sie das von 0 aufbauen werden. Weder der absolute Laie noch Personen, die in Redaktionen sitzen, werden sich eine brandneue Homepage oder „Centerpage“ oder „Landingpage“ zusammenstellen in einem leeren Template aufbauen. Aber sie wollen sie verändern. Und da ist Gutenberg, denke ich, ziemlich gut und besser als das, was andere Lösungen so bieten. Man kann überall so tief hereingehen, wie man möchte und visuell, aber auch inhaltlich Änderungen vornehmen. Sprich: Eigene Lösungen müssen zukünftig vielleicht zumindest Gutenberg unterstützen.

      Um ehrlich zu sein, hätte ich gedacht, das zahlt voll auf die Grid-Idee ein. (Übrigens ein cooler Produktname. Fast so gut wie Tinkas „Battlecat“ für den Katzenbaum) Nur, dass „Grid“ nun eben im Core ist. Das HTML ist natürlich nicht ansatzweise so sauber wie der Containeransatz. Dafür ist der Editor sehr mächtig und man hat die Community hinter sich.

      Aber bevor der falsche Eindruck entsteht: Was ich hier denke oder nutze ist natürlich nicht relevant. Wichtig ist, wie Profis wie ihr das in Zukunft einbindet oder auch nicht. Und vor allem wie die Nutzer das alles finden. Immerhin ist das Plug-in, um Gutenberg zu entfernen und wieder „Classic“ zu nutzen, sehr beliebt.

  2. Avatar von Marc
    Marc

    Seit dem Wochenende nutzt nun auch die Startseite das Full-Site-Editing.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert