Gutenberg respektiert die von einem CPT deklarierte Editorunterstützung und wird nicht geladen, wenn dies nicht unterstützt wird.

Wenn dies bedeutet, dass Gutenberg überhaupt nicht geladen wird und stattdessen der Classic-Editor verwendet wird, führt uns das auf einen Weg zu einem zersplitterten WP-Administrator, der zwischen Gutenberg- und Classic-Umgebungen aufgeteilt ist. Dies wäre in vielerlei Hinsicht schlecht für WordPress.

• Neue Benutzer müssten die wichtigsten und subtilen Arten lernen, in denen sich die beiden Arten von Schnittstellen unterscheiden. So einfache Aktionen wie das Veröffentlichen eines Beitrags oder das Wechseln zur Textansicht funktionieren in Gutenberg- und Classic-Editoren unterschiedlich.

• Bestehende Entwickler wären gezwungen, die Funktionalität ihrer Themes und Plugins in beiden Umgebungen aufrechtzuerhalten. Wir sprechen hier nicht von einer Übergangszeit; wir reden auf unbestimmte Zeit. Plugins, die jeden Beitragstyp erweitern sollen, wären am stärksten betroffen. Wenn diese Entwickler ihre Meta-Boxen in Blöcke umwandeln, müssen sie die alten Meta-Boxen immer noch beibehalten, falls jemand ihr Plugin in einem Nicht-Gutenberg-Posttyp verwendet.

• Neue Plugin-Entwickler, die in die WordPress-Entwicklung einsteigen, müssten lernen, wie man Plugins auf zwei verschiedene Arten erstellt. Angenommen, sie umfassen Gutenberg-Blöcke, ihre Plugin-Funktionalität ist möglicherweise nicht einmal in Beitragstypen mit dem Classic-Editor verfügbar.

So sehr ich glaube, dass wir Metaboxen zum Laufen bringen müssen, Gutenberg einfach abzuschalten ist auf lange Sicht nicht die beste Lösung.

Wenn dies bedeutet, dass Gutenberg überhaupt nicht geladen wird und stattdessen der Classic-Editor verwendet wird, führt uns das auf einen Weg zu einem zersplitterten WP-Administrator, der zwischen Gutenberg- und Classic-Umgebungen aufgeteilt ist.

In den Fällen, in denen ein CPT den Editor überhaupt nicht aktivieren möchte, scheint dies der beste Weg zu sein. Es ist einfach eine andere Administratoransicht, die für eine andere Erfahrung optimiert ist. (Die "Bestellungen"-Ansicht von Woo zum Beispiel.) Es würde niemandem helfen, zu versuchen, diese im Gutenberg-Kontext zu rendern.

Es ähnelt dem Aufkommen des Customizers – es war ein neues Schnittstellenparadigma, das einige der gleichen Dinge in einem anderen Kontext tat. Wir werden immer eine „Verwaltungs“-Schnittstelle und eine „Bearbeitungs“-Schnittstelle brauchen. Auf diese Weise kommen wir teilweise voran, indem wir die unterschiedlichen Zwecke von Schnittstellen klären.

Aber wegen Gutenbergs Scope Creep geht es nicht nur darum, den Editortyp zu aktivieren oder zu deaktivieren. Da Gutenberg nun die gesamte Bearbeitungsoberfläche bestimmt, gibt es eine ganze Liste von Nebenwirkungen, die mit dem oben aufgeführten Editor-Typ verbunden sind.

Wir werden immer eine „Verwaltungs“-Schnittstelle und eine „Bearbeitungs“-Schnittstelle brauchen.

Genau diese Rollen erfüllen heute der Editor und die Metaboxen. Sie sind keine isolierten Erfahrungen. Sie arbeiten zusammen.

dann sollte vielleicht das Scope Creep angegangen werden, und Gutenberg sollte auf den von wp_editor() bevölkerten Bereich beschränkt werden. Es würde sicherlich viele Kompatibilitätsprobleme lösen.

Zielfernrohrkriechen

Die Bekämpfung des Scope Creeps ist meine Vorliebe und etwas, das viele von uns in den letzten Monaten gefordert haben. Dies würde es uns ermöglichen, den Editor zu verbessern, ohne die Admin-Erfahrung aufzuteilen.

Aktivieren von Gutenberg pro Beitragstyp

