Gutenberg: Sind iframes eine tragfähige langfristige Lösung für Meta-Boxen?

1. ... Gutenberg verwendet derzeit zwei separate Iframes für die Hauptspalte und die Seitenleiste. Wenn wir Meta-Boxen unterstützen, die nach dem Titel erscheinen, würde dies theoretisch zu einem dritten Iframe führen. Wird dies Probleme damit aufwerfen, wie Plugins Assets in die Warteschlange stellen, die sich auf alle iframed-Meta-Boxen auswirken müssen?

Ich habe heute Abend einige Leistungstests durchgeführt und bin auf meiner alarmierenden Registerkarte "Netzwerk" auf diese Entdeckung gestoßen. Es scheint, dass alle CSS- und JS-Assets, die im übergeordneten Fenster in die Warteschlange gestellt werden, auch in der Hauptspalte iframe und in der Seitenleiste iframe in die Warteschlange gestellt werden. Dies bedeutet, dass jedes Asset insgesamt dreimal angefordert wird, wodurch sich die Anzahl der Asset-Anforderungen bei Verwendung effektiv verdreifacht Gutenberg .

Der Schaden an der Seitengewichtung wird bei aktiviertem Browser-Caching verringert, aber die Anzahl der Asset-Anforderungen wird immer noch verdreifacht. Ich gehe davon aus, dass dies so gemacht wird, dass jeder Iframe über die Assets verfügt, die erforderlich sind, damit die Meta-Boxen funktionieren, aber dies kann sicherlich nicht die Lösung sein, um Assets in die Warteschlange zu stellen.

Vielen Dank für die Erstellung des Problems und Ihre Erkenntnisse @kevinwhoffman. Es ist gut zu denken, dass das, was wir heute für Metaboxen in Gutenberg haben, ein Experiment ist. In vielerlei Hinsicht ist es ein Warteschleifenmuster, wenn das Projekt die Richtung herausarbeitet, in die es gehen soll. Wenn wir sagen, dass es eines ist, das "vorerst" funktioniert, aber nicht das ist, womit wir versenden würden.

Nach alledem denke ich, dass es wichtig ist, zu prüfen, wofür in Zukunft Metaboxen verwendet werden. Welche Fälle (falls vorhanden) würden nicht in Blöcke konvertiert? Müssen alle Metaboxen mobil funktionieren? Gibt es überhaupt eine alternative Schnittstelle, die wir nicht untersucht haben? Ich wette, das gibt es. Im Moment geht es darum, diese Möglichkeiten zu prüfen und einen Weg zu finden, der jetzt für den Staat und den zukünftigen Staat funktioniert.

Im Moment müssen die Fehler behoben werden, die mit der aktuellen Version von Metaboxen in Gutenberg bestehen, und das ist ein Schwerpunkt. Die Leistung muss in diese Korrektur einfließen. In Bezug auf Mobilgeräte sind Metaboxen seit langem ein Problem, wir machen es hier nicht noch schlimmer. Das heißt, wir sollten in Zukunft für eine bessere Lösung arbeiten. Es ist wichtig, sich zurückzuziehen und sich daran zu erinnern, dass dies nur eine "heutige" Lösung ist, wenn wir iterieren und weiterhin frei sind, über eine bessere Option nachzudenken.

Es ist gut zu denken, dass das, was wir heute für Metaboxen in Gutenberg haben, ein Experiment ist. In vielerlei Hinsicht ist es ein Warteschleifenmuster, wenn das Projekt die Richtung herausarbeitet, in die es gehen soll. Wenn wir sagen, dass es eines ist, das "vorerst" funktioniert, aber nicht das ist, womit wir versenden würden.

Der iframe-Ansatz funktioniert nicht, nicht einmal "vorerst". Die oben aufgeführten verwandten Probleme enthalten Beispiele für Meta-Boxen, die nicht wesentlich funktionieren. Selbst wenn diese Probleme behoben wurden, sollte die Verdreifachung des Seitengewichts und der Anzahl der Anfragen unter keinen Umständen als "funktionierend" angesehen werden.

Nach alledem denke ich, dass es wichtig ist, zu prüfen, wofür in Zukunft Metaboxen verwendet werden.

Dies geschieht respektvoll jedes Mal, wenn das Problem der Meta-Boxen angesprochen wird. Anstatt die Konversation auf zukünftige Meta-Blöcke zu verlagern, wäre es wirklich hilfreich, diese Diskussion auf die Probleme zu konzentrieren, mit denen vorhandene Meta-Boxen konfrontiert sind. Noch einmal:

Können diese Probleme behoben werden, ohne dass das Thema oder Plugin geändert werden muss, das die Meta-Box generiert?

Ich habe bisher keine Beweise dafür gesehen, dass Meta-Boxen weiterhin mit Gutenberg zusammenarbeiten werden. Wenn die Antwort Nein lautet, sollten wir aufhören, so zu tun, als wäre 5.0 nur eine weitere WordPress-Version, und ehrlich sein, wenn es darum geht, die Abwärtskompatibilität zu brechen.

Hallo Kevin,

Vielen Dank für den ausführlichen Bericht. Ich denke, viele Probleme können bis zu einem gewissen Grad behoben werden. Dies ist auch eine Untersuchung darüber, ob der iframe-Ansatz funktioniert und wie weit er gehen kann. Daher ist es gut, diese Art von Dialog zu führen und die Mängel dieses Ansatzes aufzuzeichnen.

Ist es möglich, ein Inhaltsfenster über eine Meta-Box zu starten, die über den Iframe hinausgeht?

Meinst du wie ein modaler Leuchtkasten, der die gesamte Seite einnehmen soll?

Meinst du wie ein modaler Leuchtkasten, der die gesamte Seite einnehmen soll?

Das wäre ein Beispiel, aber ich beziehe mich eher auf jedes Szenario, in dem Inhalte enthüllt werden müssen, die nicht innerhalb der Grenzen des Iframes liegen.

Kann ich beispielsweise auf eine Schaltfläche in der Seitenleiste klicken, die ein Inhaltsfeld in der Mitte der Seite auslöst? Befindet sich dieses Inhaltsfeld innerhalb des Iframes, ist es außerhalb der Abmessungen des Iframes in der Seitenleiste nicht sichtbar.

Der logische nächste Schritt wäre, stattdessen die Funktion im übergeordneten Dokument aus dem Iframe aufzurufen. Aber Plugins sind derzeit nicht so geschrieben, dass sie funktionieren, und wenn sie geändert werden müssten, würde dies den gesamten Zweck der Unterstützung von _legacy_-Meta-Boxen zunichte machen. Ich kann nicht genug betonen, dass jede Lösung, für die entschieden wird, ohne Änderung bestehender Themen oder Plugins funktionieren muss.

Da ich weiß, wie negativ die iFrame-Implementierung in Bezug auf Plugin- / Theme-Assets ist, sollte dies dem Projekt eine Pause geben. Die eigentliche Antwort hier ist, dass WordPress die Fields-API https://github.com/sc0ttkclark/wordpress-fields-api ausliefert. Ohne dies ist eine effektive Implementierung von Metaboxen mit Gutenberg praktisch unmöglich, wenn wir uns überhaupt um die Leistung kümmern.

Wenn wir Gutenberg erst dann wirklich ausliefern, wenn es "fertig" ist, sollten wir der Fields-API die gleiche Aufmerksamkeit widmen, damit Metboxen mit React in Gutenberg korrekt und nahtlos funktionieren.

Der logische nächste Schritt wäre, stattdessen die Funktion im übergeordneten Dokument aus dem Iframe aufzurufen. Derzeit sind Plugins jedoch nicht so geschrieben, dass sie funktionieren. Wenn sie geändert werden müssen, wird der gesamte Zweck der Unterstützung älterer Meta-Boxen zunichte gemacht. Ich kann nicht genug betonen, dass jede Lösung, für die entschieden wird, ohne Änderung bestehender Themen oder Plugins funktionieren muss.

Ja, definitiv ein Problem, das ich dabei hatte. Die gegenseitige Kommunikation zwischen Iframes klingt nicht sehr gut. Es gibt auch andere Alternativen zu erkunden.

Es wird jedoch definitiv Fälle geben, in denen bestimmte Themen-Plugins beschädigt werden und es nicht möglich ist, jeden möglichen Anwendungsfall zu berücksichtigen. Ich denke, ein besseres Ziel ist es, eine gute Erfahrung für die große, große Mehrheit der Benutzer und Anwendungsfälle zu schaffen . Es ist durchaus möglich, dass die aktuelle iframe-Lösung dieses Ziel nicht erreicht.

Es kann erwähnenswert sein, dass in einem kürzlich veröffentlichten Core Customizer Dev Note Post die Aufmerksamkeit auf die Entfernung der Verwendung eines Iframes als _verbesserung_ gelenkt wurde. Es scheint ein Rückschritt zu sein, hier einen Iframe als Lösung zu implementieren.

Hallo Mathetos,

Wenn wir Gutenberg erst dann wirklich ausliefern, wenn es "fertig" ist, sollten wir der Fields-API die gleiche Aufmerksamkeit widmen, damit Metboxen mit React in Gutenberg korrekt und nahtlos funktionieren.

Ich bin damit einverstanden, dass eine Fields-API etwas nett wäre. Dies würde jedoch auch bedeuten, dass Personen die Feld-API übernehmen müssen. Wenn nicht viele bereit sind, ihr Plugin / Theme für Gutenberg neu zu schreiben, sind sie meiner Meinung nach nicht bereit, dies für eine Fields-API zu tun. Ich denke auch, dass dies in einer früheren Ausgabe irgendwo erwähnt wurde, daher würde ich empfehlen, dies in der GitHub-Geschichte zu verfolgen und Ihre Gedanken darüber hinzuzufügen, wie die Fields-API Gutenberg zugute kommen könnte.

... es ist nicht möglich, jeden möglichen Anwendungsfall zu berücksichtigen. Ich denke, ein besseres Ziel ist es, eine gute Erfahrung für die große Mehrheit der Benutzer und Anwendungsfälle zu schaffen.

Ich stimme zu, und ich denke, dass dieses Ziel viel besser erreichbar wäre, wenn Gutenberg den Editor überarbeiten würde, anstatt die gesamte Seite zu übernehmen. Dann könnten wir die vorhandenen Hooks an Ort und Stelle lassen und Meta-Boxen könnten weiterhin wie bisher miteinander kommunizieren. Das Einreihen von Assets wäre ebenfalls kein Problem, da es wie heute funktionieren würde.

Ich stimme diesem Konzept von Yoast sehr zu, das meines Erachtens einen Großteil der bereits geleisteten Arbeit beibehalten würde, während der Umfang des Projekts reduziert wird, um sich auf die Editor-Komponente zu konzentrieren.

Quelle: https://yoast.com/gutenberg-alternative-approach/

Ich stimme auch dem Vorschlag von Yoast voll und ganz zu. Es bietet eine gute Zwischenphase, in der Plugin-Autoren Zeit haben, Metaboxen in die neuen Blöcke zu konvertieren. Als Teil des Plans zur eventuellen Ersetzung der gesamten Editor-Erfahrung kann WP als Projekt so etwas wie "In x-Versionen werden Metaboxen veraltet" sagen, sodass wir einen Plan haben, um auf ein besseres Endziel hinzuarbeiten.

Ich stelle nur fest, dass dieses Konzept vorhandene Metaboxen zerstört, da es keine zentrale TinyMCE-Instanz gibt, mit der kommuniziert werden kann. Anstatt 80% der Metaboxen zu unterstützen, werden 90% unterstützt (ich habe diese Zahlen erfunden).

Dieses Konzept löst das Problem der Abwärtskompatibilität nicht, sondern verzögert seine Lösung auf später mit demselben Problem. Gutenberg ist der erste Schritt in Richtung JS-Schnittstellen in WP und wird bei Gutenberg nicht aufhören.

Die Wiederverwendung von Gutenberg-Stücken zur Erstellung dieses Konzepts ist relativ machbar, aber dies ist nicht die UX, für die wir optimieren möchten. Wir möchten zuerst den bestmöglichen Editor erstellen und ihn für Benutzer ohne Abwärtskompatibilitätsprobleme (Neuinstallationen, keine Metaboxen) verfügbar machen. .).

Wenn wir der Meinung sind, dass die ideale Vision von Gutenberg versandbereit ist, haben wir Zeit, um Strategien für Upgrade-Pfade zu diskutieren. Ein Konzept wie dieses ist eine Option für einen Upgrade-Pfad, aber definitiv nicht als Endprodukt. Andere Upgrade-Pfade sind ebenfalls möglich.

Lassen Sie uns jetzt den bestmöglichen Editor erstellen.

Wenn wir glauben, dass die ideale Vision von Gutenberg versandbereit ist, haben wir Zeit, um Strategien für Upgrade-Pfade zu besprechen ...

Ich konnte dem nicht mehr widersprechen. Warum Tausende von Stunden in die Entwicklung des idealen Editors investieren, wenn er nicht mit vorhandenen Websites kompatibel gemacht werden kann? Wenn der erste Eindruck ist, dass die Benutzeroberfläche, von der sie abhängig sind, beschädigt wird, werden Benutzer den idealen Editor überhaupt nicht erleben.

Warum Tausende von Stunden in die Entwicklung des idealen Editors investieren, wenn er nicht mit vorhandenen Websites kompatibel gemacht werden kann?

Nur um das klar zu stellen,

• Es ist unmöglich, 100% kompatibel mit vorhandenen Websites zu sein, unabhängig von der Option, die Sie für den Editor auswählen, da die Plugins vollen Zugriff auf das DOM haben. Alles, was Sie im Dom ändern, beeinträchtigt die Abwärtskompatibilität
• Es gibt nur einen Weg, um eine 100% ige Abwärtskompatibilität für jede Änderung sicherzustellen: Nehmen Sie die Änderung nicht vor. Das Plugin zum Deaktivieren von Gutenberg ist bereits verfügbar.
• Der Editor ist bereits mit einer Vielzahl von Websites kompatibel. Aber wie alles andere ist es immer sichtbarer, wenn es kaputt geht.

Es ist unmöglich, 100% kompatibel mit bestehenden Websites zu sein

Nachdem dies klar ist, erstellen wir den Editor, den wir für die Zukunft von WordPress für am besten halten.

Müssen alle Metaboxen mobil funktionieren?

Ja, warum sollten sie nicht?

Welche Fälle (falls vorhanden) würden nicht in Blöcke konvertiert?

