Wird die vollständige Seitenbearbeitung in WordPress 5.8 landen? Eine Entscheidung steht bevor

Gestern hat Josepha Haden Chomphosy die Roadmap für die Entscheidung, ob Full Site Editing (FSE) in WordPress 5.8 landen wird, bekannt gegeben. Nach dem Start von Gutenberg 10.4 am 14. April wird eine kleine Gruppe von Kern-Leads an einer Go/No-Go-Demo teilnehmen.

Folgende Personen werden telefonieren:

• Matias Ventura – Gutenberg-Projektleiter, der die Demo moderieren wird.
• Matt Mullenweg – WordPress-Projektleiter.
• Helen Hou-Sandi – Leitende Entwicklerin.
• Josepha Haden Chomphosy – Geschäftsführerin.

Die Tagesordnung des Treffens ist einfach. Ventura wird die Demo hosten und die Gruppe wird Implementierungsfragen diskutieren und behandeln.

Wenn es keine Blocker gibt, teilen sie einen Plan für die Zusammenführung von FSE mit WordPress. Das wahrscheinlichere Ergebnis ist, dass sie zumindest einige Punkte finden, die angegangen werden müssen. In diesem Fall werden sie diese öffentlich mit einem Plan teilen, sie vor einem zweiten Go/No-Go-Datum am 27. April anzugehen.

Die erste Beta-Version von WordPress 5.8 ist für den 8. Juni geplant, mit einer allgemeinen öffentlichen Veröffentlichung für den 20. Juli. Das Team muss früh im Veröffentlichungszyklus über die Aufnahme entscheiden, um den Entwicklern von Themes und Plugins Zeit zur Vorbereitung zu geben.

Während viele auf eine endgültige Entscheidung warten, müssen sich im Moment alle noch etwas gedulden. Alles muss von den Projektleitern sorgfältig abgewogen werden. Es besteht eine gute Chance, dass wir das Ergebnis nicht vor dieser zweiten Frist, dem 27. April, erfahren werden.

Der größte Teil des FSE-Übergangs wäre ein Beta-Lauf für eine Untergruppe von Benutzern. Das Einbeziehen dieser Funktionen in den Kern bedeutet nicht, dass WordPress sofort den Schalter umlegt und alles für 40 % des Webs ermöglicht. Für die gesamte FSE-Erfahrung müssen Benutzer eine explizite Entscheidung treffen, ein blockbasiertes Design zu installieren und zu aktivieren.

Vor diesem Hintergrund sollte die Onboarding-Erfahrung einladend sein, die Benutzer zur Bearbeitung der Website einlädt und sie gleichzeitig über mögliche Probleme informiert. Wenn es sich um eine integrierte Beta handelt, müssen sie wirklich verstehen, dass Verbesserungen bevorstehen.

Ein solcher In-Core-Beta-Lauf ist auch willkommen, da das Projekt vor ein paar Jahren den Blockeditor gestartet hat. Unabhängig davon, ob die Leute den Blockeditor liebten oder hassten, der Rollout verlief nicht für alle reibungslos. WordPress ließ Endbenutzer in ein überarbeitetes System fallen, was für viele eine schockierende Veränderung war. Das Projekt hat diesmal die Chance, es besser zu machen, indem es den Benutzern schrittweise Funktionen einführt und es anderen ermöglicht, in die neue Erfahrung ihrer eigenen Wahl einzutauchen.

„Der wichtigste Kontext, den es zu teilen gilt, ist, dass es nicht als vollständige Standarderfahrung für Benutzer bereitgestellt wird“, schrieb Chomphosy in dem Beitrag und stellte fest, dass das Team über vergangene Fehler hinauswächst. „Eines der deutlichsten Rückmeldungen aus dem Zusammenführungsprozess von Phase Eins war, dass unsere Extender (Agenturen, Themenautoren, Plugin-Entwickler, Website-Ersteller usw.) nicht genügend Zeit hatten, sich auf die bevorstehenden Änderungen vorzubereiten.“