In Bezug auf die Möglichkeit, Gutenberg pro Beitragstyp zu deaktivieren, möchte ich betonen, dass die Vermeidung des Problems nicht dasselbe ist wie das Erreichen einer Lösung. Das Abschalten von Gutenberg pro Post-Typ kann die Inkompatibilität der Meta-Box für einige Plugins vermeiden, aber es schadet der WordPress-Landschaft auf lange Sicht.

Wenn Sie nicht sehen können, warum, stellen Sie sich vor, in zwei Jahren, nachdem Gutenberg fusioniert wurde, ein neuer Plugin-Entwickler zu sein, der in die Branche einsteigt.

• Schreiben Sie als Entwickler Ihre Plugin-Benutzeroberfläche als Block oder als Meta-Box? Wenn Sie alle Beitragstypen unterstützen möchten, müssen Sie beides schreiben.
• Ist sich ein Benutzer bei der Suche nach Plugins bewusst, dass die von Ihnen auf Ihrer Plugin-Seite versprochene Funktionalität nur in Gutenberg-aktivierten Beitragstypen funktioniert? Werden sie enttäuscht sein, wenn sie herausfinden, dass sie ihn nicht zusammen mit dem Classic-Editor verwenden können?
• Wenn derselbe Benutzer Sie um Unterstützung kontaktiert, wissen Sie, ob er fragt, wie Ihr Plugin im Classic-Editor oder im Gutenberg-Editor funktioniert. Kennt dieser Kunde überhaupt den Unterschied?
• Wenn Sie Monate nach dem Start Funktionen hinzufügen möchten, sind Sie dann bereit, Ihre Entwicklungszeit zu vervielfachen, um diese Funktionalität sowohl in die PHP-Metabox als auch in den JS-Block zu integrieren?

Dies sind nur einige der Fragen, die die Landschaft durcheinander bringen, wenn wir mit zwei Editoren und keinem Weg zur Singularität in der Benutzeroberfläche vorankommen.

show_in_rest

Die Tatsache, dass Posts Gutenberg nicht verwenden können, wenn show_in_rest nicht festgelegt ist, ist nur ein weiteres Beispiel für eine nicht verwandte Funktionalität, die sich auf die Bearbeitungserfahrung auswirkt. Es gibt keinen Grund, warum meine Präferenz für die Sichtbarkeit öffentlicher Beiträge in der REST-API sich darauf auswirken sollte, welche Schnittstelle ich beim Bearbeiten verwende. Ich verstehe die technischen Gründe, aber die Logik ist nicht vorhanden, und ich vermute, dass viele Entwickler sich nicht einmal bewusst sind, dass dies zu diesem Zeitpunkt eine Einschränkung ist.

Wie Gutenberg jemals den Geltungsbereich der wp_editor()-Parameter verlassen hat, verblüfft mich immer noch. Wenn der Gutenberg-"Editor" auf wp_editor() beschränkt wäre, dann wird die "Aktivierung als Option" pro Beitragstyp Realität und in Zukunft viel überschaubarer und erweiterbarer. Ich habe immer noch keine rationale Erklärung dafür gesehen, warum Gutenberg-Scope Creep nicht zurückskaliert und einfach in wp_editor() enthalten sein kann.

Es macht keinen Sinn, dass Gutenberg für benutzerdefinierte Beitragstypen aktiviert wird, die den Editor nicht verwenden und die nicht direkt im Frontend angezeigt werden.

Ich habe verschiedene Websites gesehen, auf denen CPTs nicht nur für echte Beitragstypen verwendet werden, sondern auch als Methode zum Erstellen von Admin-Schnittstellen für verschiedene Einstellungen und Elemente.

Zum Beispiel hat eine Autoren-Site, an der ich gearbeitet habe, CPTs für "Bücher" und "Shop-Links". Gutenberg als Redakteur für die Seiten mit den Büchern zu haben, ist absolut sinnvoll. Aber "Shop-Links" haben keine eigenen Beiträge oder Seiten, sondern werden verwendet, um die Logik für Links zu Online-Buchhandlungen auf jeder "Buch"-Seite bereitzustellen. Die Seitenvorlage Bücher zeigt Shop-Links zu Produktseiten an, die der Region (z. B. Großbritannien, USA) und dem Format (z. B. E-Book, Print) entsprechen, und fügt die in einem Post-Metafeld gespeicherte ISBN in die URL-Struktur jedes Online-Shops ein – siehe Screenshots.