Bei Blog-Posts verstehe ich, warum Blocks For Everything möglicherweise sinnvoll ist, aber dies ignoriert möglicherweise den allgemeinen Anwendungsfall für Metadaten: Daten, die nicht sichtbar sind. Ich kann eine Metabox verwenden, um die Benutzeroberfläche zum Hinzufügen von Analysedaten zu einem Beitrag bereitzustellen.

Für Dinge wie benutzerdefinierte Beitragstypen, die möglicherweise NUR aus Meta-Feldern bestehen, habe ich Probleme, die neue Benutzeroberfläche zu verstehen. Da es in WordPress an einer umfassenden CRUD-API für Daten mangelt, verwenden viele Entwickler WP_Query und die dazugehörige API-API als Ersatz und verwenden Meta-Boxen auf CPT-Bearbeitungsbildschirmen, um die Benutzeroberfläche zum Hinzufügen bestimmter Daten oder zu isolieren Verbände. Viele (die Mehrheit) der benutzerdefinierten Beitragstypen in freier Wildbahn betonen oder ignorieren die traditionelle Verwendung von "Inhalten". Bei Blog-Beiträgen steht der Inhalt im Vordergrund, aber für viele CMS-Anwendungsfälle wird ein WYSIWYG nicht erstellt viel Sinn.

In dieser aktuellen Iteration ist die Meta Box-Unterstützung ein Add-On, wenn in der Realität vieler Menschen Meta Boxes die Benutzeroberfläche, die API und der Mechanismus sind, mit dem sie ihr CMS zusammenstellen. <iframe> s sind der Gulag.

Und wir vergessen die Werte, auf denen WP für immer aufgebaut wurde: Ich sollte in der Lage sein, auf die neueste Version von WP zu aktualisieren und nichts neu schreiben zu müssen. Ich habe so viele Projekte in freier Wildbahn auf WP, dass ich sie nie wieder anfassen werde. Kann ich sicher sein, dass einige von ihnen mit dieser Änderung nicht wild brechen?

Ich werde mit diesem Beispiel enden: Wenn eine meiner "alten" Meta-Boxen das Öffnen der Benutzeroberfläche für Medien auslöst, wie funktioniert dies in diesem "neuen" Szenario innerhalb eines Iframes ohne jemanden (einen Client, mit dem ich nicht mehr arbeite) ) den Code umschreiben?

Während ich diese Gespräche verfolgt habe, kann ich nicht anders, als das Gefühl zu haben, dass die Machthaber, die sich entwickeln und die Aufnahmen in Bezug auf Gutenberg machen, Metaboxen selbst nicht verwenden oder damit umgehen. Es fühlt sich wie eine Art Argument an, das die Mittel rechtfertigt, wobei es leicht zu sagen ist, weil die Mittel anfangs nicht besonders geschätzt werden.

Bitte haben Sie Verständnis dafür, dass viele von uns Dutzende von Websites haben, die bei einem Update auf WordPress 5.0 sofort kaputt gehen würden - ein Produkt, das in der Vergangenheit den Menschen beigebracht hat, dass ein Upgrade sicher ist, da es sich um eine Abwärtskompatibilität handelt. Was hier diskutiert wird, ist keine kleine Unterbrechung (z. B. Styling), sondern ein potenzieller Show-Stopper, der die Administratorseite von Tausenden (oder mehr) Websites sofort unbrauchbar macht. Das ist beängstigend. Als Branche haben wir Menschen mit der soliden Zuverlässigkeit von WordPress verkauft.

Wie @staylor oben ausgeführt hat, sind auf den meisten unserer Websites (Unternehmensseiten mit mittlerer bis hoher Komplexität) die Metaboxen die Benutzeroberfläche. Der Editor (falls überhaupt verwendet) ist nur ein Teil davon.

Wenn wir der Meinung sind, dass die ideale Vision von Gutenberg versandbereit ist, haben wir Zeit, um Strategien für Upgrade-Pfade zu diskutieren. Ein Konzept wie dieses ist eine Option für einen Upgrade-Pfad, aber definitiv nicht als Endprodukt. Andere Upgrade-Pfade sind ebenfalls möglich.

Ich denke, es könnte ein Fehler sein, dies zu weit hinauszuschieben. Zumal viele Organisationen mindestens 1-2 Viertel benötigen, um sich vorzubereiten.

Es gibt ein Sprichwort, das ich von mehreren führenden Entwicklern von WordPress gehört habe, das ich hier für wichtig halte: Wenn jemand WordPress für seine Website übernimmt, übernimmt er nicht WordPress 3.7 oder WordPress 4.8, sondern WordPress. Diesen Weg so nahtlos wie möglich voranzutreiben, ist absolut notwendig. Dies wird die Dinge kaputt machen, und das ist in Ordnung (es gibt fast jede Version von WordPress Kompatibilitätspausen), aber sie müssen minimiert, dokumentiert und kommuniziert werden.

Es ist unmöglich, 100% kompatibel mit bestehenden Websites zu sein

Wenn Sie nicht kompatibel sein werden, gehen Sie sicher und brechen Sie Dinge. Rufen Sie die erste Version WP ++ oder WPNG auf. Es ist viel besser, im Voraus zu erklären, dass die Dinge höchstwahrscheinlich kaputt gehen und die Leute sich darauf vorbereiten lassen. Die derzeitige "Täuschung", als ob die Dinge wie gewohnt funktionieren würden, ist nur für alle schlecht.

Iframes sind eine Sackgasse in Bezug auf die Benutzerfreundlichkeit. Öffnete ein jquery-basiertes Datumsauswahl-Widget in einem Meta-Feld und war überrascht, als das Klicken auf eine andere zufällige Stelle im Fenster es nicht schloss. Es dauerte eine Minute, bis mir klar wurde, dass sich das Klickereignis im übergeordneten Fenster befand und nicht in den Iframe übertragen wurde. Ich war überrascht, habe es aber am Ende verstanden, aber wie wollen Sie den Benutzern so etwas erklären? Erwarten Sie, dass jedes Plugin die Frage jedes Benutzers nach solchen trivialen UX-Erwartungen beantwortet?
Und wie erwarten Sie, dass externe Links funktionieren?

Es gibt gute Gründe, warum Menschen Iframes nur als letzten Ausweg verwenden.

Mein produktiver Vorschlag ist, die Meta-Box nicht für bereit zu erklären, solange yoast seo nicht richtig darin funktioniert. Es ist sowohl in Bezug auf Interaktionen etwas komplex als auch auf einer Vielzahl von Websites installiert. Wenn gutenberg nicht damit arbeiten kann, wird es wahrscheinlich niemand benutzen.

Mein produktiver Vorschlag ist, die Meta-Box nicht für bereit zu erklären

Wie oben von @karmatosed ausgeführt : "Es ist gut zu denken, dass das, was wir heute für Metaboxen in Gutenberg haben, ein Experiment ist. In vielerlei Hinsicht ist es ein Warteschleifenmuster, während das Projekt die Richtung ausarbeitet, in die es gehen soll. Wenn man sagt, dass es eines ist." das funktioniert 'vorerst', ist aber nicht das, womit wir versenden würden. "

Um einige reale Daten bereitzustellen, möchte ich diese Oberfläche von einer WordPress-Site aus freigeben, an der ich in der Vergangenheit gearbeitet habe. Das Inhaltsfeld ist ein untergeordneter Teil dieses benutzerdefinierten Beitragstyps. Während einige der benutzerdefinierten Metaboxfelder in Blöcke konvertiert werden könnten, enthält die Mehrheit Daten, die entweder vom Administrator oder von einem Drittanbieter-Service über die REST-API verwendet werden. oder verwendet, um dem Eintrag Metadaten hinzuzufügen. Obwohl es etwas chaotisch aussehen mag, wurde dieses Setup speziell für den Workflow des Clients entwickelt und verwendet ein striktes Inhaltsmodell, das auf einer klaren Trennung basiert, um sicherzustellen, dass zukünftige Versionen der Website jeden Inhaltstyp unabhängig verarbeiten können.

Die Umgestaltung dieser Site, um innerhalb der Gutenberg-Realität zu funktionieren, wird lange dauern und erhebliche Ressourcen erfordern. Wenn Metaboxen nicht in einer Weise behandelt werden, die eng mit den bereits vorhandenen übereinstimmt, wird dieser Site-Besitzer wahrscheinlich auf eine Vor-Gutenberg-Version von WP zurückgreifen und bleiben dort auf unbestimmte Zeit.

Als Referenz sieht es zwar umfangreich aus, aber es ist weder das komplexeste Metabox-Setup, das ich erstellt habe, noch das komplexeste Setup, das ich gesehen habe. Was dieses Beispiel zeigt, ist die reale Problemumgehung über Metaboxen, um die Notwendigkeit einer ordnungsgemäßen Modellierung und Trennung von Inhalten über den Inhalts-Blob hinaus zu erfüllen, was Gutenberg anmutig und funktional handhaben muss.

Diesen Weg so nahtlos wie möglich voranzutreiben, ist absolut notwendig.

Einverstanden

Dies wird die Dinge kaputt machen, und das ist in Ordnung (es gibt fast jede Version von WordPress Kompatibilitätspausen), aber sie müssen minimiert, dokumentiert und kommuniziert werden.

Einverstanden

Es ist unmöglich, 100% kompatibel mit vorhandenen Websites zu sein, unabhängig von der Option, die Sie für den Editor auswählen, da die Plugins vollen Zugriff auf das DOM haben. Alles, was Sie im Dom ändern, beeinträchtigt die Abwärtskompatibilität

Einverstanden, ich glaube nicht, dass hier jemand mit Ihnen nicht einverstanden wäre. Ich denke jedoch, es gibt immer noch Raum zu diskutieren, was kaputt geht und wann es kaputt ist. Diese Art von Entscheidungen wirken sich auch darauf aus, welche Art von Arbeit Entwickler tun müssen, um Fehler zu beheben. Es gibt einen signifikanten Unterschied zwischen dem Anpassen von Dingen, da Dom-Selektoren geändert wurden, und dem Umschreiben eines benutzerdefinierten Inhaltsmodells, um dem neuen Gutenberg-Paradigma zu entsprechen, in dem Metaboxen nur irgendwie funktionieren :) Der Streit um Metaboxen zeigt mir, dass dies wahrscheinlich nicht der Fall ist Eine gute Sache, um die erste Veröffentlichung von Gutenberg im Kern zu erreichen.

Ich vergesse, dass dies alles ein Experiment ist, ich denke, @kevinwhoffman tut es auch. Ich sehe dieses Problem als eine gut durchdachte Bewertung dieses Experiments und es sollte so verstanden werden. Wird dieses Experiment als endgültige Lösung ausreichen? Also, was ist das nächste Experiment?

Ich denke auch nicht, dass es einen enormen Anstieg von Entwicklern geben wird, die ihre bestehende Arbeit auf Gutenberg umstellen, bis ein Zusammenführungsvorschlag vorliegt, in Anbetracht dessen, was in der ersten Veröffentlichung von Gutenberg _does_ matter bricht.

tldr; Erwarten wir einen Bruch mit Gutenberg? Ja! Aber wir sollten immer noch selektiv darüber sein, was wir brechen und wie weit dieser Bruch in der anfänglichen Iteration von Gutenberg geht, die zum Kern verschmolzen ist.

Ja, wir haben uns alle genug mit der Entwicklung von WordPress beschäftigt, um zu erwarten, dass einige Dinge von einer Version zur nächsten kaputt gehen. Und in gewisser Weise ist das genau mein Punkt. Solange wir Gutenberg als ein weiteres WordPress-Update präsentieren, sollte es nicht mehr oder weniger als jedes andere Update kaputt gehen. Wenn wir dieses Vertrauen brechen, spielt es keine Rolle, wie gut der Redakteur am Ende des Tages ist.

Hier ist ein aktueller Screenshot eines Plugins, das ich in den letzten Monaten entwickelt habe. In dieser Situation hat ein visueller Editor keinerlei Wert, und es macht keinen Sinn, die Art der Schnittstelle, die für die visuelle Bearbeitung von Inhalten benötigt wird, in eine Schnittstelle zu integrieren.

Ich überlege mir ernsthaft, ob ich mir überhaupt die Mühe machen sollte, dies für WordPress weiterzuentwickeln, da alle meine Arbeiten mit der nächsten Version möglicherweise rückgängig gemacht werden.

Wie Sie sehen können, benötige ich Zugriff auf den Medien-Uploader in meinen Metafeldern, und wenn der Großteil der Seite in einen Iframe verwiesen wird, ist diese Benutzeroberfläche äußerst umständlich.

Es gibt Millionen solcher Schnittstellen in Plugins, Tools und benutzerdefinierten Websites, die auf WordPress basieren. Es ist inakzeptabel, diese Benutzer wie Bürger zweiter Klasse zugunsten der "neuen Schärfe" von Blöcken zu behandeln. Metaboxen müssen ihren aktuellen Integrations- und Bekanntheitsgrad auf der Bearbeitungsseite beibehalten.

Ich unterstütze Yoasts Ansicht von Gutenberg sehr. Es ist mir unklar, wie "Upgrade des visuellen Editors" vom Gutenberg-Team neu interpretiert wurde, um "die gesamte Post-Edit-Oberfläche zu ersetzen", aber es scheint direkt im Widerspruch zum sogenannten "Ship of Theseus" zu stehen.

In diesem Fall schadet das Fehlen einer klaren Richtung und Unterstützung für die vorhandenen Standardworkflows den Entwicklern jetzt aktiv. Wie kann ich ein Projekt ohne vertrauenswürdige Hooks und Tools erstellen, auf die ich mich verlassen kann? Es ist nicht zu übersehen, dass ein so großes Softwareprojekt den Standardworkflow für Entwickler in einem einzigen Update vollständig verbessern würde. und es ist verrückt, dass diese Gespräche gerade jetzt, im November, stattfinden, wenn geplant ist, eine Fusion zu Beginn des Jahres zu genehmigen.

@aaronjorbin gut, es scheint, dass es hier ein Kommunikationsproblem gibt, wie in https://make.wordpress.org/core/2017/10/24/whats-new-in-gutenberg-24th-october/ ausdrücklich gesagt wurde

Diese Version enthält lang erwartete Unterstützung für Meta-Boxen (muss getestet werden!),

Es ist keine "Idee", es ist kein "Experiment", es ist nur etwas, das wie jede Software immer noch Fehler enthält. Ich hätte es nicht getestet, wenn es in diesem Beitrag "ein Experiment" genannt worden wäre.