Die Entscheidungsträger können auch entscheiden, einige Teile zu versenden, andere jedoch nicht. FSE ist ein Projekt, das aus mehreren Komponenten besteht.

„Das gesamte Full-Site-Editing-Projekt ist eine Art Überbegriff für eine Sammlung von Tools und Projekten, daher wäre es möglich, dass einige Teile ausgeliefert werden, andere jedoch nicht“, sagte Haden Chomphosy. „Wie Sie bereits erwähnt haben, gibt es wahrscheinlich einige Ausnahmen, aber viele davon können versendet werden, sobald sie bereit sind.“

Die Ausnahmen, auf die sie sich bezog, sind Komponenten, die zusammen mehr Sinn ergeben. Beispielsweise sind blockbasierte Designs über eine theme.json -Konfigurationsdatei und die meisten Website-Bearbeitungsblöcke nicht so nützlich, wenn sie getrennt sind.

Natürlich gibt es Fälle, in denen so etwas wie der Abfrageblock außerhalb des Website-Editors verwendet werden könnte. Benutzer können beispielsweise benutzerdefinierte Abfragen innerhalb einer Seite ohne die Vorteile des Website-Editors erstellen.

Mein Hauptaugenmerk liegt nicht auf Funktionen im Zusammenhang mit dem Site-Editor, sondern auf blockbasierten Widgets. Es ist ein Übergangstool für Benutzer mit traditionellen Themen. Zusammen mit dem neuen Navigationsmenübildschirm ist es nicht Teil des blockbasierten Themenerlebnisses. Das Ziel ist es, Benutzern zu ermöglichen, Blöcke an mehr Stellen zu verwenden. Dies führt jedoch in vielen Fällen zu einer fehlerhaften UX.

Die Widgets-Erfahrung ist immer noch teilweise defekt und behandelt jeden Block als separates Widget. Benutzer müssen lernen, eine Überschrift (Widget-Titel) und einen weiteren Block (Widget-Inhalt) in eine Gruppe (Widget-Wrapper) für die richtigen Widget-bezogenen Klassen am Front-End der Website einzufügen. Bei einigen Themen ist es kein Problem, ob Benutzer dies tun. Für andere sieht es bestenfalls hässlich aus und stört im schlimmsten Fall das Layout. Diese Verantwortung auf die Schultern der Endnutzer zu legen, wurde als akzeptable Lösung angesehen.

Ich wollte mich auf dieses Problem konzentrieren, da es eines der Dinge ist, die einfach für alle Benutzer aktiviert werden können. Ich habe immer noch Angst, dass der Übergang von einem funktionierenden System zu einem möglicherweise kaputten System zu einer holprigen Fahrt wird.

Das Release-Team von WordPress 5.6 hat entschieden, keine blockbasierten Widgets auszuliefern. Hou-Sandi lieferte als Core Tech Lead für 5.6 einen historischen Bericht über die Entscheidung und warum sie nicht bereit für die Aufnahme war:

Meine Frage zu Funktionen, die sich auf das Frontend auswirken, lautet: „Kann ich dieses neue Ding ausprobieren, ohne meine Website zu beschädigen?“ – das heißt, Benutzervertrauen. Angesichts der Tatsache, dass Widget-Bereiche zum jetzigen Zeitpunkt nicht so angezeigt werden, wie Sie es auf Ihrer Website sehen, ohne dass Themes wirklich Mühe darauf verwenden, und dass Sie Ihre Änderungen ohne Überarbeitungen live speichern müssen, um eine tatsächliche kontextbezogene Ansicht zu erhalten, tun Widget-Bereichsblöcke dies nicht ermöglichen es Ihnen, diese neue Funktion auszuprobieren, ohne Sie für das Experimentieren zu bestrafen.

Obwohl sich die Widgets wohl verbessert haben, sehe ich die Antwort immer noch als die gleiche wie im letzten Oktober. Ich habe nicht genug Zuspruch von der Theme-Entwickler-Community gesehen, um den Blockeditor selbst zu unterstützen, geschweige denn neue blockbezogene Funktionen. Irgendwann muss das Projekt jedoch einfach vorankommen. Themer müssen nur mithalten.