CPTs sind vielleicht nicht die beste Möglichkeit, diese Art von Daten und Einstellungen zu verwalten, aber es gibt viele Websites, die verschiedene Funktionen mit Editor-losen CPTs und benutzerdefinierten Metafeldern zusammengefügt haben - ich könnte andere Beispiele für diese Art der Verwendung geben. Es wäre verwirrend und kontraproduktiv, den Gutenberg-Editor auf CPTs aufzuzwingen, die den Editor überhaupt nicht verwenden.

Es macht keinen Sinn, dass Gutenberg für benutzerdefinierte Beitragstypen aktiviert wird, die den Editor nicht verwenden und die nicht direkt im Frontend angezeigt werden.

Nein, es macht keinen Sinn, aber solange Gutenberg ein Vollbild-Ersatz ist, hat die Entscheidung, Gutenberg aufzunehmen oder auszuschließen, größere Auswirkungen, die darüber hinausgehen, ob Sie einen Editor in Ihrem Beitragstyp wünschen oder nicht.

Stellen Sie sich zum Beispiel vor, Sie sind ein Plugin-Entwickler und möchten, dass Ihre Metabox "Shop-Link-Einstellungen" in einem Beitragstyp verfügbar ist, der Gutenberg verwendet, und einem zweiten Beitragstyp, der dies nicht tut. Wenn Sie ein Plugin an Tausende von Benutzern verteilen, die erwarten, dass es mit jedem Beitragstyp funktioniert, haben Sie nicht den Luxus, sich zu entscheiden. Dann kommen die in https://github.com/WordPress/gutenberg/issues/3330#issuecomment -341867663 genannten Fragen ins Spiel.

Es ist erwähnenswert, dass Metaboxen, die innerhalb ihres eigenen Posttyps isoliert sind, am wenigsten von Gutenberg betroffen sind.

Ja, ich kann sehen, dass Plugins, die sowohl Gutenberg- als auch Nicht-Gutenberg-Schnittstellen unterstützen müssen, ein großes anhaltendes Problem darstellen.

Ich denke, die Frage ist dann, wie Gutenberg mit CPTs umgehen sollte, die den Editor nicht unterstützen - wie funktioniert Gutenberg in Kontexten, in denen es keinen Sinn macht, eine Seite aus Blöcken zu erstellen, wo es nur Meta-gesteuert ist?

... wie Gutenberg mit CPTs umgehen sollte, die den Editor nicht unterstützen - wie funktioniert Gutenberg in Kontexten, in denen es keinen Sinn macht, eine Seite aus Blöcken aufzubauen, wo es nur Meta-gesteuert ist?

Wenn Gutenberg zurückfahren und nur den Editor ersetzen sollte, wie im Yoast-Konzept, das ich in https://github.com/WordPress/gutenberg/issues/3304#issuecomment -341474018 erwähnt habe, dann wird das Aktivieren oder Deaktivieren von Gutenberg ziemlich einfach.

• Wenn editor aktiviert ist, ist der Blockeditor vorhanden und Metaboxen können je nach verwendeten Hooks darüber oder darunter erscheinen.
• Wenn editor deaktiviert ist, fehlt der Blockeditor und die Metaboxen gleiten nach oben, um die primäre Schnittstelle für den Beitragstyp zu werden.

So funktioniert es heute im Wesentlichen, und durch Beibehaltung dieses Verhaltens könnten Plugins Meta-Boxen schrittweise in Blöcke umwandeln, wenn dies sinnvoll ist. Es würde auch viele der oben aufgeführten verwirrenden Fragen vermeiden, die mit einer geteilten Admin-Erfahrung verbunden sind.

Ich finde "Scope Creep" angesichts des Kickoff-Posts und des Segens, den das Projekt erhalten hat , ein seltsamer Begriff. Es ist abwertend für die Arbeit, die bereits seit dem 11. Januar in der Öffentlichkeit geleistet wurde, als wir begannen, zu diskutieren und zu recherchieren, wie die Bearbeitungserfahrung insgesamt verbessert werden kann . Uns ist nichts eingefallen, das war immer der Plan, und deshalb gibt es keine feste Bezeichnung für den Fokus.

Sei es wie es sei, ich mag ein wenig über die Design - Der Status Quo ist der einfache Ausweg, aber nicht immer der richtige.