Wenn ich noch einmal auf das Thema zurückkomme, sehe ich, dass das Hauptproblem hier der Versuch ist, die Erklärung eines Bruchs zu vermeiden. Nach meinem begrenzten Verständnis von JS-Framewoks ist es sehr schwierig, mit ihnen "halb schwanger" zu sein, und wenn Sie einmal entschieden haben, dass Ihre Hauptbildschirmsteuerung mit ihnen durchgeführt wird, muss alles mit ihnen erledigt werden Machen Sie Meta-Boxen zu erstklassigen Bürgern im Gutenberg-Bearbeitungsbildschirm.
Da es unwahrscheinlich ist, dass sich "Legacy" -Plugins anpassen, bedeutet dies, dass Gutenberg eine explizite Opt-In-Option für vorhandene Websites sein muss. Ich hasse die Idee einer UX-Gabel, aber zumindest auf diese Weise wird es einen Weg nach vorne geben, der funktionieren wird, und wenn er jetzt deklariert wird, können sich die Leute vorbereiten.

Nachdem ich die Diskussion gelesen und über die Projekte nachgedacht hatte, die ich mit WordPress erstellt habe, und über die Dinge, die Leute mit WordPress machen, kam ich zu dem Schluss, dass Gutenberg sich für benutzerdefinierte Beitragstypen entscheiden sollte. Auf diese Weise können aktuelle Websites, die CPT für strukturierte Daten verwenden, weiterhin funktionieren und neue Websites, auf denen WordPress als CMS verwendet wird, erstellt werden. Ich möchte Sie nur daran erinnern, dass wir bei der Registrierung eines Beitragstyps die Unterstützung für das Editorfeld zusammen mit anderen Funktionen explizit deklarieren können. Warum also nicht einfach explizite Unterstützung für Gutenberg hinzufügen? Dies wird natürlich nicht das Problem mit Meta-Boxen beheben, die zu Posts und Seiten hinzugefügt werden, aber es wird ermöglichen, dass WordPress in Zukunft als CMS verwendet wird.

Kann mit diesen Iframes ein neues Problem hinzufügen. Wenn die Benutzersitzung ausgeht, wird der WP-Anmeldebildschirm zweimal über Gutenberg und innerhalb des Iframes angezeigt.

Nur damit Entwickler sich dessen bewusst sind.

Mehr ich folge all dem mehr ich bin überzeugt, dass nur ein möglicher Weg wie Microsoft wäre.

Windows XP = WordPress ohne Gutenberg
Windows 10 = Wordpress mit Gutenberg.

Diese 2 können nicht mit Paketen anderer gemischt und aktualisiert werden.

Joomla und Drupal haben es geschafft. Warum nicht. Ich bevorzuge das überhaupt nicht, aber was ist eine Alternative?

Nachdem ich die Diskussion gelesen und über die Projekte nachgedacht hatte, die ich mit WordPress erstellt habe, und über die Dinge, die Leute mit WordPress machen, kam ich zu dem Schluss, dass Gutenberg sich für benutzerdefinierte Beitragstypen entscheiden sollte.

Ein geteilter Administrator wäre eines der schlechtesten Ergebnisse, die Gutenberg erzielen kann. Ich habe die Gründe dafür in https://github.com/WordPress/gutenberg/issues/3330#issuecomment -341752490 beschrieben.

Diese Diskussion wird wirklich kafkaesque. Es scheint, dass es, egal wie viele Leute pragmatische Lösungen für die gegenwärtigen Schmerzpunkte vorschlagen, einige Schlüsselpersonen gibt, die für die Kritik völlig undurchlässig zu sein scheinen. Leider haben diese Leute das letzte Wort, denn bisher hat die Diskussion gezeigt, dass einige Schlüsselpersonen Hunderte von besorgten Entwicklern überfahren können. Ich mache mir Sorgen über den Schaden, den dies dem WordPress-Ökosystem zufügt. Machen Sie Gutenberg zum Editor, nicht zum Bearbeitungsbildschirm. Brechen Sie WordPress nicht.

Kevin Hoffman:

Ich stimme diesem Konzept von Yoast sehr zu, das meines Erachtens einen Großteil der bereits geleisteten Arbeit beibehalten würde, während der Umfang des Projekts reduziert wird, um sich auf die Editor-Komponente zu konzentrieren. Quelle: https://yoast.com/gutenberg-alternative-approach/

Ich glaube, dass der von Yoast vorgeschlagene Weg eine große Verbesserung für WordPress Core darstellen würde. Ein neuer Editor zum Erstellen von Inhalten, den viele Benutzer als Verbesserung gegenüber dem aktuellen annehmen würden. Ein kleinerer Schritt für WordPress, aber eine große Verbesserung für den Benutzer.

Dies ist ein heißes Thema. Ich gebe zu, dass wir (zumindest ich) manchmal in meinen Kommentaren abweisend sein können und ich entschuldige mich dafür. Wir erhalten viel Feedback, gut, schlecht, objektiv, nutzlos und manchmal ist es schwierig, zwischen ihnen zu unterscheiden. Wir sind menschlich. Versuchen Sie, auf der anderen Seite der Gleichung zu sein, derjenige zu sein, der dieses Ding baut und all dieses Feedback erhält. Die IT kann sich „persönlichen Angriffen“ nahe fühlen, das Gehirn reagiert eher abweisend, wir sollten es nicht tun.

Leute, die Blog-Beiträge kommentieren und lesen, denken oft, wir entdecken die Meta-Box-Probleme und alles, was damit zusammenhängt. Waren nicht. Wir arbeiten jetzt seit einem Jahr an Gutenberg. Vielleicht haben Sie Gutenberg gerade entdeckt / ausprobiert, aber wir arbeiten nicht genug daran, um mit den meisten Abwärtskompatibilitätsproblemen vertraut zu sein, und wir haben Antworten auf die meisten.

Seien Sie bitte aufgeschlossen und beantworten Sie zunächst einige Fragen:

Was ist das Ziel für Gutenberg?

Es ist nicht das Hauptziel von Gutenberg, den Weg in die Zukunft von WordPress Core zu ebnen, und es war es auch nie. Technisch gesehen können Sie mithilfe der REST-API, der clientseitigen Benutzeroberfläche und der Vereinheitlichung der Kernkonzepte: Widgets, Shortcodes, Blöcke, Inhaltsmetaboxen unter einem einzigartigen Konzept „A Block“ und erfahrungsgemäß die folgenden Fragen beantworten: Wie kann das Erstellen von Websites vereinfacht werden (denken Sie an Anpassungen)? und Veröffentlichen von Inhalten (Think Editor) in WordPress.

Was ist das Ziel für den Gutenberg Editor?

Im Gegensatz zu dem, was Sie hier und da lesen, lag der Fokus immer auf der Neugestaltung der gesamten Seite. Das erste Modell für die Gutenberg-Editor-Seite wurde im zweiten oder dritten wöchentlichen Gutenberg-Meeting gezeigt. Wir befanden uns noch in der Prototyping-Phase. Monate vor dem ersten Alpha. Das Design war nah an dem, was wir gerade haben.

Was ist mit den Metaboxen, sind sie wichtig für WordPress?

Sie sind. Wie Shortcodes, Custom TinyMCE Buttons, werden sie häufig verwendet und missbraucht, um die Editor-Seite von WordPress zu erweitern.

Was ist der Unterschied zwischen Shortcodes, TinyMCE-Schaltflächen und Metaboxen?

Der Hauptunterschied besteht darin, dass „Metaboxen“ keinen „Zweck“ haben. Es ist nur eine Möglichkeit, die Editorseite ohne Konsistenz zu erweitern, während Shortcodes und TinyMCE-Schaltflächen einen haben.

Shortcodes sind Zeichenfolgen, die in der Rendering-Phase in Inhalt konvertiert wurden. TinyMCE-Schaltflächen sind benutzerdefinierte Schaltflächen, die der TinyMCE-Symbolleiste hinzugefügt wurden und über die TinyMCE-API mit dem Inhalt des Editors kommunizieren. Metaboxen? Ich weiß nicht, sie können alles sein, Sie fügen einfach eine Reihe von HTML, Javascript und PHP hinzu, um die Seite des Editors zu erweitern und wie es sich beim Speichern verhält.

Ist dieser Mangel an „Zweck“ ein Problem oder ein Vorteil?

Gut! Es kann als "Profi" angesehen werden, da ein Plugin mit dem Editor alles tun kann, was es will, einschließlich:

• Ersetzen von Schaltflächen, Textbereichen, Eingaben, Divs und anderen Elementen. Voller Zugriff auf das DOM
• Verwenden einer beliebigen globalen Javascript-Variablen, einschließlich der globalen Instanz von TinyMCE

Flexibel richtig! Aber was ist mit WordPress-Updates? Jede Aktualisierung des Editorbildschirms. Jedes TinyMCE-Update, jede Klassenänderung, jede neue div , jede entfernte / verschobene Schaltfläche, jede Änderung beeinträchtigt die Kompatibilität mit Plugins, da Sie als WordPress-Entwickler nicht wissen, wofür Plugins Metaboxen verwenden.

Können wir daraus schließen, dass Metaboxen auf lange Sicht die Entwicklung von WordPress blockieren (unabhängig von Gutenberg)?

Ja, sind Sie. Und die Internetgeschichte hat sich so oft bewährt, dass eine Technologie, die sich nicht weiterentwickelt, stirbt. (Bitte reagieren Sie nicht mit 👎 Wenn Ihnen diese Antwort nicht gefällt, ist es eine Tatsache und keine Meinung.)

Ok, aber wie können wir WordPress vorwärts bringen, wenn wir mit Metaboxen nicht weiterkommen?

Das ist eine gute Frage, und bevor wir sie beantworten, müssen wir die aktuelle Verwendung von Metaboxen in WordPress-Plugins verstehen

Wofür verwenden die aktuellen Plugins Metaboxen?

Ich würde sagen, es gibt zwei Kategorien von "Metaboxen" -Plugins:

• Metaboxen als Inhalt (oft in Post-Meta gespeichert, aber nicht immer)
• Metaboxen als Verbesserung der Editor-Erfahrung (SEO, Rechtschreibprüfung,…)

Ok, wenn wir das wissen, wie können wir vorankommen?

Wir brauchen drei Dinge:

• Bieten Sie eine Möglichkeit, diese Plugins zu erstellen oder zu aktualisieren, während Gutenberg (oder ein Update auf WordPress) ausgeliefert wird.
• Stellen Sie die bestmöglichen Upgrade-Pfade für Benutzer dieser Plugins bereit. Dies beinhaltet: Sehen Sie, ob diese Plugins noch mit den kommenden Entwicklungen arbeiten können und wie Sie den Bruch minimieren können.

Ok, aber haben Sie nicht gesagt, dass durch Änderungen an der Editorseite Plugins beschädigt werden (einschließlich des Ersetzens nur des Inhaltsbereichs)?

Recht! Wenn wir also kein Plugin beschädigen möchten, bleibt uns eine einzigartige Option. Bieten Sie eine Möglichkeit, unverändert auf der aktuellen Bearbeitungsseite zu bleiben. Genau dafür ist das Plugin gedacht, mit dem Gutenberg deaktiviert wird.

Ich würde dies persönlich nicht als guten Upgrade-Pfad bezeichnen, es ist nicht einmal ein Upgrade, etwas Besseres?

Dieser Upgrade-Pfad (Deaktivieren von Gutenberg) ist eine Notwendigkeit, aber ja, wir können es besser machen. Wenn Sie sich die Plugins mit Metaboxen ansehen, haben 90% von ihnen keine Interaktion mit dem Inhaltsbereich. Wenn wir also nur den Inhaltsbereich ersetzen (Yoast-Ansatz), werden nur 10% der Plugins beschädigt.

Der einzige Weg ohne Bruch ist die Deaktivierung von Gutenberg.

Die optimale Gutenberg-Benutzererfahrung besteht darin, die Metabox-Plugins durch Plugins zu ersetzen, die dieselbe Funktionalität wie die neuen Gutenberg-Erweiterungs-APIs bieten.

Wir haben jedoch festgestellt, dass die meisten Plugins, die Metaboxen verwenden, diese als Inhalte verwenden, die zum Posten von Meta gespeichert werden, und wir können diese auf dem Gutenberg-Bildschirm verwenden, um die gesamte Erfahrung zu genießen, während Plugin-Autoren ihre Plugins aktualisieren.

Ist dies die Iframe-Lösung, über die alle reden?

Ja, so ist es. Wir zeigen die Meta-Boxen in Iframes, die ihre Nachteile haben (Link, Modal, Reloading-Assets), aber gleichzeitig 80% der Plugins funktionieren lassen, während sie die gesamte Gutenberg-Erfahrung genießen. Diese Lösung ist gerade gelandet und wir experimentieren immer noch damit. Sicher ist, dass es keine Möglichkeit gibt, alle Metaboxen zum Laufen zu bringen und Änderungen am Editor vorzunehmen.

Ich verstehe, können Sie die Upgrade-Möglichkeiten bitte zusammenfassen?

Sicher.

1- Gutenberg deaktivieren: Brechen Sie nicht 100% der Plugins
2- Gutenberg ersetzt nur den Inhaltsbereich: 90% der Plugins funktionieren, die UX leiden darunter
3- Gutenberg ersetzt den gesamten Bildschirm: 80% der Plugins funktionieren, die UX ist besser
4- Gutenberg mit kompatiblen Plugins: Bestmögliche UX

Was müssen wir also tun?

Unser Ziel ist es, die 4. Option zu erstellen, da dies die beste Option für die Zukunft von WordPress ist. Unser Ziel ist es auch, Gutenberg so zu bauen, dass wir seine Teile wiederverwenden können, um bei Bedarf die 2. und 3. Option zu erreichen.

Wie kann ich mich für eine Option gegenüber einer anderen entscheiden?

Dies wurde noch nicht entschieden. Ein Plugin zur Auswahl des gewünschten Upgrade-Pfads ist möglich. Ein automatisches Downgrade durch Erkennen einiger Metaboxen ist eine Option ...

Das ist meine Aufgabe, um die Gründe für diese Probleme zu erklären. Wenn Sie mit Worten wie "lächerlich", "schlecht verwaltet", "schlechte Implementierung" antworten möchten, ist dies meine Geduld als einfacher Entwickler, der das ganze Jahr über über das nachgedacht hat Der bestmögliche Weg für WordPress als Ganzes (Kern und Community) ist nahe an einer Grenze. Ich persönlich antworte möglicherweise nicht weiter auf dieses Problem, aber ich höre mir Feedback an und werde meine Argumentation anpassen, wenn ich von Feedback überzeugt bin.

Wir sind alle auf dem gleichen Boot, wir wollen das Beste für WordPress.

Sehr gründliche Erklärungen, Riad. Vielen Dank, dass Sie sich die Zeit genommen haben, sie zu schreiben. Lassen Sie mich Ihnen helfen, diese Grenze mit einem 💪 und einem 🤗 zu umgehen. Ich hoffe es hilft.

In Bezug auf Metaboxen wäre es sehr wichtig, eine Fields-API im Kern zu haben. Würde unsere Plugins neu schreiben, nur um all das Durcheinander loszuwerden. Benutzerdefinierte Metabox-Lösungen neigen dazu, sich nach einiger Zeit zu sammeln.

Für Benutzer mit komplexen Metabox-Setups ist die Fields-API die Rettung, solange sie auf einem Framework wie ACF oder CMB aufgebaut sind. Die Entwickler dieser Frameworks müssen nur auf die neue API umsteigen und alles ist gut. Keine leichte Aufgabe, aber gut für alle. Jetzt ist es für diejenigen mit "hartcodierten" Dingen, die herumliegen, eine gute Zeit wie immer, die Dinge sauberer und zukunftssicherer zu organisieren. Du bist in besserer Verfassung, Gutenberg oder nicht.

Wir sind menschlich. Versuchen Sie, auf der anderen Seite der Gleichung zu sein, derjenige zu sein, der dieses Ding baut und all dieses Feedback erhält. Die IT kann sich „persönlichen Angriffen“ nahe fühlen, das Gehirn reagiert eher abweisend, wir sollten es nicht tun.

Es gibt Menschen, die sehr hart an Gutenberg arbeiten. Es gibt Menschen, deren Lebensunterhalt (ihre Themen und Plugins) von Gutenberg betroffen sein wird. Und es gibt Menschen, die die von Gutenberg betroffenen Themen und Plugins verwenden, um ihre eigene Arbeit zu erledigen. Wir alle achten aufeinander und wollen am Ende des Tages das Beste für WordPress. Obwohl wir uns leidenschaftlich darüber streiten können, was "am besten" bedeutet.

Im Gegensatz zu dem, was Sie hier und da lesen, lag der Fokus immer auf der Neugestaltung der gesamten Seite. Das erste Modell für die Gutenberg-Editor-Seite wurde im zweiten oder dritten wöchentlichen Gutenberg-Meeting gezeigt ...

Modelle allein signalisierten nicht, dass die Codebasis der gesamten Bearbeitungsseite in React neu geschrieben werden würde. Niemand hätte bei einem Modell wissen können, dass kritische Haken entfernt oder Meta-Boxen beschädigt werden. Als mir jedoch klar wurde, dass die ganzseitige Übernahme ein Problem für Meta-Boxen darstellen würde, äußerte ich diese Besorgnis am 15. Juni , einen Tag bevor 0.1.0 für die Veröffentlichung markiert wurde. Vier Monate und 15 Releases später sahen wir zum ersten Mal Meta-Boxen in der Benutzeroberfläche innerhalb von iframes.

Ich habe dieses Problem basierend auf meiner Erfahrung erstellt, die Gutenberg seit seiner Zeit vor dem Alpha genau verfolgt und getestet hat. Dies ist nur das neueste Problem im Zusammenhang mit laufenden Meta-Box-Herausforderungen. Wichtig ist jedoch, dass es das erste ist, das auf konkreten Tests einer Meta-Box-Implementierung von Gutenberg basiert.

Der Hauptunterschied besteht darin, dass „Metaboxen“ keinen „Zweck“ haben. Es ist nur eine Möglichkeit, die Editorseite ohne Konsistenz zu erweitern, während Shortcodes und TinyMCE-Schaltflächen einen haben.

Dies signalisiert erneut ein grundlegendes Missverständnis darüber, wie Meta-Boxen von Plugin- und Theme-Entwicklern verwendet werden. Wir erwarten, dass Shortcodes und TinyMCE-Schaltflächen angepasst werden müssen, da sie tatsächlich im Inhaltseditor verwendet werden. Meta-Boxen sind nicht.

Der Vorschlag, dass Meta-Boxen - die Grundbausteine ​​der benutzerdefinierten WordPress-Entwicklung - keinen Zweck mehr haben, zeigt der Community erneut, dass Gutenberg die Kernerfahrung einer "Neuinstallation" auf Kosten von Plugin- und Theme-Entwicklern priorisiert.

Jede Aktualisierung des Editorbildschirms. Jedes TinyMCE-Update, jede Klassenänderung, jede neue Div, jede entfernte / verschobene Schaltfläche, jede Änderung beeinträchtigt die Kompatibilität mit Plugins, da Sie als Core WordPress-Entwickler nicht wissen, wofür Plugins Metaboxen verwenden.

Wir kennen möglicherweise nicht den Zweck einer Meta-Box, aber wir kennen die grundlegenden Anforderungen für die Registrierung einer Meta-Box und die von ihnen verwendeten Hooks. Wir wissen, dass keiner von ihnen entwickelt wurde, um innerhalb von iframes zu arbeiten. Seit Jahren verstehen wir, wie man WordPress erweitert und verbessert, ohne sie zu beschädigen. Wenn 5.0 nur eine andere WordPress-Version ist, sollte sich das Ausmaß des Bruchs nicht von jeder anderen Version unterscheiden.

Wir zeigen die Meta-Boxen in Iframes, die ihre Nachteile haben (Link, Modal, Reloading-Assets), aber gleichzeitig 80% der Plugins funktionieren lassen, während sie die gesamte Gutenberg-Erfahrung genießen.

Wenn Sie Beweise für diese 80% / 90% -Zahlen haben, auf die ständig verwiesen wird, teilen Sie diese bitte mit. Andernfalls verwenden Sie bitte keine hypothetischen Statistiken, wenn Sie die Community bitten, eine Entscheidung dieser Größenordnung zu treffen.

Bitte stoppen Sie und bewerten Sie jetzt neu, nicht später

Nach all dieser Diskussion und dem, was ich für den Beweis hielt, dass Iframes keine tragfähige langfristige Lösung sind, stieß ich auf https://github.com/WordPress/gutenberg/issues/3165#issuecomment -341476059, das eine dritte hinzufügen soll

Es ist an der Zeit, den idealen Editor nicht mehr zu verfolgen, als ob es keine Einschränkungen gäbe, und einen Ansatz in Betracht zu ziehen, der WordPress nicht kaputt macht.

Als Entwickler, der den Gutenberg-Editor vom ersten Tag an beobachtet und diskutiert hat, muss ich leider sagen, dass Riads Argument einige große Lücken aufweist.

Erstens haben die Leute seit dem ersten Tag das Thema Metaboxen angesprochen, zusammen mit einigen anderen Themen, die noch in der Luft sind. In der Mockup-Phase wurde uns gesagt, "alles ist ein visueller Bestfall, wir werden uns später mit Metaboxen befassen". In der Prototypenphase war es dann "Dies ist alles Proof-of-Concept-Code, Metaboxen werden später behandelt". Dann, als die erste Iteration des Feature-Plugins veröffentlicht wurde (was für niemanden eine große Überraschung war, schließlich kein Umschreiben von Grund auf neu und nur ein Umpacken des aktuellen Proof-of-Concept-Codes), wurde das Argument plötzlich "Legacy-Schnittstellen wie Metaboxen werden vorerst unterstützt". Dann, als der öffentliche Aufschrei ohrenbetäubend wurde, war es "wir haben falsch geschrieben, Metaboxen sind kein Vermächtnis". Aber jetzt drängt dieses Argument nur noch einmal auf die "Legacy" -Agenda.

Metaboxen sind kein Legacy-Code, da es derzeit keinen brauchbaren Ersatz gibt.

In Metaboxen kann ich mit wp_editor trivial einen verschachtelten Editor mit vollem Funktionsumfang hinzufügen. Gutenberg hat derzeit keine Benutzeroberfläche für verschachtelte Blöcke und ist nicht für die Version 5.0 vorgesehen. Daher kann es ohne eine große Menge an benutzerdefiniertem Benutzeroberflächencode nicht das Gleiche tun.

Das ist ein einziges Beispiel, aber eine Verschlechterung der Erfahrung mit Metaboxen ist keine akzeptable Lösung, bis Gutenberg nicht mehr paritätisch ist. Das wird mit WP 5.0 nicht passieren

Hier ist eine Roadmap zum "Unified Admin" -Plan für Gutenberg, die tatsächlich funktionieren würde:

• Beschränken Sie die Erstfreigabe auf den Bereich, der derzeit von wp_editor gefüllt wird, stellen Sie jedoch die vollständige Block-Benutzeroberfläche in diesem Bereich bereit
• Fördern und erweitern Sie die Flexibilität und Funktionen, die die Block-Benutzeroberfläche bietet, indem Sie eine Feld-API versenden, die das Entwerfen in diesem Bereich trivial macht
• Wenn die Popularität zunimmt, ersetzen Sie andere Teile der Benutzeroberfläche durch ähnliche Gutenberg-Instanzen mit Sandbox. Menüs, Widgets, Customizer und die Medienbibliothek sind Schnittstellen, die für Entwickler relativ stagnieren und von einer gemeinsamen UI-Struktur profitieren könnten.
• Wenn die allgemeine Benutzeroberfläche flexibler und leistungsfähiger wird, wird sie über Metaboxen verwendet, da sie eine Reihe gemeinsamer Tools und mehr Optionen bietet
• Verschmelzen Sie allmählich die Löcher zwischen den isolierten Gutenberg-Instanzen, da die Entwicklung in diesen Räumen stagniert.

Auf diese Weise können Entwickler Gutenberg für Produktionstools verwenden, ohne die aktuellen Funktionen zu verlieren. Gutenberg wird von allen Edge-Anwendungsfällen profitieren, die für diese Entwickler entwickelt wurden, und eine flexible Lösung schaffen, die tatsächlich den Anforderungen derjenigen entspricht, die derzeit Metaboxen verwenden.

Wenn die Metaboxen veraltet sind, haben die Plugin-Autoren genügend Zeit, um die Vorteile von Gutenberg in freier Wildbahn kennenzulernen und zu nutzen, und dies ist die naheliegende Wahl.

Gutenberg ist wie ein Konzeptauto. Skalieren Sie jetzt zurück und senden Sie eine iterative Verbesserung an den Editor (nicht an die Editorseite). In den nächsten ein oder zwei Jahren können Sie das Projekt dann auf eine 100% ige Administratorabdeckung ausrichten.

Ich möchte nur aus der Perspektive eines Kundendienstanbieters einsteigen, der sich auf das lautstarke Engagement von WordPress für die Abwärtskompatibilität bezogen hat, um die Bedenken der Kunden hinsichtlich Aktualisierungen ihrer Websites zu zerstreuen. Damit erkenne ich, dass meine Verwendung von WordPress wahrscheinlich meine Wahrnehmung des Bearbeitungsbildschirms verzerrt / verzerrt hat.

Bisher scheint dieses Problem behoben / verworfen / heruntergespielt worden zu sein, als in meiner Welt Meta-Boxen ein wichtiges Verkaufsargument für WordPress waren, da benutzerdefinierte Beitragstypen für eine breite Verwendung leicht verfügbar wurden. Ich bin froh, dass diese Diskussion stattfindet.

Gutenberg ist ein beeindruckendes Projekt, ja, aber die Kunden, mit denen ich gearbeitet habe, sind sehr zufrieden mit den Meta-Box-basierten Lösungen, die ihnen zur Verfügung gestellt wurden. Eine Option zum Deaktivieren von Gutenberg zu haben ist nett, aber ich mache mir Sorgen, dass es über das Plugin deaktiviert wird. Trotz meiner Bemühungen, Kunden zu coachen, kann ich mir nicht vorstellen, dass sie bereit wären, ein neues Plugin selbst zu installieren, und sie würden auch nicht wissen, was Gutenberg ist, selbst wenn es auf einem Begrüßungsbildschirm für Upgrades offensichtlich ist.

Es ist möglich (vielleicht sogar wahrscheinlich), dass die Meta-Box-Plugins, die ich auf Client-Websites verwendet habe, so aktualisiert werden, dass sie "Gutenberg-kompatibel" sind, aber selbst dann wird sich der gesamte Workflow für diese Clients über Nacht ändern. Es fühlt sich so an, als würde es viele dieser Kunden fragen, wann ihr bestehender Workflow für sie gut funktioniert hat, seit ihre Website jedoch vor langer Zeit geliefert wurde.

Ich stehe voll und ganz hinter dem Ziel von Gutenberg, die Benutzererfahrung zu verbessern, aber meiner Meinung nach können wir den Präzedenzfall nicht vermeiden, der geschaffen wurde (absichtlich oder nicht), um Meta-Boxen für die Bearbeitung von Inhalten zu verwenden. Ich denke, Yoasts Ansatz ist großartig. Er aktiviert eine Reihe von Kontrollkästchen für eine Vielzahl möglicher Lösungen für dieses Problem.

Nur meine zwei Cent, ich freue mich darauf, das Ergebnis hier zu beobachten.

Die Anzahl der Plugins, die mit Gutenberg arbeiten, kann 80%, 90% oder 0% betragen. Wie in unseren Tests sollte vermieden werden, dass Tausende und Abertausende von Websitebesitzern selbst herausfinden müssen, ob ihre Konfiguration wahrscheinlich funktioniert oder nicht mit Gutenberg. Das wäre eine enorme Zeitverschwendung (= Geld), würde viel Verwirrung stiften und viel Vertrauen zerstören.

Ich würde gerne Plugins / Themes sehen, die als kompatibel / nicht kompatibel mit Gutenberg (oder "nicht relevant") markiert sind, damit Websitebesitzer über mögliche Probleme informiert werden können, bevor diese Sache auf ihren Websites aktiv wird, und entsprechend handeln können. Daten könnten nicht nur von Plugin-Besitzern stammen, sondern auch von Community-Tests während der Beta-Testzeit (die echte Beta ... und diese Zeitspanne sollte lang sein, nicht nur einige Wochen.) Und darüber hinaus.

Mir ist bewusst, dass dies niemals vollständig oder 100% genau sein wird, aber für die bekanntesten Plugins machbar sein sollte.

PS.
Für meine eigenen Projekte (eine Intranet-Microsites-Plattform für einen Kunden> 30.000 Mitarbeiter und eine Reihe von Websites für kleine Unternehmen / gemeinnützige Organisationen) haben wir beschlossen, Gutenberg zu deaktivieren, bis es mindestens ein Jahr in freier Wildbahn erfolgreich ist.