Das Hinzufügen von Blöcken zum bestehenden Editor, ohne den Ablauf zu überdenken, hätte die Komplexität erhöht, wo bereits Komplexität vorhanden war .

Angesichts des Mandats – Post-Authoring zu überdenken, um Blöcke zum Ersetzen von Shortcodes, benutzerdefiniertem HTML, Widgets und mehr einzubeziehen – würde ich meine Verantwortung als Designer vergeuden, indem ich nicht den gesamten Schreib-, Bearbeitungs- und Veröffentlichungsfluss ganzheitlich betrachte.

Ich bin nicht überzeugt, dass WordPress in fünf Jahren relevant sein wird , es sei denn, das Projekt als Ganzes unternimmt mutige Schritte, um die Zukunft zu meistern. Ein JavaScript-Kern wird seit Jahren auf Keynotes von State of the Word beworben. In Anbetracht dessen und der Möglichkeit, das Authoring von Rich-Post-Inhalten radikal zu vereinfachen, ist es nicht nur eine Chance, die gesamte Bearbeitungserfahrung anstelle eines winzigen Fensters zu betrachten, sondern es wäre trotz der damit verbundenen Herausforderungen wohl fahrlässig, anders zu designen damit.

Es ist unmöglich, einen guten Editor zu entwerfen, ohne den gesamten Bildschirm zu betrachten . Dies ist unbequem, erschwert das Projekt und macht es angesichts des Erbes von WordPress noch schwieriger. Es war nicht einfach, und wir haben noch einen Weg vor uns, insbesondere wie Gutenberg nativ erweitert werden kann. Aber einen halben Schritt zu machen, Gutenberg so aufzubauen, dass es nur den Inhaltstextbereich ersetzt, wäre ein großer Bärendienst für WordPress und ein schlechtes Design obendrein.

Das Laden einer Komponente von Gutenberg , nur des Editor-Canvas, in den aktuellen Bearbeitungsbildschirm ist möglich. Es wird eine stark kompromittierte Erfahrung und eine Frankenstein-Benutzeroberfläche sein, aber es kann ein Weg sein, den es zu erkunden gilt, um einen guten Migrationspfad von 4.9 auf 5.0 sicherzustellen. Es sollte jedoch klargestellt werden, dass dies weder die Aktienerfahrung noch die optimale ist.

Ich denke, die Frage ist dann, wie Gutenberg mit CPTs umgehen sollte, die den Editor nicht unterstützen - wie funktioniert Gutenberg in Kontexten, in denen es keinen Sinn macht, eine Seite aus Blöcken zu erstellen, wo es nur Meta-gesteuert ist?

@CalebWoodbridge so funktioniert es bereits. Siehe: https://github.com/WordPress/gutenberg/blob/master/lib/register.php#L290

Ich möchte darauf hinweisen, dass die Verwendung des Begriffs „Scope Creep“ nicht korrekt ist. Es ist ein Begriff, der sicherlich nicht auf ein Projekt zutrifft, das das tun soll, was Gutenberg ist.

Verzeihen Sie, dass ich dazu einen Seitenpunkt nehme, aber ich denke, es ist erwähnenswert. So wie Entwicklern Respekt entgegengebracht wird, wenn sie etwas Technisches sagen, denken Sie auch an die Designer. Die Designer, die an diesem Projekt arbeiten, haben viel Erfahrung und Können, ich respektiere die Arbeit zutiefst und es ist eine Freude, der Designleiter eines Projekts mit so großartigen Designern zu sein.

Ich fühle mich geehrt, die Gelegenheit zu haben, mit den Designern von Gutenberg zusammenzuarbeiten. Es ist ein tägliches Vergnügen und etwas, das wir in WordPress nicht immer bekommen. Als Designer im Kern ist man die meiste Zeit ein Einzelgänger, es war unglaublich, zusammenzuarbeiten.

Die Erfahrung ist der Schlüssel, wenn wir den Designansatz betrachten. @jasmussen in der ursprünglichen Vision bildete zusammen mit @matias den Grundstein für ein umfassendes Erlebnis. Als zweiter Design-Lead war es etwas, das ich schätze und bewahren möchte.