Prozentsätze erzählen sowieso nicht die ganze Geschichte. Bei jeder Diskussion über die Auswirkungen von Gutenberg muss berücksichtigt werden, wie viele Websites von der Metabox-Implementierung betroffen sind und nicht, wie viele Plugins betroffen sind. Gutenberg könnte nur eine Handvoll Plugins betreffen und dennoch Millionen von Benutzern betreffen, da einige der am häufigsten verwendeten Plugins von Metaboxen und benutzerdefinierten Feldern abhängen - ACF und Yoast SEO sind zwei offensichtliche Beispiele.

Ich verfolge die Entwicklung von Gutenberg schon seit vielen Monaten aus der Ferne und weiß, dass es das Problem der Metaboxen schon lange gibt. Ich unterstütze die Philosophie hinter Gutenberg und ich denke, dass Gutenberg irgendwann ein sehr leistungsfähiger Teil des WordPress-Kerns werden wird, der es WordPress ermöglicht, in Zukunft für viele Jahre eine tragfähige und wettbewerbsfähige Software zu sein. Ich bin mit dem gesamten Konzept von Gutenberg und seinem Ziel so einverstanden.

Was ich nicht verstehe, ist der Wunsch, auf einmal von 0 auf 100 zu kommen. Warum ist eine iterative Veröffentlichung nicht der Weg, der hier eingeschlagen wird? Warum sind die beiden Optionen "nichts brechen" oder "alles brechen"?

Metaboxen sind der Grund, warum WordPress so leistungsfähig ist wie es ist. Der Zweck besteht darin, den Bearbeitungsbildschirm zu erweitern.

Ich finde es großartig, dass Gutenberg den gesamten Bildschirm überarbeiten möchte, aber ich denke nicht, dass dies auf einmal realistisch ist, insbesondere wenn es darum geht, eine der wichtigsten Komponenten von WordPress zu behandeln (was die kundenspezifische Entwicklung betrifft ist ein großer großer Teil des Erfolgs von WordPress) beiseite.

2- Gutenberg ersetzt nur den Inhaltsbereich: 90% der Plugins funktionieren, die UX leiden darunter

Die UX leidet nicht. Die Benutzer sehen es als den Editor-Bereich, der überarbeitet wird. Es gibt ihnen eine neue Möglichkeit, Inhalte zu erstellen - eine Möglichkeit, die die meisten von ihnen nach der Anpassung als befähigend empfinden, und es wird keinen bestehenden Workflow unterbrechen oder sie fragen sich, wie sie die Dinge erreichen sollen, die sie früher erreicht haben der Editor.

4- Gutenberg mit kompatiblen Plugins: Bestmögliche UX

Dies ist ein ausgezeichnetes Ziel, aber es ist das langfristige Ziel. Letztendlich sollte es Gutenberg mit Plugins sein, die neben oder innerhalb der Guteneberg-Erfahrung funktionieren.

Unser Ziel ist es auch, Gutenberg so zu bauen, dass wir seine Teile wiederverwenden können, um bei Bedarf die 2. und 3. Option zu erreichen.

Ich bin mir nicht sicher, was das bedeutet. Sie möchten Gutenberg mit der Annahme erstellen, dass alle Plugins einfach damit funktionieren, und diese Lösung verwenden, um zu Option 2 und 3 zurückzukehren? Bauen Sie zuerst auf 2 und dann auf 3. Wird uns das nicht auf 4 bringen?

Ich mag die von @gschoppe vorgeschlagene Roadmap als Entwickler, der benutzerdefinierte WordPress-Websites erstellt. Dies ist ein Ansatz, den ich unterstützen kann, der sich nicht negativ auf Entwickler oder deren Kunden oder normale WordPress-Benutzer auswirkt und uns dennoch ans Ende bringt Ziel von Gutenberg - wenn auch in einem Tempo, das leichter zu schlucken ist.

Neben Kevins Bedenken hinsichtlich der Iframes möchte ich auf einige Bedenken hinsichtlich der Zugänglichkeit hinweisen. Erstens, während Benutzer, die eine Site visuell erleben, Framesets und Iframes zusammen mit dem Rest der Seite als zusammenhängendes Ganzes erleben, tun dies Benutzer von Bildschirmleseprogrammen nicht. Benutzer von Bildschirmleseprogrammen erleben jeden Frame innerhalb eines Framesets und jeden Iframe als eigenständigen Teil, der vom Rest der Seite getrennt ist, da Webseiten linear erlebt werden. Einige Bildschirmleseprogramme (insbesondere Jaws für Windows, das laut WEBAIMs jährlicher Umfrage zur Verwendung von Bildschirmleseprogrammen den größten Marktanteil aufweist) verfügen über eine Konfigurationseinstellung, mit der Frames, einschließlich Inline-Frames, ignoriert werden können, da sie für einige Bildschirme so störend sein können Leser Benutzer. Wenn die Einstellung Frames ignorieren aufgerufen wird, verschwindet der Inhalt in Frames und Iframes. Selbst wenn Gutenberg alle bewährten Methoden für Barrierefreiheit befolgt, wenn es um Iframes geht. Wenn Benutzer aufgefordert werden, diese Einstellung zu deaktivieren, um Inhalte vollständig bearbeiten zu können, sind sie jeder einzelnen Instanz der schlechtesten Iframe- und Frame-Praktiken im Internet ausgesetzt. Die einzige andere Alternative für diese Benutzer besteht darin, sie zu bitten, ein separates Profil zu erstellen, um Gutenberg zu verwenden. Dies ist kein einfacher Vorgang, da sie jede einzelne Browsereinstellung und Spracheinstellung erneut konfigurieren müssen. Dies bedeutet auch, dass sie mit mindestens zwei separaten Browserprofilen Schritt halten müssen. Ich werde die erste Person sein, die Jaws für Windows-Benutzer aus Gründen anweist, ganztägig auf NVDA zu migrieren. Gutenberg, der Iframes für die Unterstützung von Metaboxen verwendet, ist keiner dieser Gründe.

.. meine Geduld als einfacher Entwickler, der das ganze Jahr über über den bestmöglichen Weg für WordPress als Ganzes (Kern und Community) nachgedacht hat, ist nahe an einer Grenze.

Ich schwöre, ich hasse es, unhöflich zu sein, aber in diesem Fall müssen Sie möglicherweise dickere Haut bekommen. Sie sind frustriert über die Reaktionen angesichts eines "ganzen Jahres", in dem Sie darüber nachgedacht haben, und danken Ihnen dafür, aber dies sind Entscheidungen, die sich auf mehrere Jahre Arbeit auswirken werden, die andere geleistet haben.

In meinem Fall kann nach dem, was ich lese, fast jede Website, die ich in den letzten 3 Jahren erstellt habe, sofort kaputt gehen. Ich bin nicht mehr für diese Websites verantwortlich, aber was wird in der Agentur passieren, in der ich früher gearbeitet habe, wenn Dutzende von Kunden gleichzeitig mit defekten Websites anrufen. Wie wird sich das auf diese kleine Agentur auswirken, auf ihre tägliche Arbeit, auf ihr Endergebnis? Wie wird sich das auf ihre Kunden auswirken? Das sind meine Anliegen und ich bin nur ein kleiner (bildlicher) Entwickler in diesem relativ großen Ökosystem.

Ich gebe zu, dass wir (zumindest ich) manchmal in meinen Kommentaren abweisend sein können und ich entschuldige mich dafür.

Die Leute sind besorgt und frustriert und es scheint mir, dass sie jedes Recht dazu haben, weil die Wahrnehmung ist, dass das Team, das an Gutenberg arbeitet, wenig Verständnis dafür hat, wie Meta-Boxen verwendet werden, und wenig Bedenken hinsichtlich der Auswirkungen hat. und wird mit ihrer Vision vorankommen, egal was passiert.

Es macht mich traurig, dies zu schreiben, aber ich würde in einer Million Jahren nicht vorschlagen, dass jemand gerade ein großes Projekt mit WordPress startet.

2- Gutenberg ersetzt nur den Inhaltsbereich: 90% der Plugins funktionieren, die UX leiden darunter

@youknowriad , wie kannst du sagen, dass die UX nicht mit Gutenberg gegen TinyMCE leidet? Ich stelle diese Frage wirklich und schnarche nicht. Ich kann Ihnen sagen, dass die UX in Gutenberg im Vergleich zu TinyMCE und Meta-Boxen tatsächlich stark leidet. Ich möchte Sie ermutigen, dies selbst herauszufinden, indem Sie:

(1) Ziehen Sie den Stecker Ihrer Maus heraus.
(2) Wenn Sie auf einem Mack sind, drücken Sie Befehl + f5 und versuchen Sie, mit VoiceOver etwas Produktives zu erreichen.
(3) Wenn Sie sich auf einem PC befinden, laden Sie NVDA herunter, installieren Sie es, ziehen Sie den Stecker aus der Maus und führen Sie denselben Test durch. Versuchen Sie unter diesen Umständen, mit Gutenberg etwas Produktives zu machen.

Ich denke, Sie werden feststellen, dass die UX zu diesem Zeitpunkt ein absoluter Albtraum ist. Das heißt nicht, dass es sich nicht zum Besseren ändern kann. Gutenberg bietet WordPress die Möglichkeit, eine Menge technischer Schulden in Bezug auf die Barrierefreiheit zu beseitigen. Wenn dies sorgfältig und korrekt durchgeführt wird, können einige große Erfolge erzielt werden. Wenn dies jedoch falsch oder nachlässig gemacht wird, muss ein Großteil der Arbeit, die das WordPress Accessibility Team und andere wichtige Mitarbeiter seit 2012 geleistet haben, erneut begonnen werden. Ich würde gerne sehen, dass WordPress als Projekt nicht den gleichen Fehler macht, mit dem es begonnen hat: Die Barrierefreiheit im Internet von Anfang an nicht zu berücksichtigen, was bedeutet, dass das Barrierefreiheitsteam und andere betroffene Mitwirkende die Barrierefreiheit nachträglich verstärkt haben, was eine Aufgabe ist das kann man nie nachholen, da WordPress keine stagnierende Codebasis ist.

Ich verstehe, dass ihr seit einem Jahr an Gutenberg arbeitet. Ich verstehe auch, dass es an und für sich schwierig ist, daran zu arbeiten, und dass negatives Feedback dieser Situation nicht hilft. Schließlich verstehe ich, dass es den Anschein hat, als würden diejenigen von uns, die genauso kritisch sind wie wir, Ihr Baby als hässlich bezeichnen oder nur auf die Angst vor Veränderungen reagieren, und als Schöpfer ist das bestenfalls frustrierend und im schlimmsten Fall verletzend . Aber für mich selbst ist das Baby nicht hässlich. Es hat viel nicht realisiertes Potenzial, entweder das coolste Kind auf dem Block zu sein oder der kleine Trottel, der das Leben aller unglücklich macht. Ich würde gerne sehen, dass es das erstere und nicht das letztere ist. Insbesondere in Bezug auf Meta-Boxen sind sie ein wichtiger Bestandteil der benutzerdefinierten Entwicklung von WordPress, wahrscheinlich auch Shortcodes oder TinyMCE-Schaltflächen. Sie sollten nicht leicht abgebürstet oder in einen Iframe geschoben werden, bis wir herausfinden können, wie wir sie loswerden können.

Meine einfache Geschichte mit WordPress ist, dass es seit mehr als einem Jahrzehnt meine bevorzugte Website-Engine für die Erstellung von Websites für Privat-, Kleinunternehmens- und Unternehmenskunden ist. In dieser Zeit gab es drei Dinge, die WordPress zum Werkzeug der Wahl gemacht haben:

1. Open Source. Ich denke, dieses Publikum kann zustimmen, wie mächtig und vorteilhaft dies ist.
2. Benutzerfreundlichkeit. WordPress machte es Nicht-Entwicklern erstaunlich einfach, Inhalte zu erstellen und zu aktualisieren. Dies war in meinen frühen Jahren beim Erstellen von Websites für Einzelpersonen und Unternehmen enorm.
3. Inhalt definieren. Benutzerdefinierte Beitragstypen, benutzerdefinierte Taxonomien und benutzerdefinierte Meta-Boxen. Wenn alles, was dazu führte, eine Singularität erreichte, glaube ich nicht, dass ich es erreiche, wenn ich sage, dass WordPress als mehr als nur Blog-Software für die Geschäftswelt „verkaufbar“ war. (WordCamp Phoenix 2012 - CMB. Justin Tadlocks großartiges Schreiben zur Definition von Beitragstypen, Taxonomien und Meta-Boxen.)

Ich würde sogar sagen, dass benutzerdefinierte Meta-Boxen - diese Fähigkeit, benutzerdefinierte Administrationsoberflächen zu erstellen und eine großartige Benutzererfahrung für Menschen zu schaffen, ist enorm. Brechen Sie das, und Sie brechen WordPress .

Die Idee hinter Gutenberg, die den Content-Editor leistungsfähiger macht, ist eine großartige Idee. Es lohnt sich, aber es muss richtig gemacht werden, mit Sorgfalt und nicht gehetzt. Im Moment fühlt es sich sehr gehetzt an und bei weitem nicht bereit.

@jchristopher sagt es sehr gut:

Ich stehe voll und ganz hinter dem Ziel von Gutenberg, die Benutzererfahrung zu verbessern, aber meiner Meinung nach können wir den Präzedenzfall nicht vermeiden, der geschaffen wurde (absichtlich oder nicht), um Meta-Boxen für die Bearbeitung von Inhalten zu verwenden. Ich denke, Yoasts Ansatz ist großartig. Er aktiviert eine Reihe von Kontrollkästchen für eine Vielzahl möglicher Lösungen für dieses Problem.

@jnicol und @aurooba machen tolle Punkte und stellen gute Fragen. Warum scheint es alles oder nichts zu sein, anstatt eher eine iterative Roadmap? Yoasts Alternative ist viel vernünftiger als das, was man gesehen hat, und ich denke, das „Iframe-Experiment“ beweist diesen Punkt. Vielen Dank, @amandarush , dass Sie die Probleme mit der Barrierefreiheit

@aaronjorbin sagte es früher, wenn jemand WordPress übernimmt, übernimmt er nicht WordPress (Versionsnummer hier), sondern WordPress als Ganzes.

Es gibt eine andere Version davon, die wahrscheinlich jeder im Kundenservice oft hört. Wenn jemand zu Ihnen kommt und sagt, dass er eine neue Website benötigt (wir sprechen nicht über Blogs), sagt er im Allgemeinen nicht: "Ich brauche eine neue Wordpress-Website" oder "Ich möchte eine neue Drupal-Website" usw. Sie wollen nur eine neue Site, die funktioniert und gut funktioniert.

WordPress war die beste Lösung für Millionen von Websites: Benutzerfreundlichkeit und Open Source sind der Schlüssel. Das Aufbrechen von benutzerdefinierten Meta-Boxen (vergessen Sie die Plugin-Nummern, wie wäre es mit allen vorhandenen Websites mit benutzerdefinierten Administrator-Benutzeroberflächen?) Mit einer überstürzten Implementierung einer neuen Editor-Oberfläche schadet dieser Benutzerfreundlichkeit.

Meine Geduld als einfacher Entwickler, der das ganze Jahr über über den bestmöglichen Weg für WordPress als Ganzes (Kern und Community) nachgedacht hat, ist nahe an einer Grenze.

Ich werde hier stumpf sein:

Dieser und einige andere Kommentare wie dieser lassen mich denken, dass einige von Ihnen sich von den Entscheidungsrollen in diesem Projekt entfernen sollten. Wenn Sie kein ehrliches, gut durchdachtes, aber kritisches Feedback zu einem Produkt erhalten können, sollten Sie ehrlich gesagt keine Entscheidungsrolle in einem Produktteam übernehmen. Ich war mehrere Male in Ihren Schuhen, normalerweise in persönlichen Gesprächen, und in den erfolgreichen Fällen wurde allen im Raum klar, dass es darum ging, das bestmögliche Produkt für die Kunden zu liefern, egal wie heiß die Debatte wurde. Kritik an Produktideen und -richtungen zu üben, gehört dazu, Entscheidungsträger in einem Produktteam zu sein, und sollte zu einem besseren Produkt führen, da sich niemand vorstellen kann, wie man am besten alles macht. Das gilt auch für Teams.

Ich habe keinen Zweifel daran, dass jeder im Kernteam eine großartige Version von WordPress liefern möchte, aber Sie kommen unweigerlich einem Projekt nahe. Sie wissen, was diskutiert, überlegt, abgelehnt usw. wurde, und es ist schwierig, Dinge von außen zu betrachten. Aber Sie sind nicht die Gesamtheit der WP-Community. du kannst nicht sein Was Sie hören, sind berechtigte Bedenken hinsichtlich der Produktrichtung. Wenn Sie das nicht berücksichtigen können, denken Sie darüber nach, was gesagt wird und warum es gesagt wird, und treten Sie bitte von Entscheidungen über die Richtung von Gutenberg zurück.

Alternativ (und das wäre weitaus besser) nehmen Sie diese Gedanken auf. Überlegen Sie wirklich, was die Leute sagen. Verstehen Sie unsere Bedenken als Menschen, die Unternehmen betreiben, die WordPress verwenden, und verstehen Sie, dass wir uns nicht nur um uns selbst, sondern auch um unsere Kunden sorgen.

Ich benutze WP seit Anfang 2008 und kann mir keine neue Funktion oder Entscheidung vorstellen, die in all dieser Zeit so viel Spaltung verursacht hat wie die Einführung von Gutenberg in seiner aktuellen Form.

WordPress richtet sich zwar an die Benutzer, ist jedoch nur ein Tool, und Benutzer können dieses Tool einfach nicht verwenden, wenn sie nicht über die WP-Experten verfügen, die ihnen beim Erreichen ihrer Ziele helfen.

Ich sehe Hinweise darauf, dass ich den Benutzern einer Neuinstallation gerecht werden möchte (was? ~ 1% des Webanstiegs pro Jahr?), Aber das scheint auf Kosten der vorhandenen Benutzerbasis (~ 28%) zu gehen Die meisten davon führen wahrscheinlich ein Plugin mit mindestens einer Meta-Box aus. Das scheint in jeder Größenordnung ein schlechter Geschäftssinn zu sein.

Ich verstehe die Ideologie: Erstellen Sie einen Best-Case-Editor und verwenden Sie dann ein Adaptermuster, um alte mit neuen zu sprechen. Das Problem ist, dass PHP und JS unterschiedliche Technologien sind und die Weitergabe dieses Problems an das Land der HTML-Iframes aus allen zuvor genannten Gründen nicht möglich ist.

Es war der erste Durchgang, es war ein Experiment, aber diese Anstrengung ist nicht erfolgreich. Je schneller dies bestätigt wird, desto schneller können wir mit dem nächsten Vorschlag fortfahren.

Niemand hat eine geeignete Lösung gefunden, wenn es um Meta-Boxen geht, die jedoch alle Beteiligten zufriedenstellen.

Das bedeutet, dass eine Partei nachgeben muss - und ob das 10-50 Pro-Gutenberg-Entwickler sind oder Hunderte / Tausende von Entwicklern, die Angst haben oder welche Auswirkungen die Änderungen auf sie haben werden, geschweige denn auf ihre Benutzer, wir werden sehen.

Sobald alle Vorschläge zur Problemumgehung erschöpft sind, gibt es möglicherweise ein Zugeständnis, dass das Überschreiben der gesamten Seite nicht für alle Parteien möglich ist. Zumindest nicht in dem einzigen Treffer, der gerade versucht wird.

Um auf die ursprüngliche Frage zurückzukommen: Sind Iframes die langfristige Lösung für Meta-Boxen? Mehrere Entwickler (und wir dürfen nicht vergessen, dass sie auch Benutzer sind) haben erklärt, warum die Antwort Nein lautet.

Wir haben hier eine weitgehend konstruktive Diskussion geführt. Merken:

Wir kritisieren Ideen, Code und Pixel, nicht die Menschen dahinter. Wir haben möglicherweise unterschiedliche Meinungen über den besten Weg nach vorne, stellen jedoch keine Anmeldeinformationen in Frage. Wenn wir uns an Einzelpersonen wenden, müssen wir sie hochheben und ihnen Anerkennung für eine gut gemachte Arbeit zollen. Da auf der Welt so viel los ist, müssen wir aufeinander aufpassen. Dies ist eine monumentale Herausforderung, aber wir werden es gemeinsam schaffen.

Lassen Sie mich alle daran erinnern, dass Metaboxen in Gutenberg das Ergebnis eines @ BE-Webdesigns waren, das verstärkt und durchgeführt wurde, unabhängig von allen anderen mit wenig Hilfe, die aus dem Nichts auftauchten. Ohne @ BE-Webdesign gäbe es in Gutenberg keine Metaboxen. Von den 47 hier hinterlassenen Kommentaren haben vielleicht nur 2 Personen den Metabox-Code tatsächlich für Überprüfungs- und UX-Zwecke berührt.

Das grundlegende Problem hierbei ist jedoch, wie die Metaboxen als Bürger erster Klasse sicher auf die Seite gebracht werden können, ohne unsicheren Code zu erstellen, was zu einem Kompromiss zwischen hackigen Kludges oder Fallstricken führt.

• Die erste Iteration beinhaltete ein Gotcha, bei dem WP so tat, als wäre es auf der Seite edit.php , und die Metaboxen auf diese Weise generierten. Erste Berichte zeigten, dass es Kompatibilitätsprobleme hatte und super hackig war und keine praktikable Lösung. Dies liegt daran, dass viele Plugins Metaboxen nur registrieren, wenn bestimmte Umstände erfüllt sind, und WP nicht vertrauen, dass sie wissen, wann sie gerendert werden sollen
• Die zweite Iteration, die zusammengeführt wurde, verwendet Iframes, sodass die Metaboxen im klassischen Editor angezeigt werden, obwohl alles außer der Metabox entfernt wurde. Das ist ein bisschen klobig, aber es hat Metaboxen zum Laufen gebracht, wenn auch mit Problemen
• Es gibt auch eine Lösung, bei der wir den HTML-Code abrufen und ihn dann im Großhandel in eine Komponente einfügen. Dies wäre eine Sicherheitskatastrophe, obwohl dies eine sehr offensichtliche Lösung ist. Deshalb wurde es nicht so gemacht.

Mein Vorschlag ist:

Anstatt Gutenberg auf einer Einstellungsseite zu laden, können Sie es in die klassische Editorseite laden, Metaboxen in ihre native Umgebung laden und dann ihren Container-DOM-Knoten über JS in eine Komponente heben

Wir verwenden dann eine andere Art von Umschalter, um sicherzustellen, dass der klassische Editor weiterhin verwendet werden kann. Diesen Weg:

• Wir vermeiden den Iframe-Unsinn
• Metaboxen funktionieren wie immer bei der Registrierung
• Das vorhandene JS funktioniert wie erwartet, und es sind keine Hacks erforderlich, damit die Dinge auf PHP-Seite funktionieren

Auch das Yoast-Design ist hübsch, aber wohin geht Block-Meta?

Leider habe ich sehr wenig Erfahrung mit js auf dem Niveau, das erforderlich ist, um tatsächlichen Code zu Gutenberg beizutragen. Ich fange erst an, meine Zehen in die Welt der Entwicklung von WordPress einzutauchen, anstatt darüber zu entwickeln. Das Beste, was ich tun kann, ist, mein Feedback zu geben, den Editor zu testen (ich verwende Gutenberg aktiv in meinem persönlichen Blog) und Vorschläge / Gedanken zu machen. Wenn ich Code beitragen könnte, würde ich absolut. Wenn es einen anderen Weg gibt, wie ich helfen kann, würde ich gerne wissen. Weil mir das sehr wichtig ist. :) :)

Beiträge gibt es in vielen Formen. Während die Zeit und der Aufwand für die Entwicklung dieses Versuchs gewürdigt werden, können die Tests und Diskussionen, die zukünftige versunkene Kosten verhindern, ebenso wertvoll sein. Beispielsweise gibt es eine Reihe neu geöffneter Probleme im Zusammenhang mit der Iframe-Implementierung. Wir könnten noch viele Stunden in den Versuch investieren, diese Probleme zu beheben, oder wir könnten die Tests und Gründe in diesem Thread verwenden, um festzustellen, ob eine andere Richtung erforderlich ist. Ich hoffe, das ist die Erkenntnis, zu der wir als Gruppe gekommen sind.

Lassen Sie mich alle daran erinnern, dass Metaboxen in Gutenberg das Ergebnis eines @ BE-Webdesigns waren, das verstärkt und durchgeführt wurde, unabhängig von allen anderen mit wenig Hilfe, die aus dem Nichts auftauchten. Ohne @ BE-Webdesign gäbe es in Gutenberg keine Metaboxen.

Obwohl das Lob und die Anbetung nett sind, hatte ich definitiv Hilfe, und es ist größtenteils eine Teamleistung von vielen Menschen.

Mein Vorschlag ist:

Anstatt Gutenberg auf einer Einstellungsseite zu laden, können Sie es in die klassische Hauptseite der Editoren laden,> Metaboxen in ihre native Umgebung laden und dann ihren Container-DOM-Knoten über JS in eine Komponente heben

Ja, dies ist höchstwahrscheinlich die nächste Iteration, und ich denke, dies ist ein großartiger Vorschlag sowie eine konstruktive Idee. Ich bin mir noch nicht 100% sicher, wie ich das sauber machen soll, aber es ist durchaus möglich, keine Iframes zu verwenden und dieselbe verbesserte UX zu haben, die Gutenberg bereits bereitstellt. Es wird Updates geben, um die Meta-Box-Erfahrung zu verbessern, was wahrscheinlich die Beseitigung von Iframes beinhalten wird. Die iframe-Methode hat dazu beigetragen, zu sehen, wie die Unterstützung von Meta-Boxen implementiert werden kann. Jetzt werden bessere Verbesserungen vorgenommen. Als die Dinge vor vielen Monaten zum ersten Mal mit Meta-Boxen untersucht wurden (kein neues Thema), war es aufgrund des damaligen Zustands von Gutenberg sinnvoll, den iframe-Ansatz voranzutreiben, nachdem er zusammengeführt wurde und viele andere Teile umgezogen sind Aus technischer Sicht ist die Verwendung von Iframes wahrscheinlich nicht mehr erforderlich. Es muss noch mehr Arbeit geleistet werden.

@ BE-Webdesign Vielen Dank für Ihre Bemühungen und Beiträge hier. Lassen Sie uns dies abschließen und ein neues Thema beginnen, wenn dieser Ansatz zur Diskussion steht.

Bitte stoppen Sie und bewerten Sie jetzt neu, nicht später

Nicht jeder ist an diesen Ansatz bei der Projektgestaltung gewöhnt, aber dies ist ein Projekt, das einer kontinuierlichen täglichen Neubewertung von so ziemlich allem folgt. Vergleichen Sie die Originalmodelle mit dem aktuellen Editor. Dinge ändern sich. Die meisten Stücke sind nicht in Stein gemeißelt. Die einzige Möglichkeit, wirklich zu beurteilen, ob etwas funktioniert, besteht darin, es tatsächlich zu tun. Nicht jeder geht das Produktdesign auf die gleiche Weise an, aber ich denke, die schnelle Iteration von Gutenberg hat ihm gute Dienste geleistet, anstatt zu versuchen, Unbekanntes im Voraus auszumerzen.

Vielen Dank an alle für die Diskussion. Ich bin froh, dass sich das Gespräch am Ende wieder auf das Thema konzentriert hat: Ist der aktuelle Ansatz für Meta-Boxen in einem Iframe realisierbar? Mit der Antwort nein. Die iframes sind ein Implementierungsdetail. Ich denke, wir können sie relativ einfach löschen. Konzentrieren wir uns also darauf.

Ich möchte als abschließende Gedanken hinzufügen, dass es für uns der einfachste Weg wäre, nichts am Bearbeitungsbildschirm zu ändern. Es wäre auch nicht fair gegenüber den Zielen des Projekts und den langfristigen Nutzern von WordPress. Was einige Leute als pragmatischen Ansatz bezeichnet haben, geht nicht mit der Designrichtung einher, die dieses Projekt von Anfang an hatte - hin zur vollständigen Anpassung der Website - und was unsere bisherigen Entscheidungen diktiert hat. Hier muss nichts eine endgültige Lösung sein. Wir untersuchen, was in den Entwurfsräumen möglich ist, und stellen es zum Testen zur Verfügung. Dies kann nicht von uns allein gebaut werden und wir begrüßen aufrichtig jede Hilfe, die wir von Ihnen allen bekommen können, da auf der Straße einige schwierige Probleme zu überwinden sind.