Eines der großen Probleme mit WordPress in der Vergangenheit aus Designperspektive war eine Spirale kleiner Iterationen über kleine Iterationen. Während es für die ersten paar funktioniert, summiert es sich im Laufe der Zeit zu einer Erfahrung, die mit Patches von Verbesserungen zusammengehalten wird. Es gibt viele WordPress, die darunter leiden. Editor ist das eine, Medien das andere und es gibt noch viel mehr, auf das man verweisen kann.

Gutenberg hat uns Raum gegeben, die Patches zu entfernen, zu schauen, was wir haben und wieder aufzubauen. Es hat uns als Ergebnis den Beginn einer starken visuellen Sprache gegeben, um in die Anpassung und darüber hinaus vorzudringen. Tatsächlich eine visuelle Sprache zu haben, die WordPress in den nächsten 10 Jahren voranbringt. Ja, so weit müssen wir denken.

An dieser Stelle möchte ich auch vor Frankendesigns warnen. Jeder einzelne Designer auf der Welt hat irgendwann einmal jemanden vorgeschlagen, "einfach x hier oder y dort zu setzen". Dies erlaubt dem Designer nicht, zu entwerfen. Als Projekt befinden wir uns in einer Abwärtsspirale, wenn wir Designer nicht designen lassen. Dies ist die Art von Prozess, der das Feuer in Designern tötet, wenn er unverblümt ist. Lass uns das Feuer am Laufen halten.

Dies ist eine persönliche Anmerkung, die über Gutenberg hinausgeht. Ich bin leidenschaftlich daran interessiert, einen Raum zu schaffen, in dem Designer gedeihen und wachsen können – nicht immer als Projekt. Zeigen wir mit Gutenberg, dass wir das tun. Leidenschaft ist groß, aber respektiere die Designvision genauso wie wir in WordPress die technische Vision. Hören wir den Designern genauso zu wie denen, die über das neueste JS-Framework sprechen.

Bis zu dem Punkt von @jasmussen ,

Ich möchte es klarstellen, ich sage nicht, dass Gutenberg als Design "fertig" oder perfekt ist. Wir müssen iterieren und wir müssen testen. Was wir nicht brauchen, ist ein Rückschritt, weg von der etablierten starken Designsprache. Wir brauchen kein Frankendesign. Was wir brauchen, ist zu testen, Feedback zu erhalten und Designern die Möglichkeit zu geben, zu iterieren.

Eines der großen Probleme mit WordPress in der Vergangenheit aus Designperspektive war eine Spirale kleiner Iterationen über kleine Iterationen. Während es für die ersten paar funktioniert, summiert es sich im Laufe der Zeit zu einer Erfahrung, die mit Patches von Verbesserungen zusammengehalten wird.

Der Versuch, Aussagen wie diese mit öffentlichen Aussagen wie dieser http://matiasventura.com/post/gutenberg-or-the-ship-of-theseus/ in Einklang zu bringen, macht es den Benutzern sehr schwer, das Gefühl zu haben, ehrliche Kommunikation über die Arbeit zu erhalten Fertig sein. WordPress wird von Millionen von Menschen auf millionenfache Weise verwendet, und es wurde überdeutlich gemacht, dass in Bezug auf technische Aspekte wie die Metabox-Unterstützung oder das Post-Storage-Format ein inkrementeller Ansatz mit so wenig Bruch wie möglich erforderlich ist. Diese Entscheidung hat mehrere Teile der Implementierung erschwert und Entscheidungen erzwungen, die nicht optimal sind, aber in vielerlei Hinsicht besser unterstützt werden.

Es ist nicht sinnvoll, die Entwicklung an einem Standard und das Design an einem anderen festzuhalten. Manchmal muss das „mutige Design“ für eine vernünftige Produktion verkleinert werden. Das ist im Automobilbau bekannt und deshalb lässt sich Gutenberg leicht mit einem Concept Car vergleichen.

Sicher, Sie möchten ein ganzheitliches Design, das Javascript für den gesamten Administrator verwendet, aber das kann nicht die Version v5 sein, ohne die Erfahrung für Millionen von Benutzern zu beeinträchtigen. Wenn Sie sich stattdessen auf den Editor konzentrieren, anstatt auf die Bearbeitungsseite, können Sie ein viel besseres Erlebnis bieten (das viele Ihrer sekundären Ziele mit umsichtigem Einsatz von CSS erreichen kann), ohne dass es zu Bruch geht.