WordPress bewegt sich immer mit dem Benutzer, und wir müssen Entwicklungspfade herausfinden, um Übergänge für unseren vorhandenen Code zu vereinfachen. Als Projekt haben wir bereits gesagt, dass wir die Unterstützung für Meta-Boxen von WordPress nicht einstellen, sondern auch untersuchen müssen, welche Schnittstellenentscheidungen wir innerhalb des neuen Paradigmas treffen müssen, einschließlich der Möglichkeit, den klassischen Editor wann zu laden Wir erkennen Meta-Boxen, die wir nicht verarbeiten können oder die direkt mit einem Editor in Konflikt stehen, der klarer abgrenzen möchte, was Inhalt und was Metadaten sind. Es gibt Leute da draußen, die gerade von der Standarderfahrung von Gutenberg profitieren könnten. Als Entwickler haben wir das Privileg, Lösungen herstellen zu können, aber auch die Verantwortung, uns den Änderungen nicht zu entziehen, die wir vornehmen müssen, damit Menschen, die sonst Schwierigkeiten hätten, im offenen Web präsent sein können.

@mtias Ich

Leider steht das völlig im Widerspruch zu dem, was @youknowriad in diesem Thread

Leider haben Sie die vorgeschlagene Yoast-Skizze nicht angesprochen, die uns die Flexibilität von Gutenberg bietet und gleichzeitig mit vorhandenen Metaboxen kompatibel ist. Warum kann niemand erkennen, warum Sie diesen Ansatz nicht in Betracht ziehen?

Leider steht das völlig im Widerspruch zu dem, was @youknowriad in diesem Thread

Ich denke, Sie haben einfach falsch verstanden, was ich gesagt habe. Ich habe nur Fakten aufgezählt und teile @mtias Gedanken zu 100%

@mtias

Was einige Leute als pragmatischen Ansatz bezeichnet haben, geht nicht mit der Designrichtung einher, die dieses Projekt von Anfang an hatte - auf dem Weg zur vollständigen Anpassung der Website

Ich bin mit dieser Ansicht wirklich nicht einverstanden. Eine iterative Erweiterung, die auf den Editor selbst beschränkt ist, aber Metaboxen ersetzen kann, sowie die Freigabe und Förderung einer Feld-API wäre eine reibungslose Möglichkeit, die Masse der Plugins einfach durch Benutzerfreundlichkeit in ein Blockparadigma umzuwandeln im Vergleich zu der zerbrochenen Landschaft, die wir jetzt haben.

Wenn Sie diesen Zwischenübergang reibungslos durchführen, wird es viel einfacher, die direkte DOM-Generierung / -Manipulation auf dem Bildschirm post_edit zu verwerfen, da die Standardlösung in der Praxis bis dahin keine solche Manipulation mehr beinhalten würde. Ich glaube nicht, dass jemand sagt "direkte DOM-Manipulation muss für immer die primäre Erfahrung sein". Sie sagen "Es ist jetzt die primäre Lösung".

Wenn Sie die vollständige Flexibilität der Dom-Manipulation mit einer Vollbildlösung beibehalten können, entscheiden Sie sich dafür ... aber das scheint ein sehr hohes Ziel zu sein, und ich bezweifle, dass jede Form des Hebens vom klassischen Bearbeitungsbildschirm tatsächlich funktionieren kann auf einem angemessenen Maß an Kompatibilität. Vielleicht irre ich mich, aber es scheint ein unglaublich komplizierter Hack zu sein, Benutzer zu wechseln, wenn ein iterativerer Ansatz den gleichen Job machen könnte.

Indem Sie den Vorrang des aktuellen Paradigmas beibehalten und gleichzeitig das neue freigeben, fördern Sie die Adoption, ohne die aktuelle Erfahrung anderer zu beeinträchtigen. Sobald die meisten Workflows zu einem Blockparadigma übergegangen sind, kann die direkte Dom-Kontrolle zugunsten einer Vollbildlösung abgelehnt werden.

Es geht nicht darum, die Ziele des Projekts zu verraten, sondern lediglich den Veröffentlichungsplan anzusprechen, um die Änderung für Tausende von Agenturen und Entwicklern leichter handhabbar zu machen.

@youknowriad Lassen Sie mich ein paar Ausschnitte von dem posten, was Sie geschrieben haben, um das zu unterstützen, was ich sage:

durch Nutzung der REST-API, der clientseitigen Benutzeroberfläche und Vereinheitlichung der Kernkonzepte: Widgets, Shortcodes, Blöcke, Inhaltsmetaboxen unter einem einzigartigen Konzept „Ein Block“

Niemand hat darum gebeten, "Content-Metaboxen" in Blöcke umzuwandeln, und es wurde nicht kommuniziert, bis Gutenberg seine ursprüngliche Version ausgeliefert hat. Genau darum geht es im Kern des Arguments. Ich werde nicht wiederholen, was andere viel besser gesagt haben, nur dass Metaboxen sehr oft kein Seiteninhalt sind.

Im Gegensatz zu dem, was Sie hier und da lesen, lag der Fokus immer auf der Neugestaltung der gesamten Seite. Das erste Modell für die Gutenberg-Editor-Seite wurde im zweiten oder dritten wöchentlichen Gutenberg-Meeting gezeigt. Wir befanden uns noch in der Prototyping-Phase.

Das Gutenberg-Team sagte immer wieder, die Skizzen seien nur zur Schau und nicht das endgültige Design. Außerdem kann eine Skizze nicht anzeigen, ob der gesamte Bearbeitungsbildschirm in React konvertiert wurde oder ob er nur anders gestaltet wurde. Die Tatsache, dass die gesamte Seite neu gestaltet werden sollte, war eine große Überraschung für alle, mit denen ich gesprochen habe.

Was ist der Unterschied zwischen Shortcodes, TinyMCE-Schaltflächen und Metaboxen?
Der Hauptunterschied besteht darin, dass „Metaboxen“ keinen „Zweck“ haben. Es ist nur eine Möglichkeit, die Editorseite ohne Konsistenz zu erweitern, während Shortcodes und TinyMCE-Schaltflächen einen haben.

Dies ist ein riesiges Missverständnis, das bei Automattic die Augenbrauen hochziehen sollte. (Und ich hoffe, @mtias und @m hören zu). Es ist einfach nicht wahr und ich stelle Ihr Urteil nach dieser Aussage wirklich in Frage.

Können wir daraus schließen, dass Metaboxen auf lange Sicht die Entwicklung von WordPress blockieren (unabhängig von Gutenberg)?
Ja, sind Sie.

Ich würde sagen, dass Ihnen hier fast niemand zustimmt, und ich denke, Automattic muss darüber abstimmen, um die Produktrichtung zu bestimmen.

Ich frage auch

Ich bin buchstäblich nicht davon überzeugt, dass eine PR, mit der Gutenberg nur als Bearbeitungskomponente verwendet werden soll, vom Gutenberg-Team aufgrund der Aussagen einiger weniger Mitarbeiter von Automattic berücksichtigt wird.

@mtias ,

Ich möchte als abschließende Gedanken hinzufügen, dass es für uns der einfachste Weg wäre, nichts am Bearbeitungsbildschirm zu ändern. Es wäre auch nicht fair gegenüber den Zielen des Projekts und den langfristigen Nutzern von WordPress.

Einen Schritt zu einem Zeitpunkt gehen, nicht in irgendeiner Weise beeinträchtigt , die Ziele des Projektes. Wenn dies das Ziel ist, können Sie immer noch Anpassungen in voller Größe vornehmen. Wenn Sie dies jedoch schrittweise tun, bringen Sie den Rest der Entwickler-Community mit.

Der Customizer ist ein Paradebeispiel dafür. Ja, es hat seine Kritiker, aber das Endkonzept wird im Laufe der Zeit umgesetzt, um es bestimmten Benutzergruppen zu ermöglichen, WP effizient als Werkzeug für die Verwaltung ihrer Website zu nutzen.

Es gibt Leute da draußen, die gerade von der Standarderfahrung von Gutenberg profitieren könnten.

Absolut. Es gibt aber auch eine wesentlich größere Anzahl von Personen, die derzeit eine nachteilige Erfahrung mit dem Standard-Gutenberg machen würden.

Ich hoffe, wir können alle mit Respekt weitermachen und die Menschen in unseren Antworten vom Produkt trennen. Leidenschaft ist großartig, aber es ist wichtig, dass wir über den Menschen nachdenken, mit dem wir in solchen Themen interagieren. Jede Person, die an diesem Projekt beteiligt ist, kümmert sich darum, sie würde nicht in diese Threads kommen und interagieren, wenn sie es nicht tun würden. Lassen Sie uns jetzt einen Atemzug nehmen und uns alle daran erinnern, wie sehr uns alle WordPress am Herzen liegt und wir möchten, dass diese Community für alle sicher und produktiv bleibt.

@khromov , als Designleiter dieses Projekts, genau wie Matias der technische Leiter ist, stehe ich zu 100% hinter @youknowriad. Ich verstehe, dass Sie leidenschaftlich sind, aber Sie sind nicht respektvoll. Bitte passen Sie Ihren Ansatz an, indem Sie eine einzelne Person anrufen. Hören wir auf, persönlich zu sein.

Es ist wichtig, sich auch daran zu erinnern, dass viele derjenigen, die an Gutenberg arbeiteten, zuvor Mitglieder der WordPress-Community waren und zuvor (noch) Hauptverantwortliche waren. Ja, das schließt mich ein. Ich werde hier super persönlich sprechen, sobald Sie eine PR machen, benachrichtigen Sie mich bitte und ich werde einen Blick darauf werfen und sicherstellen, dass es den gleichen Respekt hat, den alle Bewertungen haben, egal woher sie kommen. Bitte lassen Sie uns dieses Projekt nicht mehr als "uns gegen sie" betrachten. Es ist nicht so und wir haben hier einige erstaunliche nicht-automattische Mitwirkende. Diese Aussage macht sie zu einem Dis-Service.

@khromov

Ich werde allgemein als Kritiker von Gutenberg angesehen, da meine Beiträge und Kommentare die Probleme hervorheben, die ich bei der Herangehensweise und Umsetzung sehe, aber ich bin der Meinung, dass die Ziele und Fortschritte von Gutenberg in Kommentaren manchmal aufgrund von Missverständnissen oder mangelndem Verständnis falsch interpretiert werden das übergeordnete Ziel des Projekts.

Blöcke sind keine visuelle Möglichkeit, Post-Inhalte darzustellen und zu bearbeiten. Sie müssen auch nicht Teil eines Inhaltsauswahlmenüs sein oder per Drag / Drop abgelegt werden können. Sie können natürlich für diese Dinge verwendet werden, und das ist der Workflow, den viele der sichtbaren Teile von Gutenberg hervorgehoben haben. Ignorieren Sie jedoch für einen Moment, was Sie über dieses Paradigma wissen, und betrachten Sie es stattdessen so:

Blöcke sollen eine grundlegende Kontrollstruktur für den Standort darstellen, unabhängig von Schnittstelle oder Speicher.

• Widgets sollen zu Blöcken werden. Das bedeutet NICHT, dass sie im Editor vorhanden sind und in post_content gespeichert werden. Dies bedeutet lediglich, dass sie mit einem System gesteuert werden, das in einem JavaScript-Framework mit einer einzigen gemeinsamen API erstellt wurde.
• Der Customizer soll durch Blöcke ersetzt werden. Die Schnittstelle wird wahrscheinlich (ungefähr) gleich bleiben, aber die Abschnitte des Customizers werden von derselben API gesteuert.
• Die Plugins-Seite, der Themeneditor und das Dashboard selbst sollen schließlich zu Blöcken werden. Wenn die Idee dieser Abschnitte, so wie sie ist, nicht vorstellbar ist, mit einer gemeinsamen API neu erstellt zu werden, haben Sie wahrscheinlich einige Missverständnisse, die mit der Bedeutung eines Blocks in der WordPress-Sprache zusammenhängen.

Das Problem ist nicht, dass Metaboxen innerhalb des Blockparadigmas nicht neu erstellt werden können. Tatsächlich sind Nicht-Front-End-Blöcke vorgesehen, die programmgesteuert zu einem Post-Typ hinzugefügt, an Ort und Stelle gesperrt und anstelle von post_content in Post-Meta gespeichert werden die WordPress 5.0-Version (korrigieren Sie mich, wenn ich falsch liege).

Dies deckt im Wesentlichen alle Anforderungen an triviale Metafelder wie Textfelder und Auswahlen ab. Sie könnten diese Schnittstelle genau in Blöcken duplizieren, wenn Sie möchten, oder Sie könnten möglicherweise einen Teil davon rationalisieren, basierend auf der neuen visuellen Sprache, die Blöcke liefern ... das wäre ganz und gar Ihr Anruf.

Das Problem ist nicht, dass Metaboxen niemals blockiert werden können. Das Problem ist, dass es derzeit Schnittstellen in Metaboxen gibt, die noch nicht in Blöcken (entweder von WordPress oder von Drittanbietern) unterstützt werden. Die Neuimplementierung dieser Arbeit ist eine Herkulesaufgabe für Entwickler, insbesondere da diese Tools nicht erstellt wurden von einer gemeinsamen API wie der vorgeschlagenen Fields-API, jedoch auf eine Hodge-Podge-Weise, die das DOM der Seite direkt ändert und Ressourcen auf eine nicht verwaltete Ad-hoc-Weise in die Warteschlange stellt.

Dieser aktuelle Status verursacht auch Entwicklern Probleme. Wenn Sie beispielsweise Visual Composer zusammen mit Piklist für Felder verwenden, überschreibt Piklist viele Ihrer Admin-Stile, wodurch die Navigation in VC sehr schwierig wird.

Wenn Sie WooCommerce zusammen mit einem Plugin verwenden, das die neue Version der Select2-Bibliothek in die Warteschlange stellt, wird die Admin-Oberfläche durch die eine oder andere mit einem kritischen JS-Fehler beschädigt.

Dasselbe kann passieren, wenn zwei verschiedene Plugins auf unterschiedlichen Versionen des CMB2-Frameworks basieren.

Blöcke beabsichtigen, diese Probleme zu lösen, indem ein gemeinsames Framework für die verschiedenen Seitenergänzungen eingeführt wird. Ein Teil dieses Frameworks wird sich darauf konzentrieren, dem Editor per Drag & Drop visuelles Material anzubieten, aber die Mehrheit ist nicht wirklich daran gebunden. Es wird nur sichergestellt, dass die im Administrator angezeigten Elemente auf eine gemeinsame Weise verwaltet werden.

Nun gibt es gültige Argumente dafür, dass WordPress von einer Wild-West-Entwicklerhaltung profitiert hat und dass dieses gemeinsame Framework die Eintrittsbarriere für Entwickler erhöht, die nicht wissen, wie sie reagieren sollen. Und es gibt gültige Argumente dafür, dass die Block-Schnittstelle vor der Veröffentlichung nichts erreicht, was einer weit verbreiteten Übernahme durch Entwickler nahe kommt. Es gibt sogar gültige Argumente dafür, dass die aktuelle Block-API etwas naiv ist und viele gängige Workflows nicht berücksichtigt, sodass es unmöglich ist, Plugins anzupassen, bis diese Funktionen erstellt und dokumentiert sind.

Zu argumentieren, dass die Metabox, wie sie ist, die End-All-Be-All-Lösung ist und für die Ewigkeit erhalten bleiben muss, bietet für niemanden einen großartigen Weg nach vorne. Damit WordPress allen Benutzern, einschließlich Entwicklern, bessere Optionen bieten kann, muss ein gemeinsames System vorhanden sein.

Es wäre schön gewesen, wenn dieses System vor Jahren eine gemeinsame Fields-API gewesen wäre, so dass all diese Änderungen meist nur einen Ersatz für den Rendering-Schritt für diese API darstellen würden, aber so wie es aussieht, muss ein Weg nach vorne gefunden werden.

Trotzdem bin ich nach wie vor nachdrücklich für Yoasts vorgeschlagene Zwischenlösung, da dies der beste Weg in der Praxis ist, um zu einer möglichen gemeinsamen Benutzeroberfläche zu gelangen. Ich bleibe natürlich kritisch, aber ich möchte sicherstellen, dass wir Fakten und keine Missverständnisse kritisch gegenüberstehen.

Leider steht das völlig im Widerspruch zu dem, was @youknowriad in diesem Thread

Ich würde sagen, dass Ihnen hier fast niemand zustimmt, und ich denke, Automattic muss darüber abstimmen, um die Produktrichtung zu bestimmen.

Es ist offensichtlich, dass das mit Automattic verbundene Gutenberg-Team keinen Zentimeter bewegt und jede Kritik ablenkt.

Ich bin buchstäblich nicht davon überzeugt, dass eine PR, mit der Gutenberg nur als Bearbeitungskomponente verwendet werden soll, vom Gutenberg-Team aufgrund der Aussagen einiger weniger Mitarbeiter von Automattic berücksichtigt wird.

Ich möchte nur das Offensichtliche sagen, aber Gutenberg ist ein WordPress-Community-Projekt, kein Automattic-Produkt . Ich bin vielleicht selbst ein Automattician, aber das gibt mir nicht mehr Autorität für dieses Projekt als jeder andere, sei es ein Freiberufler, ein Agentur-CEO oder ein engagierter Entwickler, der eine 5% ige Verpflichtung eines Unternehmens erfüllt, im Gegensatz zu dem, was einige Leute vorgeschlagen haben. Ebenso ist WordPress selbst ein Community-Projekt, kein Automattic-Projekt.

Automattic "veröffentlicht" oder "baut" WordPress nicht und Gutenberg ist kein Automattic-Produkt

Bevor dieses Gespräch noch emotionaler wird und die Menschen den Wald vor lauter Bäumen aus den Augen verlieren, möchte ich mir die Zeit nehmen, um die Schwierigkeit der Aufgabe zu würdigen, die dem Gutenberg-Team zugewiesen wurde, und wie gut sie damit umgehen im Allgemeinen. Sie wurden beauftragt, ein Paradigma zu erstellen, das die Grundlage für die gesamte Administratorerfahrung von WordPress bildet, und zwar innerhalb von Einschränkungen, die es ihnen nur ermöglichen, seine Wirksamkeit in einer kleinen Ecke der Benutzeroberfläche zu demonstrieren.

Das Ausmaß an Missverständnissen, das durch die Idee verursacht wird, dass "der Herausgeber übernimmt", ist immens und muss sehr schwer zu handhaben sein. Ihre Aufgabe ist es, die gemeinsamen Bausteine ​​für den Administrator von WordPress zu erstellen und sie durch Neuerstellen des Editors zu testen. Ich glaube zwar, dass diese Aufgabe für die Öffentlichkeit viel schmackhafter und flexibler wäre, wenn sie nur die wp_editor() -Schnittstelle neu erstellen und von dort aus erweitern würde, aber es ist verständlich, warum alle verbundenen Komponenten der 'Bearbeitungserfahrung' eine vollständigerer Versuch für das vorgeschlagene neue Paradigma.

Ich verstehe und schätze das Jahr der Bemühungen, die in diese Arbeit geflossen sind. Ich bin immer noch kritisch gegenüber einigen der getroffenen Entscheidungen und glaube, dass es Zeit ist, einige Änderungen vorzunehmen, die die anfängliche Übernahme erheblich verbessern werden, aber ich stimme voll und ganz dem übergeordneten Ziel zu, schließlich einen strukturierteren Rahmen für die WordPress-Administratorerfahrung bereitzustellen , sowohl für Entwickler als auch für Benutzer.

@ karmatosed

Der Grund, warum ich @youknowriad erwähnte, ist, dass er der einzige war, der an der Diskussion teilnahm. Eine Diskussion, an der Hunderte von Entwicklern und Tausende von Stunden beteiligt waren, ohne Fortschritte zu erzielen, obwohl auf Entwicklerseite ein klarer Konsens bestand. Ich denke nicht, dass es respektlos ist, die Legitimität von Entscheidungen in Frage zu stellen, die von einer kleinen Gruppe von Entwicklern getroffen werden, selbst wenn dies das Anrufen bestimmter Personen beinhaltet.

Unabhängig davon hatte ich ein privates Gespräch mit @youknowriad und er hat mir die bevorstehende Roadmap erklärt, die meiner Meinung nach sinnvoller klingt als das, was nach außen kommuniziert wird.

@ Tomjn

Ich bin respektvoll anderer Meinung. Die wichtigen Entscheidungen werden von Automatticians getroffen, und nach einem Gespräch mit @youknowriad habe ich verstanden, dass die Produktrichtung bereits für eine lange Zeit festgelegt ist, sodass wir als regelmäßige Mitwirkende nichts anderes tun müssen, als Fehler und möglicherweise kleinere visuelle

@gschoppe Ich wünschte nur, dieser "Paradigmenwechsel" würde offen diskutiert und in Zusammenarbeit mit der Entwicklergemeinde durchgeführt. Vielleicht ist das die Absicht, aber in diesem Fall funktioniert die Kommunikationsseite nicht sehr gut.

Warum kann niemand erkennen, warum Sie diesen Ansatz nicht in Betracht ziehen?

@khromov hatten wir bereits und an einigen anderen Stellen in den Editor-Chats usw. Dieses Problem betraf insbesondere die Iframe-Implementierung.

Ich bin buchstäblich nicht davon überzeugt, dass eine PR, mit der Gutenberg nur als Bearbeitungskomponente verwendet werden soll, vom Gutenberg-Team aufgrund der Aussagen einiger weniger Mitarbeiter von Automattic berücksichtigt wird.

Überhaupt nicht. Wir haben es uns schon sehr früh selbst überlegt und es als zu einschränkend und nicht angemessen angesehen, um unsere Vision voranzutreiben. Es könnte für viele immer noch ein vernünftiger Kompromiss sein und ein gutes Plugin zum Erkunden sein. Die Arbeit, die nötig ist, um dies zu erreichen, würde Gutenberg im Allgemeinen verbessern, indem es wiederverwendbarer wird, sodass ich mich nicht gegen Leute wehren würde, die daran arbeiten. Wenn jemand an einer solchen PR gearbeitet hat, würde ich wahrscheinlich vorschlagen, im Abschnitt Schreiben eine Einstellung hinzuzufügen, um das Verhalten umzuschalten, anstatt es als Standard festzulegen.

Wir haben wichtige Funktionen für verschachtelte Blöcke, globale Blöcke, das Deklarieren von Blockvorlagen, Spalten usw., die wirklich davon profitieren, dass das Inhaltsblatt die ganze Seite ist und sich ansonsten eher schlecht anfühlt, was die Möglichkeiten der Entwickler und die Benutzer einschränkt. Es gibt auch nette Tools wie die Dokumentskizze, die sich nahtlos und in Echtzeit in den Vollbild-Editor integrieren lassen und als bloßer Ersatz für TinyMCE gedacht wären.

Schritt für Schritt zu gehen, beeinträchtigt in keiner Weise die Ziele des Projekts.

Bestimmt! Wir haben einen abgestuften Ansatz vorgeschlagen, der aus Matts ursprünglichem neuen Schwerpunktbeitrag die Schritte nur anders betrachtet. Das Gutenberg-Projekt besteht im Allgemeinen aus drei Phasen: vom Post-Editor über Seitenvorlagen bis hin zur Site-Erstellung. Was ursprünglich ist, ist, dass das Paradigma eines ist, bei dem der Inhalt ein einzelner Bereich ist, mit dem Block als primärem Konzept, und bei dem das Ergebnis mit Klarheit und ohne übermäßige Abstraktionen visuell dargestellt werden kann.

Absolut. Es gibt aber auch eine wesentlich größere Anzahl von Personen, die derzeit eine nachteilige Erfahrung mit dem Standard-Gutenberg machen würden.

Natürlich, und aus diesem Grund gibt es sowohl ein Plugin, mit dem Sie nach Belieben auf die aktuelle Erfahrung zurückgreifen können, als auch Mechanismen zur Behandlung von Inkompatibilitäten, mit denen mehr Dinge aktiviert werden können (z. B. wenn Sie mit Ihren Meta-Boxen vertraut sind Wenn Sie in Gutenberg zeigen, können Sie die Unterstützung dafür erklären oder umgekehrt.

@gschoppe Ich weiß, dass wir in der Vergangenheit

Sie von Automattic sollten sich nicht beschweren, dass wir Ihre Arbeit nicht respektieren können und dass wir Sie zu sehr drängen.
Nicht für 7000 - 10.000 € pro Monatsgehalt werden Sie bezahlt. Dumm. Es ist nicht so, als würden sich Leute bei freiwilligen Entwicklern über WP Trac beschweren.
Wenn Gutenberg Ihnen Kopfschmerzen bereitet, sprechen Sie mit Ihrem Chef. Er hat dir eine unmögliche Aufgabe gegeben.

Zweitens sind Sie weitaus bessere Programmierer als die Mehrheit der Leute, die hier kommentiert haben. Warum haben Sie versucht, die "Iframes" -Lösung zu bestehen?
Ich habe dir gesagt, du behandelst Leute wie Kinder. Versuchen wir es mit Iframes und sehen wir, ob die Leute zu viel schreien, zu emotional sind. Wenn es viel Lärm gibt, entfernen wir uns von Iframes.

Warum haben Sie versucht, die "Iframes" -Lösung zu bestehen?
Ich habe dir gesagt, du behandelst Leute wie Kinder. Versuchen wir es mit Iframes und sehen wir, ob die Leute zu viel schreien, zu emotional sind. Wenn es viel Lärm gibt, entfernen wir uns von Iframes.

Als die Meta-Box-Unterstützung zum ersten Mal implementiert wurde, befand sich der neue Editor auf einer völlig neuen Administrationsseite, nicht auf post.php, der Editor wurde anders geladen, und im Allgemeinen gab es viele Einschränkungen, die Teil der Lösung des Meta-Box-Problems mithilfe von Iframes waren und einige beleuchteten Von diesen Einschränkungen, die nicht mehr existieren, und infolgedessen Meta-Boxen müssen höchstwahrscheinlich keine Iframes mehr verwendet werden.

Dieses Projekt bevorzugt eine schrittweise Verbesserung aller Releases gegenüber der Perfektion in einem einzigen Release. Niemand versucht zu sehen, ob die Leute schreien werden. Die Realität ist, dass der iframe-Ansatz für die meisten Meta-Boxen gut funktioniert hat, obwohl die Leute dies gemacht haben. Jetzt wird es weiter verbessert und es wird immer weniger 😱 🙀 geben.

@StaggerLeee, bitte respektiere alle in diesem Projekt, egal wo sie arbeiten. So wie Sie möchten, dass jemand Sie gut behandelt, tun Sie dies auch anderen.

Ich werde als Designleiter für dieses Projekt keine persönlichen Aussagen sehen, wie Sie sie gemacht haben. Es ist mir egal, wo jemand arbeitet oder welchen Hintergrund er hat, das sind persönliche Daten, über die Sie kein Recht haben, zu telefonieren. Bitte lassen Sie das Personal fallen und konzentrieren Sie sich wieder auf das Produkt.

Lassen Sie uns nun weitermachen und uns darauf konzentrieren, das bestmögliche Produkt zu entwickeln. Ich verstehe absolut, dass Ihre Punkte oft von einem Ort der Leidenschaft stammen. Sie können respektvoll und leidenschaftlich sein, bitte kehren Sie dazu zurück.

Sie von Automattic sollten sich nicht beschweren, dass wir Ihre Arbeit nicht respektieren können und dass wir Sie zu sehr drängen.
Nicht für 7000 - 10.000 € pro Monatsgehalt werden Sie bezahlt. Dumm. Es ist nicht so, als würden sich Leute bei freiwilligen Entwicklern über WP Trac beschweren.
Wenn Gutenberg Ihnen Kopfschmerzen bereitet, sprechen Sie mit Ihrem Chef. Er hat dir eine unmögliche Aufgabe gegeben.

@StaggerLeee Ich wünschte, ich hätte so viel Hinweis erhalten, aber Automattic ist nicht Google, und ich kann anderswo in der WP-Welt mehr verdienen. Meine eigene Anwesenheit hier ist rein von meinem eigenen Rücken, ich werde nicht dafür bezahlt, hier zu sein, und auch nicht viele andere Leute arbeiten daran. Ich werde tatsächlich dafür bezahlt, Codeüberprüfungen durchzuführen und Unternehmenskunden zu starten!

Vertrauen Sie also darauf, dass die Nachricht empfangen wurde. Der Beweis befindet sich oben auf der Registerkarte " Pull-Anfragen". Dies ist keine Automattic-Verschwörung, um Ihren Code zu brechen und Ihre Kunden zu stören (vergessen Sie nicht, Automattic hat zahlende Kunden, die benutze auch Metaboxen_)

Für diejenigen, die immer noch von Iframes betroffen sind, empfehle ich, hier diese Pull-Anfrage (https://github.com/WordPress/gutenberg/pull/3345) zu

Bei den nächsten Iterationen von Metabox-Implementierungen wäre es gut, Kompatibilitätsprobleme zu testen und zu identifizieren. Es könnte sich gut anfühlen, verdorbene Früchte in Richtung A8C zu werfen, aber es hilft nicht.