Durch die Bereitstellung einer gut dokumentierten Fields-API können Sie dann Plugins und Themes im nächsten Jahr in die Gutenberg-Blöcke-Mentalität umwandeln, indem Sie es einfacher und logischer machen, dieselbe Schnittstelle zu erstellen. Sehr schnell werden Metaboxen zur alten Vorgehensweise und alle hochwertigen Plugins werden zu Blöcken ... wieder einmal muss dies organisch geschehen. Es ist unhaltbar, die Hände der Leute zu zwingen, indem man Funktionen veraltet oder eine geteilte Schnittstelle erstellt, bei der Plugin-Autoren sowohl für Gutenberg als auch für Metaboxen programmieren müssen.

Es ist gut, dass Sie die Überholung von Medien als einen Bereich erwähnen, der überarbeitet werden muss. Es war der erste Abschnitt von WordPress, der ein JS-Framework vollständig umfasste, und es war weitgehend ein großer Rückschritt für Entwickler. Die fehlende Anpassungsfähigkeit der Mediathek ist kein Zeichen dafür, dass sie perfekt ist, sondern dass es an durchdachtem Design mangelt, das zukünftige und aktuelle Anwendungsfälle berücksichtigt. Ich habe viele Male versucht, die Medienschnittstelle zu ändern, nur um festzustellen, dass irgendwann jemand entschieden hat, dass wichtige Komponenten in die Backbone-Vorlagen hartcodiert werden sollten. Ich bin gestern buchstäblich in einen dieser Fälle gestoßen! (wie Sie im siebten Absatz hier sehen können: https://gschoppe.com/wordpress/disable-attachment-pages/)

Wenn Sie Gutenberg zurück zum Editor skalieren, anstatt zur Bearbeitungsseite, erhalten Sie einen Weg nach vorne, der nicht alles zerstört. Sobald Gutenberg als Basis für benutzerdefinierte Post-Schnittstellen gut etabliert ist, kann die reine JavaScript-Vision den Rest der Bearbeitungsseite übernehmen. Diese Art von Iteration ist bei großen Softwarepaketen absolut entscheidend, es sei denn (wie Matt inakzeptabel behauptet hat), Sie bieten LTS-Releases an und machen jede Hauptversion zu einer kompletten Breaking Change.

Es gibt zwei Gruben, in die Sie zu fallen riskieren, und Sie haben eine identifiziert. Ja, ohne den Übergang zu einer einheitlichen Benutzeroberfläche mit modernen Technologien wird WordPress wahrscheinlich in den nächsten halben zehn Jahren sterben. Aber auch, wenn WordPress während dieses Übergangs keine angemessene Unterstützung für seine riesige Community von Entwicklern und professionellen Benutzern bietet, wird es viel früher sterben.

Machen Sie einen Beat, skalieren Sie zurück und liefern Sie etwas, das den Benutzern die Toolbox öffnet, ohne den bestehenden Workflow zu unterbrechen. Dann können Sie Version für Version vorwärts skalieren. Sie haben ein schönes Konzeptauto, aber was wir brauchen, ist ein Serienauto, das für alle Grenzfälle des realen Fahrens funktioniert. Aber wenn Sie das Konzept bereitstellen, können Sie diese Idee auf einen begrenzteren Umfang anwenden, und in einem Jahr werden diese Prinzipien allgegenwärtig sein

@gschoppe , danke, dass du dir die Zeit genommen hast zu antworten.

Zuerst etwas Klarheit. Ich bin nicht damit einverstanden, dass mein Kommentar dem Beitrag von Matias widerspricht. Ich stehe voll und ganz zu seinem Posten, es ist auch meine Vision und wir als die Leiter dieses Projekts sind uns in der Richtung einig. Ihre persönliche Meinung ist Ihre, also fahren wir von diesem Punkt aus fort.

Es ist nicht sinnvoll, die Entwicklung an einem Standard und das Design an einem anderen festzuhalten.

Ich stimme zu und mein Kommentar zielt nicht darauf ab, dass Design mehr gehört wird oder andere Standards hat, es geht darum, alle Stimmen zu hören und denselben Standard für alle anzuwenden.

Es ist gut, dass Sie die Überholung von Medien als einen Bereich erwähnen, der überarbeitet werden muss.

Ich würde gerne ein Medium sehen, das sich von Grund auf auf Designer und Entwickler konzentriert, das war nicht der Fall.

Aber auch, wenn WordPress während dieses Übergangs keine angemessene Unterstützung für seine riesige Community von Entwicklern und professionellen Benutzern bietet, wird es viel früher sterben.

Es ist interessant, dass Sie dies sagen, da niemand irgendwelche Funktionen wegnimmt. Das hat kein Designvorschlag von Gutenberg getan. Auf die eine oder andere Weise können alle vorhandenen Funktionen ausgeführt werden, auch wenn dies mit dem klassischen Editor-Plugin erfolgt.

Ich kann mir nichts besseres vorstellen, als sich auf iframes zu verlassen, um eine Benutzeroberfläche zusammenzustellen. Ich verstehe zwar, dass Metaboxen den Designprozess stark beeinträchtigen, aber ein Teil des Designs hat mit Einschränkungen zu tun. Sich vorwärts zu bewegen, als ob diese Einschränkungen nicht existierten, oder den Übergangsplan bis zum Ende zu verschieben, wird einer bereits besorgten und skeptischen Gemeinschaft weitere Sorgen bereiten.

Wenn der langfristige Plan für Gutenberg Plugin-Territorium wäre, dann würde ich sagen, experimentiere ohne Grenzen. Aber wenn es nicht dazu bestimmt ist, ein Plugin zu sein, für das die Leute sich entscheiden müssen, anstatt sich abzumelden, dann muss es realistisch mit dem Kern und dem ganzen Gepäck umgehen, das es mit sich bringt.

Mein Kommentar zielt nicht darauf ab, dass Design mehr gehört wird

Jeder einzelne Designer auf der Welt hat irgendwann einmal jemanden vorgeschlagen, "einfach x hier oder y dort zu setzen". Dies erlaubt dem Designer nicht, zu entwerfen. Als Projekt befinden wir uns in einer Abwärtsspirale, wenn wir Designer nicht designen lassen. Dies ist die Art von Prozess, der das Feuer in Designern tötet, wenn er unverblümt ist. Lass uns das Feuer am Laufen halten.

In jedem Unternehmen der Welt werden Designs an die Zwänge der Implementierung angepasst. Wenn die Abwärtskompatibilität für Metaboxen eine Einschränkung darstellt, muss das Design dies akzeptieren und innerhalb der Einschränkungen arbeiten.

Um es direkt zu sagen ,

Das hat kein Designvorschlag von Gutenberg getan. Auf die eine oder andere Weise können alle vorhandenen Funktionen ausgeführt werden, auch wenn dies mit dem klassischen Editor-Plugin erfolgt.

Derzeit legt Gutenberg alle Metafelder in einen iframe. Das unterbricht die Funktionalität auf einer sehr tiefen Ebene. Wir befinden uns im Zeitalter der Barrierefreiheit, und wenn wir die primäre erwartete Methode zum Erstellen benutzerdefinierter Benutzererfahrungen und das Einsperren in einen iframe verwenden, wird die Barrierefreiheit von diesen Tools grundsätzlich entfernt. Es verdreifacht auch die Anzahl der Anforderungen, die zum Laden des Editors erforderlich sind, und bietet Benutzern eine schreckliche Benutzeroberfläche, die modale Vollbilderfahrungen in einem winzigen Bereich einsperrt.

Derzeit wird in diesem Thread diskutiert, ob Gutenberg sich für benutzerdefinierte Beitragstypen anmelden oder abmelden sollte. Wenn Sie sich anmelden, werden zuvor konsistente UI-Entscheidungen von Entwicklern, die alle Beitragstypen unterstützen möchten, zwischen der Gutenberg-Erfahrung und der klassischen Erfahrung aufgeteilt, was die doppelte Entwicklungsarbeit erfordert, um eine angemessene Benutzererfahrung für beide bereitzustellen, und keine Konsistenz gewährleistet der Benutzererfahrung.

Derzeit bietet die Funktion wp_editor() (die derzeit bewährte Methode zum Implementieren einer vollständigen Kopie der Bearbeitungserfahrung auf nicht bearbeiteten Seiten) keine Gutenberg-Schnittstelle, was bedeutet, dass ich dies nicht tun kann Erstellen Sie benutzerdefinierte Bearbeitungserlebnisse auf Nicht-Post-Seiten ... was ist mein Weg dorthin, abgesehen davon, dass Sie Benutzern eine geteilte UX bieten?

Das Plugin zum Entfernen von Gutenberg kann zwar einige Probleme lösen, Sie können es jedoch nicht als Lösung für Plugin-Entwickler versenden. Sie haben nicht die Freiheit zu sagen: "Wenn Sie eine konsistente und zugängliche Benutzeroberfläche für alle Beitragstypen wünschen, müssen Sie den neuen Editor deaktivieren".

Das Entfernen von Funktionen ist für den Standardworkflow NICHT abwärtskompatibel. Das Entfernen von Funktionen ist der letzte Ausweg für die 1 % der Nutzer, die nicht als erstklassige Erfahrungen untergebracht werden können. In diesem Fall handelt es sich bei keinem der von mir angegebenen Beispiele um 1 %-Probleme.

Um ein bisschen Öl in die Flammen hinzuzufügen: Erst letzte Woche hatte ich ein massives Problem mit der Verwendung von iFrames, dh. Sie können auf Desktop-Systemen gut spielen, aber in 90% der getesteten Fälle versagen sie massiv auf Mobile / Responsive. Nachdem ich zahlreiche Message-Board-Threads, Artikel im Netz und Fragen zu Stack Overflow durchwühlt hatte, entschied ich mich, den iframe-Ansatz vollständig aufzugeben, weil die Reaktionsfähigkeit mit em.. ugh so schrecklich kompliziert wird. Einige Konvertierungsaufgaben waren ziemlich einfach zu bewerkstelligen, wie zum Beispiel "verwende eine Weiterleitung auf die eigentliche Subdomain, in der sich das Projekt befindet", anstatt sich auf einen iframe zu verlassen, um eine schöne Dekoration anzubringen, die nur die vermeintliche Hauptdomain zeigt, aber andere waren viel erbärmlicher.

Nichtsdestotrotz war die Wende im Vergleich zu dem enormen Arbeitsaufwand, den ich leisten müsste, um RWD richtig und vor allem zuverlässig UND wartbar zu machen, um mit iframes zu arbeiten, viel weniger Aufwand und somit der bessere Ausweg.

Zusammenfassend lässt sich sagen, dass iframes, obwohl sie auf den ersten Blick wie ein einfacher Ausweg aussehen, eine SEHR SCHLECHTE Designwahl sind, nicht nur wegen (vieler) Zugänglichkeitsprobleme.

Nur meine 0,02 Cent,
cu, w0lf.

Danke @mtias für das Zeigen dieses Problems.
Unten poste ich meine Gedanken darüber, wie Gutenberg Türen für die WordPress-Plugin-Entwickler öffnen kann.

Anpassbare CSS-Klasse für jeden vorhandenen Block

Erforderlich: CSS-Klasse für jeden Block-Wrapper und voller Zugriff, um ihn anzupassen. Es wäre großartig, wenn Gutenberg die CSS-Klasse für das oberste Element selbst von Drittentwicklern fordert.

Zweck: Auf diese Weise können wir den Blöcken benutzerdefinierte Klassen für erweitertes Styling hinzufügen. Wir können auch Klassen verwenden, um Animationen oder andere erweiterte Blockeigenschaften hinzuzufügen.

Anwendungsbeispiel: Wir erstellen für einen großen Kunden eine Website mit einer streng definierten Designsprache. Der Seiteneditor sollte in der Lage sein, Blöcke mit einer vordefinierten Anzahl von Stilen zu erstellen, die von unserem Designer speziell für diesen Kunden erstellt wurden.

Anpassbare Datenattribute für jeden vorhandenen Block

Erforderlich: Möglichkeit, benutzerdefinierte Datenattribute für jeden Block-Wrapper hinzuzufügen.

Zweck: Sauberere und flexiblere Alternative zu den oben beschriebenen benutzerdefinierten CSS-Klassen. Mit Datenattributen können wir jedes Element auf der Seite formatieren. Neben dem Styling können benutzerdefinierte Datenattribute verwendet werden, um zusätzliche Metadaten für JS zu speichern.

Anwendungsbeispiel:

• Responsive Blöcke : Markieren Sie einen Block, der nur auf Mobilgeräten/Desktops angezeigt werden soll
• Bedingte Blöcke : Markiere einen Block, der angezeigt/ausgeblendet werden soll mit JS <div data-condition="if-adblock"... , <div data-condition="if-from-facebook"...
• Blockanimation : einen zu animierenden <div data-animation="on-load animation-style-3"...
• Blockdesign : <div data-skin="dark"...