FWIW, als ich mit Webentwicklern gesprochen habe, verwenden alle Metaboxen für Inhalte, damit sie maximale Kontrolle haben. Ich bin nicht sicher, ob Metaboxen für viele Menschen als "Vermächtnis" gelten werden, sondern eher als Teil der Zukunft. Es könnte sich lohnen, sich an die WordPress-VIP-Leute zu wenden, um ihre Meinung zu erfahren.

Ich bin nicht sicher, ob Metaboxen für viele Menschen als "Vermächtnis" gelten werden, sondern eher als Teil der Zukunft. Es könnte sich lohnen, sich an die WordPress-VIP-Leute zu wenden, um ihre Meinung zu erfahren.

Ich entschuldige mich, dass die Formulierung schlecht war. Metaboxen sind hier, um zu bleiben. Aus diesem Grund erhält die Metabox-Seitenleiste ein Upgrade in Form der neuen Seitenleiste "Post Settings".

Was ich damit sagen wollte war, dass neue Metaboxen in JS geschrieben werden sollten und in der Seitenleiste der Post-Einstellungen neben den Standard-Metaboxen angezeigt werden. In PHP geschriebene Metaboxen sollten idealerweise auf JS aktualisiert werden, aber auch weiterhin in ihrer PHP-Form funktionieren. Dafür ist das Fenster "Erweiterte Einstellungen" gedacht, das sich unten befindet, nicht weil wir nicht möchten, dass sie Teil der Seitenleiste sind, sondern weil es sehr schwierig ist, PHP- und JS-Metaboxen in einer Seitenleiste zu mischen.

Das Senden von PHP-verwalteten Metaboxen über JS und Ajax ist mit großen Herausforderungen verbunden, insbesondere hinsichtlich der Aktualisierung des Metabox-Renderings, um den neu gespeicherten Status widerzuspiegeln: https://core.trac.wordpress.org/ticket/7756

Ich frage mich, ob das Einbetten einer alten Metabox über einen Iframe hier eine Lösung sein könnte, bei der der Iframe src so etwas wie /wp-admin/post.php?post=620&action=edit&metabox=my_plugin_settings und nur diese eine Metabox in das Dokument ausgibt.

Was ich damit sagen wollte war, dass neue Metaboxen in JS geschrieben werden sollten und in der Seitenleiste der Post-Einstellungen neben den Standard-Metaboxen angezeigt werden.

Bedeutet dies, dass JavaScript-Metaboxen nur in der Seitenleiste angezeigt werden können und nicht Teil des Abschnitts "Erweiterte Einstellungen" sein können? Ganz oben auf meinem Kopf kann ich mir viele Plugins vorstellen, bei denen die Seitenleiste nicht wirklich genug Platz bietet und die Seitenleiste möglicherweise überladen ist. Nur ein paar Plugins, die Probleme mit diesem Ansatz haben könnten:

• Yoast SEO: Bietet eine große Anzahl von Feldern, die wahrscheinlich nicht in die Seitenleiste passen. Möglicherweise gibt es eine Metabox in der Seitenleiste, die ein Modal für weitere Optionen öffnet. Dies scheint jedoch eine unnötige Einschränkung zu umgehen

• Benutzerdefinierte Feld-Plugins / Drag & Drop-Seitenersteller - diese ersetzen oder ersetzen teilweise den Hauptinhaltsbereich und benötigen daher viel Platz auf dem Bildschirm. Das Potenzial von Vollseiten-Erstellern rechtfertigt es ihnen, ihre eigene, vollständig benutzerdefinierte Benutzeroberfläche als separate Ansicht zu erstellen. In einigen Fällen sind jedoch zusätzlich zum Hauptinhaltsbereich eine Reihe von extra strukturierten Feldern erforderlich (und ich schätze, dass Guttenburg den Bedarf für diese Art von reduzieren sollte Plugin, aber es kann auch nicht jeden Anwendungsfall abdecken)

• WooCommerce - fügt Metaboxen für Bestell- und Werbebuchungsdaten hinzu, während der Haupteditor entfernt wird (Woo plant, eventuell eine eigene benutzerdefinierte Benutzeroberfläche zu erstellen, aber ich vermute, dass dies noch weit entfernt ist und andere Plugins sich in einer ähnlichen Situation befinden werden).

(Ich gehe davon aus, dass Guttenburg geplant ist, die aktuellen Ansichten post-new / post-edit.php zu ersetzen, anstatt einfach eine Alternative zu sein?)

Ha danke @braders - Yoast UX-er

Unsere Metabox ist momentan in der Tat ziemlich groß und breit, da sie viele Dinge tut. Es würde uns nichts ausmachen, diese Funktionen mehr in die verschiedenen Metaboxen in der Seitenleiste zu integrieren, um eine engere Integration zu ermöglichen, aber ich habe mich gefragt, ob dies möglich sein wird. Können wir beispielsweise wie bisher SEO-Scores zum Feld "Veröffentlichen" hinzufügen? Und wenn nicht, können wir uns trotzdem in das erweiterte Einstellungsfeld einbinden, selbst wenn unsere Metabox in JS codiert ist?

Wir sollten unbedingt versuchen, die neuen Post-Einstellungen steckbar zu machen, damit Sie der Seitenleiste Javascript-Metaboxen hinzufügen können. Vielleicht ist es Zeit, ein Ticket dafür zu öffnen. Dieses Ticket ist hauptsächlich für in PHP geschriebene Metaboxen gedacht, die vorübergehend funktionieren müssen.

Wurden in Anlehnung an Metaboxen im erweiterten Abschnitt Diskussionen oder Modelle durchgeführt, wie ein Beitragstyp dargestellt werden soll, der die Bearbeitung von Beitragsinhalten nicht unterstützt? In diesen Fällen werden die Metaboxen im mittleren Bereich für die primäre Bearbeitungserfahrung verwendet. Sollte Gutenberg einen "Nur-Titel" -Modus präsentieren? Oder sollte der Post-Titel in Abwesenheit des Herausgebers anders behandelt werden?

Wurden in Anlehnung an Metaboxen im erweiterten Abschnitt Diskussionen oder Modelle durchgeführt, wie ein Beitragstyp dargestellt werden soll, der die Bearbeitung von Beitragsinhalten nicht unterstützt? In diesen Fällen werden die Metaboxen im mittleren Bereich für die primäre Bearbeitungserfahrung verwendet. Sollte Gutenberg einen "Nur-Titel" -Modus präsentieren? Oder sollte der Post-Titel in Abwesenheit des Herausgebers anders behandelt werden?

Dies wäre gut, um ein separates Ticket für zu erstellen! Mit Screenshots des vorhandenen Beitragstyps, falls vorhanden! ✨

Ich möchte auch betonen, dass viele Plugins benutzerdefinierte Beitragstypen verwenden, die auf Meta-Boxen ohne Inhaltseditor basieren. Wenn der Beitragstyp ohne Unterstützung für editor registriert ist, sollte es einen Nur-Titel-Modus geben, der die gesamte Zeichenfläche für die Verwendung durch Meta-Boxen öffnet.

+1, um WordPress VIP zu erreichen. Dies ist auch ein Problem im Calypso-Thread: https://github.com/Automattic/wp-calypso/issues/587

Wirklich wichtiges Merkmal für die Spitze des Marktes!

Ich frage mich, ob das Einbetten einer alten Metabox über einen Iframe hier eine Lösung sein könnte, bei der der Iframe src so etwas wie /wp-admin/post.php?post=620&action=edit&metabox=my_plugin_settings und nur diese eine Metabox in das Dokument ausgibt.

Ich hatte die gleiche Idee auch. Dies ist auch aus Gründen des Sandboxing und des Sitzungsmanagements eine gute Idee. Dann können wir häufige Anwendungsfälle dieser Funktion identifizieren und eine API implementieren, um sie zu behandeln.

Ich wollte mich als Plugin-Entwickler und als jemand einarbeiten, der WordPress hauptsächlich als E-Commerce-Tool verwendet. Auch weil @kevinwhoffman es mir gesagt hat.

Ich habe Gutenberg heute müde gemacht und kann dies buchstäblich nicht als WordPress verarbeiten, ohne zu sehen, wie Metaboxen und Editor-Schaltflächen (hinzugefügt über den Hook media_buttons) ein Teil davon sind.

Ich bin auch kein großer Fan des aktuellen Status des WordPress-Editors und der Metabox-Palooza. Ich habe gerade gezählt und in der Einzelbeitragsansicht des Downloads (Produktposttyp von Easy Digital Download) habe ich 14 benutzerdefinierte Meta-Boxen von Yoast, Easy Digital Downloads und meinen eigenen benutzerdefinierten Code mit CMB2 hinzugefügt. Es ist viel, aber ich brauche die. WordPress ist ziemlich sinnlos ohne diese Schnittstelle und was es enthüllt.

Ich mache mir Sorgen, dass dies von Anfang an nicht berücksichtigt wurde, da ich an so vielen Websites gearbeitet habe, auf denen die mit ACF, Pods, CMB2 usw. hinzugefügte Benutzeroberfläche für benutzerdefinierte Felder die gesamte Bearbeitungserfahrung darstellte.

Hier sind meine technischen Bedenken:
1) Schaltflächen, die über die media_buttons hinzugefügt wurden. In meinem Plugin Caldera Forms (80K + aktive Installationen) verwenden wir diese Aktion, um eine Schaltfläche zum Einfügen von Formularen hinzuzufügen, die ein Modal zum Einfügen des Shortcodes in den Post-Editor aufruft. Vielleicht würden wir in einen benutzerdefinierten Block in Gutenberg umziehen.
2) Wie bleibt die Aktion save_post abwärtskompatibel? So viele Plugins, Themes und benutzerdefinierte Codes hängen bei save_action an und greifen auf $ _POST super global zu. Das ist kein gutes Design, aber es ist eine technische Schuld, die Millionen von Websites betrifft.
3) Es gab einen Vorschlag, ältere Metaboxen in einem iFrame zu rendern. Dies macht mir Sorgen, da der Zugriff auf den Inhalt eines iFrames über JavaScript nicht möglich ist.

@ Shelob9 hi!

Es gab einen Vorschlag, ältere Metaboxen in einem iFrame zu rendern. Dies macht mir Sorgen, da der Zugriff auf den Inhalt eines iFrames über JavaScript nicht möglich ist.

Der Zugriff auf den Inhalt eines Iframes über JavaScript ist möglich, solange er sich in derselben Domäne befindet, wie dies in diesem Fall der Fall wäre.

Wie bleibt die Aktion save_post abwärtskompatibel? So viele Plugins, Themes und benutzerdefinierte Codes hängen bei save_action an und greifen auf $ _POST super global zu. Das ist kein gutes Design, aber es ist eine technische Schuld, die Millionen von Websites betrifft.

Wir können nur so viel tun, um den Übergang älterer Metaboxen zu Gutenberg zu erleichtern. Es gibt einen grundlegenden Unterschied zwischen der Modellierung von Daten in Gutenberg und dem aktuellen Bildschirm nach der Bearbeitung. Das heißt, Daten werden jetzt zum ersten Mal tatsächlich modelliert. Mit der Datenmodellierung können wir endlich JavaScript-Schnittstellen verwenden, um den Status von Posts und Postmeta auf eine Weise zu manipulieren, die mit $_POST und der Aktion save_post unmöglich ist, geschweige denn Änderungen an Postmeta vorab anzeigen zu können. Durch das Weiterleiten von Postmeta-Änderungen durch das Modell kann Postmeta zum ersten Mal in der Vorschau angezeigt werden. Auch wenn Gutenberg nach Möglichkeit ältere Metaboxen enthalten kann, sind sie immer von Natur aus darauf beschränkt, wie viel sie von der neuen Benutzeroberfläche profitieren können. Ich denke, das ist genauso Realität wie die Tatsache, dass wir technische Schulden haben.

Ich denke, es ist die absichtliche und bewusste Entscheidung von Matt, dass die technischen Schulden gestrichen werden müssen, wenn sich WordPress so entwickeln soll, dass es auch in Zukunft relevant bleibt. Je mehr wir ACF, Pods und CMB2 aktualisieren können, um das von Gutenberg eingeführte Datenmodell zu verwenden, desto einfacher wird dieser Übergang meiner Meinung nach. Es wird zweifellos viele Herausforderungen und harte Arbeit geben!

@westonruter danke, dass der Zweck des Bereichs Erweiterte Einstellungen viel klarer wird.

Ich vermute, dass sich ein Teil der Diskussion hier auch teilweise mit verfügbaren Bildschirmimmobilien befasst.

Es sieht so aus, als ob Gutenberg JS-Metaboxen Zugriff auf die umschaltbare Seitenleiste erhalten können (was für mich in Ordnung ist), während ältere PHP-Metaboxen Zugriff auf den viel größeren Bereich am unteren Bildschirmrand erhalten (was auch für mich in Ordnung ist).

Leider gehe ich davon aus, dass dieser Wunsch nach verfügbarer Bildschirmfläche die beabsichtigte Diskussion über den effektiven Umgang mit älteren PHP-Metaboxen beeinträchtigen kann.

Ich bin damit einverstanden, dass Plugin-Hersteller ihre Metaboxen überdenken und besser in das neue Layout integrieren können, anstatt alle alten Methoden zu unterstützen. Gleichzeitig stimme ich zu, dass ähnliche Integrationsmöglichkeiten auch im neuen Editor angeboten werden sollten (und ich vertraue darauf, dass dies der Fall sein wird). Ich glaube, # 1352 ist der Hauptort, um dies derzeit zu diskutieren. In diesem Problem wird erläutert, wie wir beim Start die Abwärtskompatibilität für nicht aktualisierte PHP-Metaboxen bereitstellen.

Ich frage mich, ob das Einbetten einer Legacy-Metabox über einen Iframe hier eine Lösung sein könnte

Der Zugriff auf iframes ist für Benutzer von Bildschirmleseprogrammen keine besonders aufregende Erfahrung. Irgendwelche anderen Optionen?

Ich wollte mich nur hier einschalten, die Seitenleiste ist einfach nicht groß genug für die meisten Meta-Boxen, die wir in Plugins und Themes sehen. Uns zu zwingen, Dinge in diesen kleinen Raum zu stopfen, ist meiner Meinung nach ein Rückschlag. Ich finde diesen neuen Editor großartig, aber nicht, wenn es darum geht, die heutige Verwendung von Meta-Boxen zu opfern.

Ich stimme @kevinpmiller sehr zu. Metaboxen benötigen viel Immobilien und können nicht in einer Seitenleiste versteckt werden. Der aktuelle Status von Metaboxen ist unzusammenhängend und schlecht gestaltet, aber sie spiegeln auch wider, was WordPress ist - ein hoch erweiterbares CMS.

Als Antwort auf @westonruter vielen Dank für die Klarstellung der Abwärtskompatibilität. Ich denke, das muss SEHR klar gemacht werden, dass WordPress 5.0 oder wo immer dies landet, nicht abwärtskompatibel ist, da dies die Benutzererwartung war.

Ich bin auch besorgt darüber, wie Metaboxen behandelt werden, insbesondere bei bestimmten benutzerdefinierten Beitragstypen, bei denen der Inhaltseditor möglicherweise nicht im Mittelpunkt des CPT steht. Ich werde hier auf WooCommerce eingehen, da es sich um ein bekanntes Plugin handelt, aber es gibt viele andere Plugins und Themen, die ähnliche Probleme haben.

Zum Beispiel haben WooCommerce-Bestellungen keinen Inhaltseditor - er wird einfach nicht benötigt. Details zur Bestellung sind wichtig, nicht die Bearbeitung von Inhalten, und sollten zu Recht im Mittelpunkt dieser Seite stehen.

Können CPTs wie diese den Editor entfernen, wenn er nicht benötigt wird? Das Plugin scheint nicht vollständig in benutzerdefinierte Metaboxen in CPTs integriert zu sein, daher ist es schwer zu sagen, ob dies berücksichtigt wurde oder nicht.

WooCommerce-Produkte werfen auch ein weiteres Problem auf, bei dem es zwei Inhaltsbereiche gibt - einen für die Produktbeschreibung und einen für die Kurzbeschreibung des Produkts. Muss einer im "Haupt" -Editor-Bereich Vorrang vor dem anderen haben, während der andere in der Seitenleiste hängen bleibt? Es scheint ein weniger als optimales Bearbeitungserlebnis für das in der Seitenleiste zu sein.

Kann es eine Option geben, diese Einstellungen absichtlich im Bereich unter (oder über?) Dem Editor zu registrieren, anstatt sie alle in der Seitenleiste zu stopfen? Dies könnte den aktuellen Kontext- und Prioritätsparametern add_meta_box ähnlich sein. Vielleicht können Sie sogar zwischen mehreren Inhaltseditoren (oder anderen Metaboxen) wechseln, die in den breiteren Bereich der Seite gehören.

Vielleicht fehlt mir hier etwas (bitte korrigieren Sie mich, wenn ich falsch liege), aber es scheint, als würde ein großer Schub für einen besseren Editor gemacht, wenn in Wirklichkeit nicht alle Verwendungen von WordPress etwas anderes erfordern als das, was heute verwendet wird.

FRAGE Wie definieren wir ein CPT, um Gutenberg nicht zu verwenden (entspricht keinem Editor), und zeigen NUR die Metaboxen in voller Breite an, auf die sich unsere Unternehmen verlassen.
Ich verlasse mich auf Metaboxen. Meistens sehen meine CPTs so aus
'supports' => array( 'title' )
Und werden von dort erweitert. Bitte betrachten Sie diejenigen von uns, die Geschäftstools für Kunden entwickelt haben, die CPTs mit Metaboxen verwenden, als eingeschränkte und geführte Formulardateneingabe und nicht zum Schreiben von Artikeln.
Meine Arbeit besteht hauptsächlich aus benutzerdefinierten Erweiterungen von CMB2, die mit Client-Systemen verbunden sind. EG Immobilienanzeigen, die Systeme von Drittanbietern aufrufen.

Ich möchte nicht dramatisch klingen, aber ich werde an WP4.9 festhalten, bis dies gelöst ist und ich sehr besorgt über die Zukunft bin. Ich verstehe, dass Gutenberg "die Schulden gegenüber der Vergangenheit storniert"! Aber die Schulden fallen auf Leute wie mich.

Das Thema hier scheint zu sein, dass es nicht um Guttenburg geht, sondern um die mangelnde Abwärtskompatibilität.

Es gibt einige aktuelle Guttenburg-Probleme, für die möglicherweise separate Tickets ausgegeben werden sollten (erlauben Sie Metaboxen, Guttenburg ohne Editorunterstützung in voller Breite zu verwenden), aber Gutturnberg kann die aktuellen Bildschirme nicht vollständig replizieren und sollte es auch nicht IMHO versuchen.

Ich frage mich jedoch, ob mehr getan werden sollte, um Guttenburg zum Opt-In / Opt-Out zu bewegen. Ein paar Ideen:

• Ich würde vermuten, dass die meisten aktuellen CPTs Metaboxen über den Haupteditor stark nutzen. Vielleicht sollten sich Plugin-Autoren mit 'supports' => array( 'gutenburg' ) oder ähnlichem für Gutturnberg entscheiden

• Für Beiträge und Seiten sollte Guttenburg möglicherweise als Site-Einstellung optional sein. Es wäre sogar möglich, Benutzer zu fragen, ob sie Guttenburg nach dem 5.0-Update verwenden möchten, und diese Auswahl in der DB zu speichern.

• Alternativ könnten Themen die Unterstützung über post_type_supports () deklarieren, dies könnte jedoch die Aufnahme ernsthaft beeinträchtigen - oder Themen könnten sich abmelden, was Benutzern von nicht mehr gepflegten Legacy-Themen, die nicht mehr aktualisiert werden, nicht helfen würde. (Vielleicht würde ein Plugin zum Entfernen von Guttenburn für Benutzer älterer Themen ausreichen?)

Unabhängig von der Implementierung denke ich jedoch, dass die aktuelle Ansicht erhalten bleiben sollte, auch wenn sie der Mehrheit der Benutzer zunehmend verborgen bleibt ...

Ich mag die theoretische Idee, dass CPTs explizit 'supports' => array( 'gutenberg' ) anfordern, um vorhandene Funktionen beizubehalten, falls das Unterstützungsflag 'gutenberg' nicht definiert ist. Es würde mir viel Arbeit ersparen, alte Websites für verärgerte Kunden zu reparieren, die auf WP5 aktualisiert haben.

Ich stelle fest, dass die vorhandenen 'Unterstützungen' => Funktionen (Titel, Herausgeber, Autor, ...) sehr selbstbeschreibende Namen haben. Gutenberg fällt hier als Projektname auf. Ich frage mich, ob ein aussagekräftigerer Funktionsname für diese Verwendung in Betracht gezogen würde. vielleicht "Blockeditor"? 'supports' => array( 'block-editor' )

Natürlich müsste es eine Strategie geben, um Fehler wie 'supports' => array( 'title','editor',thumbnail', 'block-editor' ) aufzufangen. Ich würde annehmen, dass das 'Block-Editor'-Flag den älteren' Editor'-Modus einfach außer Kraft setzt.

Ein weiterer Plugin-Entwickler hier mit Bedenken.

Wenn auf Sidebar-Meta nur über JS zugegriffen werden kann, was bedeutet dies für PHP-registrierte Metaboxen mit einem Kontext von side ? Wenn Sie diese in den vorgeschlagenen Abschnitt "Erweiterte Einstellungen" verschieben, wird die Idee widerrufen, dass diese Metaboxen kontextbezogen sind.

Wie wir alle wissen, sind Seitenleisten nicht nur eine gut aussehende Designentscheidung. Sie enthalten häufig relationale Inhalte auf eine Weise, die dem Benutzer hilft, die Priorität seiner Inhalte und die Beziehung zum Hauptinhalt zu verstehen. Das Zuweisen einer side -Metabox zu einem anderen Kontext aufgrund einer technischen Barriere scheint etwas falsch.

In Anbetracht der fortschreitenden JS-Kennzeichnung des Administrationsbereichs bieten diese "Legacy" -Metaboxen auch Plugin- und Theme-Entwicklern einen natürlichen Ausgangspunkt für eigenständige React / Vue / andere Apps, um der Bearbeitungsseite zusätzliche Funktionen bereitzustellen.

Der Editor sieht gut aus, aber bitte vergessen Sie den Rest der Seite nicht.

Ich hatte die Gelegenheit, ein wenig mehr darüber nachzudenken, und mit einigen Zusammenhängen, die andere hier teilen, denke ich, dass es noch ein weiteres Problem gibt. Dieser neue Editor zwingt uns zu einem einzigen Layout und Workflow. Warum entfernen wir Anpassungen? Die Möglichkeit, Dateneingaben pro Kunde zu erstellen, macht WordPress und die meisten anderen Lösungen wirklich großartig. Je mehr ich mit diesem Editor spiele, desto mehr fühlt es sich wie eine aufgeblähte Version des Customizers an, bei der der Vorschaubereich durch einen Editor ersetzt wurde und die Seitenleiste nur die Seiten gewechselt hat.

Es wurde auch erwähnt, dass wir dies zum Schreiben von Posts verwenden könnten, CPTs jedoch erlauben könnten, dies zu unterstützen. Ich denke auch nicht, dass das wirklich funktionieren wird. Nachrichtenorganisationen würden diese Art von Editor lieben, benötigen aber auch benutzerdefinierte Workflows für zusätzliche Inhalte, Zeitplanung, Einbettungen, Infografiken und andere benötigte Daten.

Wie sieht es aus, wenn sich dieser Editor wie der Vollbild- / ablenkungsfreie Editor verhält? Auf diese Weise könnten wir das Beste aus beiden Welten haben, ohne auf Funktionalität und "Legacy" -Code zu verzichten. (Übrigens - ich finde es lächerlich, dass die Art und Weise, wie wir derzeit Meta-Boxen erstellen, in diesem Projekt als "Legacy ..." bezeichnet wird).

Vielen Dank für Ihre Zeit Jungs, es wird geschätzt.

Wie sieht es aus, wenn sich dieser Editor wie der Vollbild- / ablenkungsfreie Editor verhält?

+1

Ich werde mein Hauptanliegen wiederholen: CPTs benötigen häufig keinen "Editor", da der Beitrag aus großen und dynamisch gruppierten Metaboxen in einem geführten Benutzerworkflow erstellt wird (z. B. WooCommerce-Produktdaten).

Solche Metaboxen passen nicht in die vorgeschlagene Schublade "Erweiterte Einstellungen", da sie primäre Elemente für die Eingabe von Inhalten bilden und im Post-Editor in voller Breite und offen hervorgehoben werden müssen. Vor diesem Hintergrund scheint # 952 eine zu kleine Konzession zu sein, da wichtige Daten in eine geschlossene Schublade eingegeben werden.

Wenn von uns Entwicklern erwartet wird, dass sie alle unsere alten Metabox-Lösungen in Blöcke umwandeln, muss jemand von Automaticc dies klar und öffentlich angeben, bevor der Hammer in 5.0 fällt. Ich sehe keine Anzeichen dafür, dass das Team diesen Teil des Marktes und die Auswirkungen auf das Geschäft berücksichtigt hat.

Hier wurden bereits viele gute Gedanken hinzugefügt, daher werde ich nur diese einfachen Gedanken einbringen:

Anstatt unten einen Expander "Erweiterte Einstellungen" für alle älteren Dinge zu haben, können Sie einfach einen Expander für jede Metabox erstellen, die genau so unten liegt, wenn sich die Metabox im normalen und erweiterten Kontext befindet, und dann verwenden die Seiteneinstellungen für den Seitenkontext?

Es scheint nicht so weit von einer Lösung entfernt zu sein. Und wenn der Beitragstyp den Editor nicht unterstützt, blenden Sie den Editor einfach aus, aber alles andere wird auf die gleiche Weise angezeigt. Es ist ein vernünftiges Layout. Geben Sie einfach Optionen wie das Festlegen der erweiterten Standard-Metabox an.

Die Idee, die derzeitige Methode zum Rendern von Metaboxen in Betracht zu ziehen und eine neue, js-gesteuerte und bevorzugte Methode zum Ausbauen der Felder bereitzustellen, macht mir sicherlich nichts aus. Wir können dann schrittweise umschalten, ohne in Panik geraten zu müssen, wenn in 5.0 sofort etwas kaputt geht.

Hoffe, diese Gedanken helfen. Wenn jemand anderes bereits etwas dazu gesagt hat, nehmen Sie dies einfach als Vereinbarung. 😄

Ich möchte der Diskussion zwei weitere wertvolle Hooks hinzufügen: edit_form_after_title und edit_form_after_editor die derzeit die vollständige Kontrolle über die Benutzeroberfläche nach der Bearbeitung bieten. Offensichtlich ist Gutenberg nicht nur ein Ersatz für "wp_editor", sondern eine völlig andere Sichtweise auf die Benutzeroberfläche (und wie sie derzeit aussieht, ihre zukünftige modulare Erweiterbarkeit).

Ich sehe, dass Probleme wie dieses versuchen, das Problem zu lösen, aber ich denke, es geht nicht um "was passiert mit unseren Metaboxen", sondern eher um die Frage, wohin WordPress als "Produkt" geht.

Es ist leicht, das mittelfristige Ziel einer solchen Lösung zu erkennen: Es wird ziemlich einfach sein, dies in das Frontend zu verschieben (und vielleicht einigen Konkurrenten näher zu kommen).

Aus Sicht von Entwicklern / Unternehmen / Planern wäre es hilfreich, die (zukünftige) Absicht von 'Gutenberg' zu verstehen, oder kann mich jemand auf ein solches Leitbild oder ähnliches hinweisen?

Noch ein paar Meinungen von mir ...

Ich stelle fest, dass die vorhandenen 'Unterstützungen' => Funktionen (Titel, Herausgeber, Autor, ...) sehr selbstbeschreibende Namen haben. Gutenberg ist hier ein Projektname. Ich frage mich, ob ein aussagekräftigerer Funktionsname für diese Verwendung in Betracht gezogen würde. vielleicht "Blockeditor"? 'unterstützt' => Array ('Blockeditor')

Ich stimme zu - das klingt nach einem Detail, das sortiert werden kann, sobald der Ansatz vereinbart ist 😄

Natürlich müsste es eine Strategie geben, um Fehler wie 'support' => array ('title', 'editor', thumbnail ',' block-editor ') abzufangen. Ich würde annehmen, dass das 'Block-Editor'-Flag den älteren' Editor'-Modus einfach außer Kraft setzt.

Ich würde Gutenberg als Erweiterung der aktuellen Unterstützung für Post-Typen ansehen. Wenn es also keine Unterstützung für editor gäbe, würde Gutenburg nur Titel- / Seitenleisten- / erweiterte Optionen anzeigen. Vielleicht würde die Gutenburg-Unterstützung besser als separates Argument für die CPT-Registrierung behandelt, als Teil des Unterstützungsarrays zu sein?

Anstatt unten einen Expander "Erweiterte Einstellungen" für alle älteren Dinge zu haben, können Sie einfach einen Expander für jede Metabox erstellen, die genau so unten liegt, wenn sich die Metabox im normalen und erweiterten Kontext befindet, und dann verwenden die Seiteneinstellungen für den Seitenkontext?

Ich persönlich mag diese Idee - Wenn diese Panels neu angeordnet und versteckt werden könnten, wie es derzeit möglich ist, könnte dies eine Ideenlösung sein ...

Möglicherweise sollte es auch eine Möglichkeit geben, eine (oder mehrere?) Oder diese beim Laden der Seite als geöffnet festzulegen - insbesondere, wenn der Beitragstyp den Haupteditor nicht unterstützt.

Es wurde auch erwähnt, dass wir dies zum Schreiben von Posts verwenden könnten, CPTs jedoch erlauben könnten, dies zu unterstützen. Ich denke auch nicht, dass das wirklich funktionieren wird. Nachrichtenorganisationen würden diese Art von Editor lieben, benötigen aber auch benutzerdefinierte Workflows für zusätzliche Inhalte, Zeitplanung, Einbettungen, Infografiken und andere benötigte Daten.

Wenn der neue reaktionsbasierte Bildschirm genauso steckbar ist wie die alten Bearbeitungsbildschirme, gibt es keinen Grund, warum diese benutzerdefinierten Workflows nicht oben auf der Seite / Seitenleiste / unter dem Editor oder an anderer Stelle auf der Seite hinzugefügt werden können. (Haftungsausschluss: Ich habe kein tiefes Verständnis für React, daher bleibt abzuwarten, wie viel komplexere Hooks außerhalb von PHP liegen werden.) Auch # 1352

Ich denke, die Verwirrung hier ist darauf zurückzuführen, dass es einen grundlegenden Unterschied gibt, wie Gutenberg sich vorstellt, dass der Editor zuerst blockiert wird . Mit anderen Worten, wir sollten nicht mehr über das Hinzufügen von Metaboxen nachdenken, sondern über das Hinzufügen von Blöcken. Felder, die Sie früher in Metaboxen eingefügt haben, werden jetzt vorwärts bewegt und stattdessen in Blöcke eingefügt.

Wenn Sie einen benutzerdefinierten Beitragstyp definieren, umfasst dies wahrscheinlich die erforderlichen und nur zulässigen Blöcke. Für einen benutzerdefinierten Beitragstyp, der keine Unterstützung für editor bietet, wird der "Editor" weiterhin in Gutenberg angezeigt, der _inserter_ kann jedoch im Wesentlichen deaktiviert werden. Die Blöcke, die im Editor angezeigt werden, werden entsprechend den Anforderungen des Beitragstyps gesperrt. Wenn die Blöcke nicht ausgefüllt worden wären, würden sie als Platzhalter angezeigt. Beachten Sie, dass diese Blöcke ihre Eigenschaften dann wie derzeit in Metaboxen in Postmeta speichern können, dies jedoch auf normalisierte Weise anstelle von Ad-hoc über die Aktion save_post und $_POST global.

Ich denke also, dass das Endergebnis hier weitgehend das gleiche sein wird. Plugin-Autoren erhalten weiterhin eine "Box", in die benutzerdefinierte Felder eingefügt werden können. Es ist nur so, dass sie in Blöcken anstelle von Metaboxen angezeigt werden.

Ich denke, die Verwirrung hier ist darauf zurückzuführen, dass es einen grundlegenden Unterschied gibt, wie Gutenberg sich vorstellt, dass der Editor zuerst blockiert wird. Mit anderen Worten, wir sollten nicht mehr über das Hinzufügen von Metaboxen nachdenken, sondern über das Hinzufügen von Blöcken. Felder, die Sie früher in Metaboxen eingefügt haben, werden jetzt vorwärts bewegt und stattdessen in Blöcke eingefügt.

@westonruter Dies scheint für inhaltshaltige

Vielen Dank an @westonruter für die Klarstellung, aber dies wirft ein paar neue Fragen für mich auf.

Blöcke, die ihre Daten als post_meta speichern, scheinen ein grundlegend anderer Blocktyp zu sein als das, was ich bisher in der Demo gesehen habe. Würden diese Daten auch redundant im Fluss des Post-Inhalts gespeichert?

Gibt es irgendetwas, das einen Autor davon abhält, einem Beitrag mehr als eine akzeptable Anzahl von Blöcken hinzuzufügen? (Hinzufügen mehrerer post_meta-Felder, wenn nur eines sinnvoll ist)

Ich würde @westonruter eher zustimmen, post_content am Frontend hervorgeht. Hier ist ein Beispiel mit dem Plugin "Der Veranstaltungskalender" (meine Interpretation) des modernen Stammes.

In dieser Situation sind die Ereignisdetails der primäre Inhalt, nicht der Freiform-Inhaltsbereich. Das Plugin verwendet die Metadaten seines benutzerdefinierten Beitragstyps, um ein eigenes Markup zusammenzustellen, und das post_content ist lediglich der beschreibende Text, der am Ende der Seite gedruckt wird. Aus diesem Grund sollte der Ereignisdetailblock nicht verschiebbar, löschbar oder überhaupt Teil der Inhaltsausgabe sein. Es sollte jedoch zuerst angezeigt werden, da es den primären Inhalt für diesen Beitragstyp darstellt.

WooCommerce wäre ein weiteres Beispiel, bei dem ein oder mehrere Produktinformationsblöcke Vorrang vor dem beschreibenden Text eines Produktposttyps haben sollten, aber keine optionalen Blöcke sein sollten, die der Benutzer selbst einfügen soll.

Ich denke, das grundlegende Konzept für Blöcke sollte darin bestehen, die richtige Benutzeroberfläche für den Beitrag zusammenzustellen und nicht unbedingt zu implizieren, wo diese Daten im Frontend gespeichert oder gerendert werden.

... sollten wir nicht mehr über das Hinzufügen von Metaboxen nachdenken, sondern über das Hinzufügen von Blöcken.

Das ist für Inhalte sinnvoll, aber viele Plugins verwenden benutzerdefinierte Beitragstypen für Nichtinhalte wie Formulare oder Zahlungen. Diese Beitragstypen ähneln in keiner Weise einem Blog-Beitrag, und ihre abstrakten Metafelder würden auch nicht von einem Blockeditor profitieren. Wenn alle Konfigurationen von Blöcken erzwungen werden, wird die offene Zeichenfläche entfernt, auf die sich Plugin-Entwickler verlassen. Dieselbe offene Zeichenfläche, die das Plugin-Ökosystem zu dem gemacht hat, was es heute ist.

Der derzeitige Ansatz scheint Block-First zu sein, wobei Meta-Boxen auf eine unterstützende Rolle beschränkt sind. Während Blöcke vielen inhaltsorientierten Plugins zugute kommen, wird die Notwendigkeit, abstrakte Einstellungen zu definieren, dennoch von den offensichtlichen Beschriftungen und vertrauten Eingaben profitieren, die Meta-Boxen bieten. In diesen Fällen sollten Entwickler die Freiheit haben, die gesamte Zeichenfläche zu verwenden.

@westonruter Können Sie bitte klarstellen, was Sie sagen, wenn mein benutzerdefinierter Beitragstyp bestimmte zusätzliche Felder erfordert, würde ich diese Daten in einen Block

Wenn ja, habe ich einige Anschlussfragen:

1) Kann ich diesen Block als Standard festlegen? IE es wurde immer auf diesem Beitragstyp angezeigt und konnte nicht entfernt werden. Wenn mein Plugin beispielsweise Ereignisse erstellt hat und jedes Ereignis ein Start- und Enddatum hat, ist der Block für das Start- und Enddatum und im Beitragsinhalt erforderlich, wenn der benutzerdefinierte Beitragstyp des Ereignisses standardmäßig bearbeitet wird?

2) Wie würden Daten aus diesem Block gespeichert? Soweit ich weiß, werden die Daten aus Blöcken derzeit als HTML-Kommentare in post_content gespeichert. Wie würden wir die Daten aus diesen Blöcken dazu bringen, Meta zu posten? Wie würde ich beispielsweise für mein hypothetisches Ereignis-Plugin das Start- und Enddatum in das Post-Meta aufnehmen, damit ich nach ihnen fragen kann?

3) Was ist der Grund dafür, dass alles in Richtung des Hauptinhaltseditors geht und für benutzerdefinierte Beitragstypen gilt? Gibt es Benutzertests, die diese Designrichtung stützen, insbesondere in Bezug auf benutzerdefinierte Beitragstypen, die keinen Blog-Beitrag / Artikel darstellen?

@ kekewhoffman Ich post_content speichern. Blöcke, die bearbeitet werden, können so gestaltet werden, dass sie Überschriften / Beschriftungen haben, die der heutigen Darstellung von Metaboxen ähneln.

@ Shelob9 Ja, wenn Ihr benutzerdefinierter Beitragstyp zusätzliche Felder erfordert, werden diese meiner Meinung nach in einem Block dargestellt. Wenn Sie einen benutzerdefinierten Beitragstyp "Produkt" haben, kann es einen einzelnen product-details -Block geben, der Felder für den Preis, Variationen usw. enthält.

1. Kann ich diesen Block als Standard festlegen? IE es wurde immer auf diesem Beitragstyp angezeigt und konnte nicht entfernt werden. Wenn mein Plugin beispielsweise Ereignisse erstellt hat und jedes Ereignis ein Start- und Enddatum hat, ist der Block für das Start- und Enddatum und im Beitragsinhalt erforderlich, wenn der benutzerdefinierte Beitragstyp des Ereignisses standardmäßig bearbeitet wird?

Ja genau. Benutzerdefinierte Beitragstypen, Beitragsformate und Seitenvorlagen können einfach das Konzept erforderlicher Blöcke beinhalten, die „gesperrt“ sind und nicht entfernt oder neu angeordnet werden können. Ein Beispiel hierfür wäre ein Block für den Post-Auszug: https://github.com/WordPress/gutenberg/issues/1288#issuecomment -310544967

1. Wie würden Daten aus diesem Block gespeichert? Soweit ich weiß, werden die Daten aus Blöcken derzeit als HTML-Kommentare in post_content gespeichert. Wie würden wir die Daten aus diesen Blöcken dazu bringen, Meta zu posten? Wie würde ich beispielsweise für mein hypothetisches Ereignis-Plugin das Start- und Enddatum in das Post-Meta aufnehmen, damit ich nach ihnen fragen kann?

Die meisten Blöcke speichern ihre Daten heute in HTML innerhalb von post_content , müssen dies aber nicht. In https://github.com/WordPress/gutenberg/issues/1288 sehen Sie beispielsweise die Diskussion eines Auszugsblocks, in dem sein Inhalt in post_excerpt gespeichert ist, und eines Blocks "Empfohlenes Bild", in dem sein Inhalt in Postmeta gespeichert ist. Sie sollten also auf jeden Fall in der Lage sein, einen event-details -Block zu haben, dessen Start- und Enddatum in postmeta gespeichert wird.

1. Was ist der Grund dafür, dass alles in Richtung des Hauptinhaltseditors geht und für benutzerdefinierte Beitragstypen gilt? Gibt es Benutzertests, die diese Designrichtung stützen, insbesondere in Bezug auf benutzerdefinierte Beitragstypen, die keinen Blog-Beitrag / Artikel darstellen?

Wie oben beschrieben, können die Daten von post_content , Postmeta, Begriffen oder einem anderen Ort bezogen und dort gespeichert werden. Die Idee, "Block zuerst" zu sein, besteht darin, einen gemeinsamen Gebäudeblock zu haben, den alles verwendet, und dabei können die Blockkomponenten in WordPress maximal wiederverwendet werden. Das ist mein Verständnis.

@westonruter - Danke für die Klarstellung. Dies ist sehr nützlich, da es nicht viele Informationen darüber gibt, wie sich dieser Editor auf Beitragstypen bezieht, die keine Blog-Beiträge / Artikel usw. sind.

Ich hoffe, wir werden bald eine Dokumentation darüber sehen, wie man einen "Metablock" schreibt.

Wir sollten uns überlegen, was wir dem Benutzer durch die Post-Bearbeitungserfahrung beibringen und wie dies benutzerdefinierten Post-Typen zugeordnet wird.

Beim Bearbeiten eines Standardposts im Blockeditor erfährt der Benutzer, dass jeder Block Inhalt darstellt. Mit dem Inhalt verknüpfte Einstellungen sind in einem Panel / Meta-Feld verfügbar, das sich außerhalb des Blockeditors befindet. Inhalt lebt in Blöcken. Einstellungen leben in Panels. Es wurde an anderer Stelle gesagt, dass das, was der Benutzer im Blockeditor sieht, eine Vorschau der Seite sein sollte, wenn sie veröffentlicht wird.

Wenn Sie dann Einstellungen und Inhalte im Blockeditor für benutzerdefinierte Beitragstypen kombinieren, wird die Idee gebrochen, dass der Blockeditor eine Vorschau ist. Ich denke, wir sollten den Blockeditor das tun lassen, was er am besten kann, nämlich Inhalte zu bearbeiten, und Entwicklern die Möglichkeit geben, Einstellungsschnittstellen zu erstellen, die nicht dieselben Anforderungen wie ein Inhaltsblock haben.

Ich habe an einem umfangreichen Plugin gearbeitet, das Meta-Boxen wie WooCommerce und EDD hinzufügt. In den meisten Fällen habe ich den Inhaltseditor vom Bildschirm entfernt, da er nicht benötigt wird. Ich bin ein bisschen besorgt, dass es nicht etwas sein sollte, das wir mit Gutenberg verschmelzen sollten.
Ansonsten, wohin würde das alles gehen.

Ich stimme @kevinwhoffman zu, dass Blöcke, die Meta darstellen sollen, einen visuellen Hinweis für den Benutzer benötigen, dass diese sich irgendwie vom Post-Inhalt unterscheiden und in der Ausgabe nicht zu erwarten sind. Eine Möglichkeit, dies zu beheben, ist ein Teiler. Dies ist im Wesentlichen nur eine Neuinterpretation der Art und Weise, wie Inhalte jetzt von Metaboxen getrennt werden.

Dies löst nicht jedes Problem für mich, aber ich denke, es ist eine interessante Möglichkeit, Metaboxen ein neues Gesicht zu geben, und es könnte wahrscheinlich ziemlich abwärtskompatibel mit vorhandenen Plugins sein, aber das wäre keine erstklassige Erfahrung für den Benutzer.

Hier ist ein Versuch, den Benutzer zu informieren, wenn ein Meta-Block der primäre Inhalt ist, der Post-Inhalt als Beschreibung verwendet wird und es zusätzliche Meta-Blöcke gibt.

@brentjett Danke für die Modelle. Wie Sie betonen, ist es wichtig, Einstellungen von Inhalten zu trennen, aber ich sehe keinen Vorteil darin, dass ein Einstellungsfeld wie Yoast überhaupt ein Block sein muss.

• Es stellt keinen Inhalt auf der Seite dar und bricht damit die Idee, dass der Blockeditor eine Vorschau des Inhalts auf der Seite ist.
• Es sind nicht mehrere Instanzen erforderlich.
• Es profitiert nicht davon, in der Mitte anderer Inhaltsblöcke neu positioniert zu werden.
• Es sollte standardmäßig auf der Seite vorhanden sein.

Jedes dieser Merkmale widerspricht dem Standardverhalten eines Blocks. Sicher gibt es verschiedene Diskussionen, um einmalige Verwendungsblöcke zu erstellen, die in ihrer Position verriegelt und standardmäßig vorhanden sein können. Aber warum einen Block in eine Meta-Box verwandeln, wenn wir uns stattdessen darauf konzentrieren könnten, die Meta-Box-Implementierung zu verbessern, die bereits diesem Zweck dient?

Ich sehe keinen Vorteil darin, dass ein Einstellungsfeld wie Yoast überhaupt ein Block sein muss.

Lassen Sie uns hier eine Minute zurücktreten. Zwei Dinge. Eine davon ist die Unterstützung für alte in PHP geschriebene Metaboxen, für die wir die Schublade "Erweiterte Einstellungen" in diesem Beitrag nachgebildet haben.

Die andere Sache ist die Beantwortung der Frage: Wenn wir dies von Grund auf neu gestalten wollten, wie würde es heute aussehen?

Hier schlagen wir _blocks_ als neue Schnittstelle vor, die viele unterschiedliche vereinen kann. Wir schlagen bereits vor, dass Blöcke Shortcodes, benutzerdefiniertem HTML, Widgets und einem Vorteil für Einbettungen überlegen sein können. Abhängig davon, was die Metabox tut, gibt es keinen Grund, warum sie diese Schnittstelle auch nicht subsumieren kann.

Einverstanden. Und wenn wir für eine Sekunde für Yoast sprechen, planen wir, uns an vielen Stellen rund um den neuen Editor zu integrieren, um die Erfahrung zu verbessern, die gutenberg anstrebt, anstatt einen großen Block zu bauen, um unsere alte Metabox zu emulieren. Es wurden jedoch auch andere Beispiele erwähnt Arbeite auch als Block, denke ich. Ja, es erfordert einige Arbeit, aber wenn sich herausstellt, dass dieser Editor WordPress-Benutzer begeistert, sobald er etwas mehr Traktion erreicht, ist dies eine aufregende Gelegenheit, die Integration zu überdenken, und ich denke, dass unsere Produkte dadurch besser werden.

Wir haben also zwei Legacy-Funktionsfälle:
MetaBoxen, die Metadaten verarbeiten (wie Yoast), und MetaBoxen, die verwendet wurden, um eine strukturierte Schnittstelle für die Eingabe von Inhalten bereitzustellen (wie WooCommerce).

Entwicklung für die Zukunft
Wenn wir von einer leeren Tafel ausgehen ("Stornierung unserer Schulden gegenüber der Vergangenheit"), dann kann es durchaus funktionieren, dass Metadaten in die vorgeschlagene "erweiterte" Schublade gestellt werden. Außerdem könnte der strukturierte Inhaltseintrag in eine gesperrte Blockordnungsschnittstelle in Gutenberg passen. Beide sind völlig hypothetisch, könnten aber möglicherweise als Implementierungen für zukünftige WP CMS-Entwicklungen dienen.

ältere Business-CMS-Probleme
99% meiner Arbeit besteht darin, maßgeschneiderte Geschäftslösungen direkt für meine Kundenunternehmen bereitzustellen. Mein Anliegen sind also nicht die großartigen Dinge, die ich in Zukunft aufbauen könnte, sondern die kalten, harten Fakten über die Funktionalität meiner Kundensite und die Geschäftsbeziehungen. Welche Vorschläge gibt es, um bestehende CMS-lösungsbasierte Unternehmen nach Gutenberg zu migrieren? In meiner Situation verfügt jeder Client über eine andere maßgeschneiderte CMS-Lösung, die auf dem etablierten WP-Framework basiert. Für mich der Satz "Schuldenerlass gegenüber der Vergangenheit" = "Das Baby mit dem Badewasser rauswerfen".

Sorgen
Wenn Gutenberg in WP5.0 als Core ausgeliefert wird, gehe ich davon aus, dass meine Kunden nicht funktionierende Sites haben werden. Dann muss jede Site neu erstellt und jeder Client besänftigt werden. Rund 40 Kunden möchten möglicherweise, dass ich in dieser Woche ihr CMS repariere.

• Ältere CMS-Meta-Box-abhängige Websites und ihre Benutzerbasis scheinen für das Kernteam nicht wesentlich zu sein
• Der "fortgeschrittene" Ziehungsvorschlag Nr. 952 wurde priorisiert, was auf mangelndes Interesse in der gesamten Region hinweist.
• Es gibt keine vorgeschlagene Methode zur Lösung des CMS-Problems "Schulden gegenüber der Vergangenheit"

Hier schlagen wir Blöcke als neue Schnittstelle vor, die viele unterschiedliche Blöcke vereinen kann. Wir schlagen bereits vor, dass Blöcke Shortcodes, benutzerdefiniertem HTML, Widgets und einem Vorteil für Einbettungen überlegen sein können.

Blöcke sind für all diese Dinge sinnvoll - Shortcodes, benutzerdefiniertes HTML, Widgets, Einbettungen. Dies sind alle Arten von Inhalten, die auf der Seite angezeigt werden. Ich stimme zu, blockiere sie alle.

Einstellungen sind keines dieser Dinge. Einstellungen haben unterschiedliche Anforderungen , die sich nicht mit dem grundlegenden Verhalten eines Blocks überschneiden. In vielen Fällen speichern diese Einstellungsfelder Post-Meta, das keinen Einfluss auf die Front-End-Präsentation eines Posts hat. Es erscheint unnötig, jedes Mal, wenn ein Beitrag angezeigt wird, Nicht-Inhalte neben Inhalten zu analysieren.

Eine andere zu berücksichtigende Sache ist, was passiert, wenn der Benutzer in den Textmodus wechselt. Werden sie eine Reihe von HTML-Kommentaren sehen, die neben ihrem Beitragsinhalt Einstellungsfelder darstellen? Wird der Benutzer diese ungewohnten Dinge löschen?

All dies könnte vereinfacht werden, indem Blöcke als Inhalt und Einstellungen als separate UI-Komponente behandelt werden. Selbst wenn wir keine älteren Meta-Boxen berücksichtigen müssten (was ein großes Problem ist, auf das

Der Abschnitt

Dies ist eine großartige Diskussion darüber, was in Zukunft möglich sein wird und dass alles großartig klingt, WordPress, wie es das wirklich braucht. Für mich als Plugin-Entwickler, keine große Sache, werde ich ein oder zwei Blöcke machen und gut sein. Aber was passiert mit Steves Kunden und den Millionen von Websites, die an Kunden mit der Erwartung der Abwärtskompatibilität verkauft wurden?

Ich verstehe diese Bedenken, da ich auch viele Kunden habe, deren Websites wahrscheinlich mit dem Update brechen werden. Einige Gedanken von mir:

Wir verwenden ACF ausgiebig für das Content Management. Zum Beispiel könnten wir mehrere Tinymce-Editoren pro Post oder in einem Repeater haben. Wenn das Ziel darin besteht, Tinymce zu ersetzen, wie würden wir dann mehrere "Blockcontainer" verwenden? Ich verstehe jetzt richtig, dass es nur einen "Blockcontainer" gibt, oder?

Eine weitere ACF-Funktion, die nicht zum Nachbearbeitungsablauf passt, sind Optionsseiten. Ich sehe wirklich nicht, wie das auf einer Optionsseite funktionieren würde.

Für diejenigen, die Abwärtskompatibilität wünschen - wahrscheinlich wird jemand ein Plugin erstellen, um die aktuelle Bearbeitungserfahrung wiederherzustellen, wenn keine Zeit / Ressourcen für ein Update auf gutenberg vorhanden sind (dies ist etwas, das ich verwenden möchte). Außerdem wäre 5.0 eine große Version, was bedeutet, dass Änderungen in Ordnung sind (zumindest gemäß den Semver- Standards).

WordPress folgt nicht semver.

@westonruter Ich denke das macht Sinn:

Felder, die Sie früher in Metaboxen eingefügt haben, werden jetzt vorwärts bewegt und stattdessen in Blöcke eingefügt.

Aber wie kommen wir von dort (Metaboxen) hierher (Blöcke)? Sowohl in Bezug auf den Backcompat für Code (Plugins, die für Gutenberg noch nicht aktualisiert wurden) als auch in Bezug auf den Backcompat für Daten (wie werden vorhandene Metaboxdaten in einem neuen Inhaltsblock angezeigt, sobald ein Plugin dafür aktualisiert wurde; ist das ein Plugin? Umfangsproblem?).

Aber wie kommen wir von dort (Metaboxen) hierher (Blöcke)? Sowohl in Bezug auf den Backcompat für Code (Plugins, die für Gutenberg noch nicht aktualisiert wurden) als auch in Bezug auf den Backcompat für Daten (wie werden vorhandene Metaboxdaten in einem neuen Inhaltsblock angezeigt, sobald ein Plugin dafür aktualisiert wurde; ist das ein Plugin? Umfangsproblem?).

Das sind gute Fragen. Wir werden die Antworten untersuchen, während wir diese Funktionen implementieren.

Wenn ich raten müsste, wo wir hier landen werden: Aktuelle Metaboxen werden in einen "Legacy" -Bereich verschoben und wir werden APIs, Dokumentationen und Beispiele für die Registrierung von "New-Style" -Metabox-Block-Dingen bereitstellen.

@nylen was ist mit dem Rendern der aktuellen Metaboxen?

Es ist eine gute Nachricht, dass Meta-Boxen priorisiert werden, aber wir müssen eine Lösung in Betracht ziehen, die über das Platzieren alter Meta-Boxen in einer Schublade oder das Beschränken auf einen "Legacy" -Bereich hinausgeht.

Es gibt heute unzählige Websites, die hauptsächlich mit Meta-Boxen über Plugins wie Advanced Custom Fields erstellt werden. Wir sprechen hier von Vollbildschnittstellen, nicht nur von ein oder zwei Feldern am Ende eines Beitrags. Ich bin sicher, dass ACF aktualisiert wird, um mit Gutenberg zu funktionieren, aber diese Websites werden nicht neu erstellt.

Es bleibt also die Frage, was mit einer Schnittstelle passiert, die keinen Editor hat und vollständig aus Meta-Boxen besteht.

Es bleibt also die Frage, was mit einer Schnittstelle passiert, die keinen Editor hat und vollständig aus Meta-Boxen besteht.

Die Idee hier und korrigieren Sie mich, wenn ich mich bei @mtias irre , ist, dass Sie den Inhaltsbereich einfach mit Ihrem Plugin ausblenden und alles, was Sie sehen, Metaboxen sind, in denen sich der Inhalt befinden würde.

Wie sieht es aus, wenn sich dieser Editor wie der Vollbild- / ablenkungsfreie Editor verhält?

+1. Dies ist eine gute Idee, da sie den aktuellen Editor mit Meta-Boxen überhaupt nicht beeinflusst. Während der ablenkungsfreie Editor lange Zeit da war, wird er nicht viel benutzt. Der Gutenberg-Editor kann dies übernehmen und verbessern, anstatt den Editorbildschirm neu zu schreiben.

Es wäre auch besser, wenn wir die Unterstützung für den Gutenberg-Editor mit dem Parameter supports registrieren würden, wenn register_post_type .

Schließlich würde ich als Meta-Box-Entwickler gerne eine neue API sehen, damit Meta-Boxen für den neuen Editor funktionieren. Wie Sie hier sehen, verwenden viele Entwickler Meta-Boxen, um zusätzlichen Inhalt für die Beiträge bereitzustellen. Diese Inhalte können kategorisiert und später durchsucht werden. Es sind nicht nur einfache Inhaltsblöcke als Post-Inhalte. Wenn es also einen neuen Ersatz für die add_meta_box() -Funktion gibt, überarbeite ich gerne mein Meta Box-Plugin, um damit zu arbeiten.

Einverstanden mit allem, was gesagt wurde: Standard-Metaboxen funktionieren immer noch / haben einen Platz. Als führender Entwickler von CMB2 kann ich garantieren, dass es einen ziemlich großen Aufschrei geben wird, wenn CMB2 bei der Veröffentlichung von WordPress 5.0 irgendwie kaputt ist. Ich meine das sicherlich nicht als Bedrohung, sondern einfach als Realität.

Je mehr wir ACF, Pods und CMB2 aktualisieren können, um das von Gutenberg eingeführte Datenmodell zu verwenden, desto einfacher wird dieser Übergang meiner Meinung nach.

Ich werde auf jeden Fall versuchen, dies langfristig zu tun, aber ich bin mir nicht sicher, ob es eine faire Erwartung ist, dass Metabox-Bibliotheken dies zum Zeitpunkt der Veröffentlichung von Gutenberg haben werden. (Zugegeben, das ist möglicherweise nicht die Erwartung)

I can guarantee there will be a pretty significant outcry if CMB2 is somehow broken when WordPress 5.0 is released

Und selbst wenn es aktualisiert wird, würden alte Installationen kaputt gehen.

Bitte beachten Sie auch, dass Feldgruppen in ACF nicht in Metaboxen enthalten sein müssen. Es gibt jedoch auch den Stil "Nahtlos (keine Metabox)" mit den Optionen "Seite", "Normal - Nach Inhalt" und "Hoch" zwischen Titel und Editor (!!!) '. Letzteres ist wichtig, um einen aussagekräftigen Bearbeitungsfluss zu schaffen.

Bitte denken Sie daran, dass es viele kritische individuelle Entwicklungen gibt, die niemals aktualisiert werden, da niemand dafür bezahlen wird. Das Unterbrechen dieser Implementierungen ist der ultimative Killer für WP in Unternehmensumgebungen.

@ wsydney76 Bitte Feldgruppen in ACF nicht in Metaboxen enthalten sein müssen, sondern es gibt auch den Stil "Nahtlos (keine Metabox)" mit den Optionen "Seite", "Normal - Nach Inhalt" und "Hoch - zwischen Titel" und Herausgeber (!!!) '. Letzteres ist wichtig, um einen aussagekräftigen Bearbeitungsfluss zu schaffen.

Es ist erwähnenswert, dass dies in WordPress nicht "nur funktioniert", sondern einen benutzerdefinierten Plugin-Code erfordert, um die übliche Metabox-Benutzeroberfläche zu entfernen. Es ist daher anzunehmen, dass dies zusätzliche Arbeit von ACF erfordert, um mit Gutenburg zu arbeiten.

Mach es einfach. Wenn für den benutzerdefinierten Beitragstyp keine Unterstützung für den Editor (Gutenberg) deklariert ist, verwenden Sie Ihre Vorstellungskraft, CSS-Kenntnisse und Ihre talentiertesten Kerndesigner, um den gesamten Editor in etwas anderes zu konvertieren. Lassen Sie es als nichts erscheinen, was Client / Benutzer im (nativen) Nachbearbeitungsbildschirm sehen. Es geht nur um das Aussehen. Kunden ist es egal, ob Gutenberg im Hintergrund arbeitet oder nicht, es könnte sie auch nicht weniger interessieren, selbst wenn sie von Webentwicklern darüber informiert werden. Sie sind visuelle Arten von Menschen.

In Bezug auf die Abwärtskompatibilität habe ich bereits im Februar eine Long Support- Version von WordPress vorgeschlagen, lange bevor Gutenberg 5.0 ankündigte.

Zu diesem Zeitpunkt schien es eine unwahrscheinliche Aufgabe zu sein, aber jetzt, da dies geschieht, ist es noch wichtiger zu diskutieren, wie man 4.9 zu einer LTS-Version macht, die Unterstützung vor 4.9 abschneidet und sich auf 5.0 konzentriert.

Den Beitrag finden Sie hier:
https://khromov.se/wordpress-needs-another-long-term-support-version/

10 Jahre + WordPress-Entwickler hier. Wie viele erwähnt, ist diese Entwicklung groß für den Inhalt. Es ist eine wirklich benötigte Standardlösung für dynamische Inhaltsblöcke mit benutzerdefiniertem Markup. Dies schränkt jedoch die Verwendung von Beitragstypen in einer Weise ein, die vom Inhalt abweicht und WordPress näher an ein Framework heranführt.

Als Beispiel: Ich habe eine Reihe von Plugins erstellt, mit denen nicht nur Felder für Beitragstypen (wie viele andere) erstellt werden können, sondern auch Beziehungen zwischen ihnen (dh eins zu eins, eins zu viele usw.). Dies (zusammen mit weiteren Funktionen) verwandelt Post-Typen in etwas, das Modellen in Frameworks wie Laravel oder Rails sehr nahe kommt, und ich verwende dann ein DSL, um mit diesen Posts, ihren Daten und ihren Beziehungen zu arbeiten.

Diese Art der Verwendung ist alles andere als ungewöhnlich, und WordPress selbst hat die kreative Verwendung von Beitragstypen gefördert, indem es Entwicklern ermöglicht hat, Beitragstypen als nicht öffentlich zu deklarieren. Flags wie "public", "public_queryable" und "show_ui" sollen Entwicklern die Verwendung von Beitragstypen für andere Zwecke als eine einfache 1: 1-Spiegelbeziehung mit einer öffentlichen Seite auf der Website ermöglichen

Wie passt Gutenberg zu dieser Vision?

Ich sehe keine andere Lösung, als diesen Editor optional zu halten, dh er sollte weiterhin TinyMCE ersetzen, aber der Editor sollte optional bleiben, genau wie TinyMCE derzeit optional ist.

Wenn wir weiterhin Beitragstypen erstellen können, die den Editor nicht unterstützen, und weiterhin Metaboxen in diesen Beitragstypen verwenden können, könnte meiner Meinung nach ein Konsens viel schneller erreicht werden.

Die Übernahme des neuen Editors durch Entwickler von Themes & Plugins könnte mit dieser Art von Ansatz langsamer werden, aber ich sehe ehrlich gesagt keinen anderen Ausweg, der nicht bedeutet, den 4.9 LTS-Weg zu gehen, der den Start neuer Projekte ermöglichen würde mit WP 5.0 und Legacy-Projekten, um bei 4.9 LTS zu bleiben.

UPDATE: Als ich diesen Kommentar schrieb, war der Titel des Threads anders und die Möglichkeit, Metaboxen zu verwerfen, wurde diskutiert (dh das Kernteam hatte diese Frage noch nicht eindeutig mit einem festen "Nein" beantwortet, wie in den Kommentaren unten). In einem solchen Szenario hätte gutenberg einfach dynamische Blöcke unterstützt und die vielen anderen Anwendungsfälle für Metaboxen ignoriert, daher mein obiger Kommentar.

Nachdem ich einige Zeit damit verbracht habe, alle Kommentare zu lesen, scheint es mir, dass das wahrscheinliche Ergebnis dieser Entwicklung des Bearbeitungsbildschirms darin besteht, eine neue API für Metaboxen bereitzustellen, die in diesem js-basierten Bearbeitungsbildschirm funktioniert. Das heißt, wir verlieren nicht wirklich die Fähigkeit, Beiträge auf kreative Weise zu verwenden, wie ich oben erwähnte, aber wir bekommen einfach eine neue API, um dies zu tun, und die Benutzeroberfläche wird js-basiert sein.

Wir planen, Pods 2.7 zum Erstellen einer reaktionsbasierten App mit der WordPress REST-API und
Wird Gutenberg mit Pods kompatibel sein?

Ich sehe, dass dieses wichtige Problem von jedem Meilenstein entfernt wurde. Es wurde wieder de-priorisiert, während Schnickschnack für die Blog-Bearbeitung viel Arbeit bekommen und zu Betas hinzugefügt werden. Dies ist sehr besorgniserregend für die Zukunft von Wordpress als CMS.

Ich habe meine eigenen Codegeneratoren erstellt, die von GenerateWP inspiriert sind. Für meinen eigenen und privaten Gebrauch auf localhost, nicht öffentlich.
Wie auch immer, ich frage mich, wie es im Gutenberg aussehen würde, wenn der Wechsel abgeschlossen ist. ACF-Felder, viel benutzerdefinierter PHP-Code für die Vorschau.

Wir haben dieses Problem nicht vergessen. Vielmehr handelt es sich um ein äußerst kompliziertes Thema, mit dem wir uns gerade erst befassen, zusammen mit vielen anderen Prioritäten, damit der Editor gut funktioniert.

Einige der Schwierigkeiten, auf die wir bei der Verkabelung von Metaboxen stoßen werden, können beim Lesen von Nr. 2251 offensichtlich werden, das auch einige Informationen zu den nächsten Schritten aus technischer Sicht enthält.

Der wichtigste Punkt, den ich hier hervorheben möchte, ist, dass wir Hilfe von der Community benötigen, um diese Implementierung zu planen und zu testen.

Hier ist ein Ausgangspunkt für eine Liste von Plugins:

Plugin                                      Active installs
======                                      ===============
advanced-custom-fields                           1,000,000+
custom-post-type-ui                                400,000+
meta-box                                           200,000+
types                                              200,000+
cmb2                                               100,000+
pods                                                50,000+
custom-field-suite                                  40,000+
wck-custom-fields-and-custom-post-types-creator     20,000+
piklist                                             10,000+
carbon-fields                                        2,000+

Plugins, die oben nicht angezeigt werden, höchstwahrscheinlich, weil sie sich nicht im WP.org-Plugin-Verzeichnis befinden:

• Feldmanager

Wenn Ihnen andere weit verbreitete Plugins bekannt sind, die eine ähnliche Aufgabe erfüllen, teilen Sie uns dies bitte hier in dieser Ausgabe mit.

Wenn Sie Entwickler eines dieser Plugins sind und / oder Details darüber bereitstellen können, mit welchen WordPress-Hooks diese Plugins ihre Metaboxen hinzufügen und verwandte Skripte oder Stylesheets in die Warteschlange stellen, teilen Sie uns dies bitte hier in dieser Ausgabe mit oder erstellen Sie ein neues Problem für jedes spezifische Plugin in der obigen Liste. Das Sammeln dieser Informationen ist zeitaufwändig und für weitere Entwicklungsbemühungen äußerst hilfreich, um alles an einem Ort zu haben. Zum Beispiel:

Advanced Custom Fields fügt seine Metaboxen hinzu, indem ein Hook für admin_enqueue_scripts registriert wird. Dieser Hook überprüft, ob die aktuelle Seitenladung entweder post.php oder post-new.php , und fügt in diesem Fall eine Aktion admin_head die add_meta_box aufruft. Der WP-Kern führt seine do_meta_boxes -Aufrufe kurz nach dieser Aktion in edit-form-advanced.php .

Wenn Sie ein Entwickler sind, der mit der Art und Weise vertraut ist, wie WordPress derzeit Metaboxen rendert und speichert, ist Ihre Eingabe hier und / oder auf # 2251 willkommen.

Hallo Leute,
Elliot hier - ACF dev.

ACF verwendet die Aktion admin_enqueue_scripts , um eine "Feldgruppen-Matching-Logik" auszuführen, und dann die Aktion admin_head , um Metaboxen hinzuzufügen (über add_meta_box() ). Die Aktion add_meta_boxes wird nicht verwendet.

Kann ich hier eine offensichtliche Frage stellen? Warum diskutieren wir die "Schwierigkeiten" von Metaboxen? Diese sind ein wesentlicher Bestandteil jeder WP-Website. Sicherlich kann die Metabox-Logik unverändert bleiben und neben dem neuen Gutenberg-Editorbereich leben.

Bitte markieren Sie auch

Vielen Dank
E.

Hallo Leute-

Ich formuliere immer noch einige Gedanken und Ideen, aber ich wollte eine kurze Frage stellen, da diese Diskussion anscheinend etwas zu konzentriert wird.

Warum reden wir nur über das Hinzufügen von Feldern zu Meta-Boxen? Das aktuelle System ermöglicht es uns, alles hinzuzufügen. Daten, Javascript, um APIs von Drittanbietern zu verwenden, um deren Tools zu verwenden, eine schnelle Anzeige von Notizen oder Hilfeinformationen und sogar Bilder von niedlichen kleinen Kätzchen, die den Leuten eine hohe Fünf geben (ok, vielleicht nicht diese, aber wer weiß, richtig?!).

Der Punkt, den ich hier ansprechen möchte, ist, dass Meta-Boxen universelle Container sind, die eine Vielzahl von Dingen enthalten können, die Felder enthalten, aber nicht darauf beschränkt sind. Im Moment ist es mit PHP ziemlich einfach, dies zu tun. Bitten wir die Leute derzeit jedoch, zu wissen, wie man eine React-Komponente schreibt, um beispielsweise Text einzufügen?

Wie gesagt, ich versuche nur, den Kontext des Gesprächs zu erweitern.

Vielen Dank,

Kevin - Hauptentwickler für Piklist

Diese Frage wurde in vielen Kommentaren oben erwähnt, aber meines Wissens nicht beantwortet:

Ist es möglich, den vorhandenen TinyMCE-Post-Editor durch Gutenberg zu ersetzen, während der Rest der Benutzeroberfläche, einschließlich Meta-Boxen und vorhandener Hooks, unverändert bleibt?

Dieser eingeschränkte Bereich würde es Gutenberg ermöglichen, benutzerdefinierte Beitragstypen ein- oder auszuschließen, indem bei der Registrierung des Beitragstyps die Unterstützung von editor definiert wird.

• Wenn editor Support registriert ist, wird Gutenberg auf dem Bearbeitungsbildschirm angezeigt, und vorhandene Meta-Boxen funktionieren weiterhin wie heute im aktuellen Editor.
• Wenn der Support für editor nicht registriert ist, wird Gutenberg nicht geladen und die leere Leinwand steht Meta-Boxen wie heute zur Verfügung.

Dieser Ansatz scheint die massive Herausforderung der Abwärtskompatibilität mit vorhandenen Meta-Box-Implementierungen zu vermeiden und gleichzeitig Ressourcen freizugeben, um den bestmöglichen Editor zu erstellen.

Kann ich hier eine offensichtliche Frage stellen? Warum diskutieren wir die "Schwierigkeiten" von Metaboxen?

@elliotcondon - Wenn ein

Vielen Dank für die Bestätigung der Informationen, die ich über die Registrierung der Metaboxen durch ACF gesammelt habe. Um weitere Fortschritte bei der Implementierung von ACF zu erzielen, sind die folgenden Punkte hilfreich:

• Welche Skripte und Stylesheets werden in die Warteschlange gestellt, um die Funktionalität von ACF-Metaboxen zu steuern?
• Welche Aktionen sind dafür verantwortlich, sie in die Warteschlange zu stellen?
• Alle Bedingungen, die steuern, ob sie in die Warteschlange gestellt werden oder nicht.

Warum reden wir nur über das Hinzufügen von Feldern zu Meta-Boxen?

Ich möchte an einen Ort gelangen, an dem es dem Gutenberg-Code nicht sehr wichtig sein muss, was eine Metabox tatsächlich tut.

Um dieses Ziel zu erreichen,

• Welche Aktionen sind dafür verantwortlich, add_meta_box aufzurufen, um Metaboxen zu registrieren?
• Alle Bedingungen, die steuern, ob sie registriert sind oder nicht (z. B. der aktuelle Bildschirm ist post.php oder post-new.php ).

In dieser Ausgabe konzentrieren wir uns weiterhin darauf, dass vorhandene PHP-Metaboxen neben der Gutenberg-Oberfläche funktionieren.

Im Moment ist es mit PHP ziemlich einfach, dies zu tun. Bitten wir die Leute derzeit jedoch, zu wissen, wie man eine React-Komponente schreibt, um beispielsweise Text einzufügen?

Ja, wir müssen eine Reihe von APIs ausarbeiten, um Metaboxen im "neuen Stil" zu erstellen. Folgendes haben wir heute für Blöcke: Ich gehe davon aus, dass es ziemlich ähnlich sein wird, da Metaboxen als "Blöcke" registriert werden, die an einem anderen Ort als post_content sparen können: http://gutenberg-devdoc.surge.sh/

Die Diskussion über Metaboxen neuen Stils sollte unter # 1684 oder in einem separaten Problem stattfinden, um eine technische API vorzuschlagen.

Wenn der Support für editor nicht registriert ist, wird Gutenberg nicht geladen und die leere Leinwand steht Meta-Boxen wie heute zur Verfügung.

@kevinwhoffman - Gutenberg, wie es heute geschrieben wurde, soll ein post_content Editor sein. Wenn also die Unterstützung für editor nicht aktiviert ist, deaktivieren wir sie zumindest vorerst. Dies ist auch aus Code-Sicht eine ziemlich einfache Aufgabe. Können Sie hierfür eine neue Ausgabe erstellen, die ich mit dem Label Good First Task ?

Gutenberg, wie es heute geschrieben wurde, soll ein post_content Editor sein.

@nylen Wenn Gutenberg wirklich als post_content Editor gedacht ist, sollten Meta-Boxen in Ruhe gelassen werden, da sie sich nicht mit post_content befassen.

Darüber hinaus ist die Notwendigkeit einer API zur Übersetzung von PHP-Meta-Boxen in React-Meta-Boxen ein hergestelltes Problem. Es muss kein Problem sein, aber es ist zu einem Problem geworden, weil irgendwann auf der ganzen Linie entschieden wurde, dass das Umschreiben des post_content Editors auch die Funktionsweise von Meta-Boxen komplett ändern sollte.

Sie haben die enorme Herausforderung beim Schreiben einer solchen API in # 2251 beschrieben. Die Übersetzung von PHP-Meta-Boxen in React für eine beliebte Lösung für benutzerdefinierte Felder wie ACF ist schwierig genug, geschweige denn für jede Meta-Box-Implementierung, die heute existiert, ob beliebt oder nicht. Es skaliert nicht.

@ Kevinwhoffman - Sehr gut gesagt. Dies spiegelt meine genauen Gedanken sowie viele andere Entwickler wider, mit denen ich gesprochen habe.

Ich möchte dieses Problem nicht vom Thema abbringen, aber ich verstehe nicht, warum es bei der Einführung eines neuen JS-Seitenerstellers Probleme mit der Metabox geben muss. Das meine ich, wenn ich sage:

Warum diskutieren wir die "Schwierigkeiten" von Metaboxen?

Ich freue mich, das zu lesen:

Wenn die Editorunterstützung nicht registriert ist, wird Gutenberg nicht geladen und die leere Leinwand steht Meta-Boxen wie heute zur Verfügung.

Wenn das oben Gesagte zutrifft, sollte die gesamte wp-admin-Logik (Aktionen, Funktionen usw.) für den Bearbeitungsbildschirm eines Posts gleich (ish) bleiben. Daher sollte es keinen Grund geben, warum das Metabox-HTML nicht wie seit Jahren gerendert werden kann.

@nylen
ACF stellt einige JS- und CSS-Dateien in die Warteschlange, um das HTML-Element der ACF-Metabox zu formatieren und mit ihm zu interagieren.
ACF verwendet die Aktionen 'admin_enqueue_scripts', um diese Assets hinzuzufügen
Viele andere Plugins und Themes stellen Stile / Skripte in die Warteschlange - warum sollte dies ein Problem sein?
ACF verwendet JS nicht zum Speichern von Metadaten. Es verwendet die Aktion save_post , um alle $_POST Daten zu speichern - ziemlich normales Zeug.

Darüber hinaus ist die Notwendigkeit einer API zur Übersetzung von PHP-Meta-Boxen in React-Meta-Boxen ein hergestelltes Problem.

Das ist nicht ganz das, was wir tun. Es ist eher so: Da wir den traditionellen post.php nicht mehr verwenden, müssen wir die Dinge heraussuchen, die wir brauchen.

Wenn die Editorunterstützung nicht registriert ist, wird Gutenberg nicht geladen und die leere Leinwand steht Meta-Boxen wie heute zur Verfügung.

Zur Verdeutlichung: Dies ist derzeit nicht der Fall, aber es wäre vernünftig, dies in einer PR zu untersuchen. Wenn Sie daran interessiert sind, dass dies heute funktioniert, helfen Sie uns bitte, es wird viel schneller gehen.

@kevinwhoffman @elliotcondon @nylen Oder noch besser, wie wäre es mit:

• Wenn block-editor Support registriert ist, verwenden Sie Gutenberg.
• Wenn editor Support registriert ist, verwenden Sie TinyMCE.
• Wenn weder Support noch Registrierung registriert sind, werden weder Gutenberg noch TinyMCE geladen.

Ich bin nicht dafür, die Erfahrung des WP-Administrators aufgrund der Anwesenheit oder Abwesenheit von Gutenberg zu brechen.

Wenn Gutenberg = New React Meta Boxes und No Gutenberg = Old PHP Meta Boxes, dann ist ein gebrochener Administrator die Richtung, in die wir gehen.

Meta-Boxen sollten überall gleich funktionieren, unabhängig davon, ob ein Editor vorhanden ist.

Beispiel: Angenommen, ich habe ein Plugin, das eine Meta-Box hinzufügt, um Beiträge mit 5 Sternen zu bewerten. Das Plugin ist so aufgebaut, dass jeder Beitragstyp bewertet werden kann. Warum sollten sich die Interna dieser Meta-Box ändern, je nachdem, ob der Beitragstyp einen Editor verwendet oder nicht?

@ Kevinwhoffman

Ich bin nicht dafür, die Erfahrung des WP-Administrators aufgrund der Anwesenheit oder Abwesenheit von Gutenberg zu brechen.

War das eine Antwort auf meinen Vorschlag bezüglich block-editor oder etwas anderes?

Übrigens, ich sehe meinen Vorschlag nicht als Bruch der Erfahrung, ich sehe es als Aufbau auf Ihrem Vorschlag, vorhandene Meta-Boxen aufzunehmen, wenn sie in der WordPress-Konfiguration vorhanden sind.

@mikeschinkel Die Fähigkeit, Gutenberg zu aktivieren oder zu deaktivieren, ist notwendig, aber ich argumentiere gegen die Idee, dass Gutenberg das Verhalten von Meta-Boxen bestimmt. Das sind getrennte Themen.

@ Kevinwhoffman Ich bin

Von Pods aus machen wir normale, dokumentierte Standardaufgaben mit denselben Aktionen wie ACF und CMB2. Wir alle machen es so, wie es jetzt empfohlen wird.

+1 für die Fähigkeit, Meta-Boxen neben Gutenberg weiter zu verwenden, können Benutzer Gutenberg letztendlich für Dinge verwenden, die direkt in den Inhalt gehören, und für alles andere gibt es noch die Meta-Boxen, die sie für Attribute und zusätzliche Informationen zu einem "Beitrag" lieben "(jeglicher Art).

-1 Wenn Sie alles in React neu schreiben müssen, unterstützen Sie zumindest beide für eine lange Zeit, bis alle Zeit haben, sich mit der React-Methode vertraut zu machen, und sie unterstützt mehr / bringt die Knicke für Meta-Box-Implementierungen heraus. Ich denke nicht, dass es eine Zeit gibt, in der die PHP-Meta-Boxen auslaufen sollten, sie für den Backcompat behalten und Plugins migrieren sollten, wenn die Dokumentation der React-Meta-Box und die Entwicklerfähigkeiten in diesem Bereich verbessert werden.

Nach der Diskussion in diesem Ticket sowie den daraus resultierenden öffentlichen und privaten Gesprächen denke ich, dass hier eine kritische Frage beantwortet werden muss:

Beabsichtigt WordPress, die Metabox-API offiziell zu verwerfen?

Wenn die Antwort Nein lautet, ist das Ganze „Bewegen wir die Dinge und lähmen sie ein wenig“ ein Nichtstarter. Wenn die API weiterhin den Abwärtskompatibilitätsstandards von WordPress Core entspricht, ist zu erwarten, dass alle vorhandenen Metabox-Implementierungen nur funktionieren. Wie es in WordPress der Fall ist.

Wenn die Antwort Ja lautet, ist dies eine enorme Änderung der Richtlinien zur Abwärtskompatibilität und das Ende der Ära für die gesamte WordPress-Entwicklung. Es erfordert nicht nur das „Lösen“ von Metaboxen in Gutenberg. Es würde eine enorme Umschulung und Klärung erfordern, dass die langjährige Spanne der WordPress-Kernentwicklung, die auf eine bestimmte Art und Weise durchgeführt wird und ein gewisses Maß an Abwärtskompatibilitätserwartungen bietet, vorbei ist.

Leider scheint die aktuelle Antwort nicht Ja zu sagen, sondern beabsichtigt, Dinge zu brechen, während sie vorgibt, ein Nein zu sein . Persönlich finde ich es äußerst untypisch für ein wichtiges Kernmerkmal und es ist sehr beunruhigend, dass es so gemacht wird.

Der Post-Edit-Bildschirm ist der am besten angepasste Bildschirm für jedes Projekt, das über ein Barebone-Blog hinausgeht.

Diese Anpassungen sind nicht auf die Registrierung von Metaboxen beschränkt. Jeder Hook, den die Bearbeitungsadministrationsbildschirme bieten, wird in demselben Projekt verwendet. In den Fällen, in denen es keinen Hook gibt, verwenden Entwickler jQuery, um UI-Elemente in die Seite einzufügen.

Für diese Anpassungen muss es also einen Weg nach vorne geben.

Für Metaboxen ist Fieldmanager das Werkzeug der Wahl, da es VIP-genehmigt ist. Fieldmanager ist leistungsstark, konzentriert sich jedoch auf eine begrenzte Anzahl von Feldern. Legacy-Codebasen können häufig nicht nachgerüstet werden, um Fieldmanager oder eine andere Dienstprogrammbibliothek zu verwenden.

Daher werden viele Metaboxen immer noch mit benutzerdefiniertem Code erstellt. Benutzerdefinierter Code bedeutet eine Kombination aus PHP und JavaScript, häufig mit Ajax-gesteuerten Interaktionen.

Der Vorschlag, all diese sorgfältig gestalteten Metaboxen von ihrer beabsichtigten Position in einen Bereich unterhalb des Editors zu stopfen, ist absurd.

Eine Regression der derzeit verfügbaren Anpassungsoptionen auf dem Bildschirm "Nachbearbeitung" ist nicht akzeptabel.

Wenn vorhandener Code aktualisiert werden muss, können Sie 12 bis 18 Monate ab dem Zeitpunkt zählen, an dem alle neuen APIs fertiggestellt sind, damit diese Upgrades für Clientprojekte durchgeführt werden können. Dies bedeutet, dass es einen Zeitraum mit zwei Ausführungen geben muss, in dem sowohl die Legacy-APIs als auch die neuen APIs nebeneinander existieren.

Ich verstehe nicht, warum Metaboxen überhaupt etwas mit Gutenberg zu tun haben? Es ist nur eine Backend-Seite, Bildschirm. Kann auf Hunderte von Arten angeordnet werden.
Sie sagten, die derzeitige Implementierung unterbricht React.

Lassen Sie die Entwickler entscheiden, ob sie ihre Metabox an Gutenberg binden oder draußen lassen möchten.
All dieses Problem ist, weil Sie davon ausgehen, dass jeder Gutenberg-Blöcke auf die eine oder andere Weise herstellen muss. Was ist, wenn sie es nicht wollen, brauchen sie es nicht?

Zweites großes Problem für mich persönlich. Ich hatte immer Probleme mit Javascript, ich bin ein Anti-Talent für diese Sprache.
Ok, nicht alles dreht sich um mich herum, sondern nur um es zu sagen. Es wird nicht einfacher sein, Metaboxen hinzuzufügen als zuvor.

Ich denke, @Rarst hat das Problem wunderbar zusammengefasst. Die Community braucht eine klare Antwort und es scheint, dass das Entwicklerteam geneigt zu sein scheint, der Abwertungsrichtung zu folgen, aber es kann es einfach nicht klar formulieren, weil es zuerst versucht, eine Lösung zu finden, die ich voll und ganz respektiere. Wir brauchen keine Community, die monatelang in Panik gerät, aber gleichzeitig muss dieselbe Community über genügend Köpfe und einen klaren Weg verfügen. Dies ist ehrlich gesagt ein schwerer Kompromiss.

@ fklein-lu Ich bin absolut anderer Meinung, dass Fieldmanager das "Werkzeug der Wahl" sein sollte. Ich sehe es nicht einmal in der Liste der Top 10 Felder Plugin.
https://github.com/WordPress/gutenberg/issues/952#issuecomment -320523428

Wie viele andere bereits gesagt haben, führt die Änderung der Funktionsweise von Metaboxen zwar zu dem Wunsch, Metaboxen und Gutenberg zu einer kohärenten und vernetzten Schnittstelle zu machen, jedoch zu einer unglaublichen Komplexität, die für die Menschen eine enorme Abschreckung darstellen kann. Die Geschichte hat uns gezeigt, dass die Einführung schwerwiegender Inkompatibilitäten zwischen Versionen eine Community stark fragmentieren kann.

Wie würde man Metaboxen zum Dashboard-Backend-Bildschirm hinzufügen?
Es hat nichts mit Gutenberg zu tun.

@khromov Lies, was ich tatsächlich geschrieben habe, anstatt meine Worte falsch zu zitieren. Wenn Sie den Beitrag lesen, auf

@ fklein-lu Ich bin mir nicht sicher, warum du denkst, dass ich dich falsch zitiere. Hier ist der vollständige Kontext: "Für Metaboxen ist Fieldmanager das Werkzeug der Wahl, da es VIP-genehmigt ist." Ich kenne niemanden, der Fieldmanager verwendet, daher fällt es mir schwer, dieses Zitat zu verstehen.

Mir ist bekannt, dass Fieldmanager nicht auf WPorg ist. Ich sage, wir haben keine Nutzungsdaten. Ich bezweifle sehr, dass es mit einigen der Top-Plugins mithalten kann, und es hat auch sehr wenig Community-Unterstützung, außer denjenigen, die es für VIP verwenden, was eine verschwindend kleine Minderheit der Gesamtzahl der Entwickler darstellt.

In unserer Agentur glauben wir, dass WordPress irgendwo in 3.x den Schritt vom Blogging-System zum Content Management System gemacht hat. Derzeit können wir den Inhalt so gestalten, wie es das Projekt benötigt, und wir verwenden benutzerdefinierte Beitragstypen und Meta-Boxen, um eine Vielzahl unterschiedlicher Inhalte zu erstellen, nicht nur Text.

Wenn der Blockeditor in 5.0 obligatorisch wird, glauben wir fest daran, dass dies ein ideologischer Rückschritt vom CMS zum Blogging-System wäre. Es gibt unzählige Unternehmensanwendungen, auf denen WordPress als Hotelbuchungslösung, Jobplattform, kopfloses CMS für eine App, Ortungsdienste usw. ausgeführt wird, und in vielen dieser Anwendungsfälle ist der Editor nicht einmal aktiviert.

Die vollständige Abwärtskompatibilität mit der aktuellen Metabox-Implementierung ist ein absolutes MUSS. Wenn Sie dies brechen, wird das Vertrauen von Kunden und Benutzern für die kommenden Jahre gebrochen. Meine Lieblingslösung wäre etwas in Anlehnung an die "them_supports" und die ablenkungsfreie Benutzerfreundlichkeit.

TL; DR: Erwarten Sie nicht, dass Unternehmenskunden ihren Code innerhalb der nächsten 12 Monate für andere Zwecke als die Wartung aktualisieren. Fügen Sie eine Verfallsrichtlinie / Warnung mit einem geeigneten Zeitplan hinzu. Erwarten Sie einen enormen Vertrauensverlust in WordPress, wenn Sie eine Änderung (auch zum Besseren) in Bezug auf die Benutzerfreundlichkeit des Backends und des Codes erzwingen.

Es wurde irgendwie als Politik oder Abstimmung / Wahlen, nicht als Kodierung. Einige Leute entschieden, dass alte Metaboxen "alt", "rückwärts", "einschränkend" sind und es keinen Platz mehr für sie gibt. Ohne wirkliche Argumente und Gründe gegen sie. Ich habe sie nicht gesehen, außer dass React und andere Skripte turbo-modern sind.

Ich unterstütze Sie immer noch bei der Suche nach einer Lösung, um alte Metaboxen loszuwerden und dies so zu tun, wie Sie es sich Gutenberg vorgestellt haben. Aber anscheinend haben Sie keine Ahnung, wie Sie es lösen sollen.

Es ist schwierig, all dies zu diskutieren, wenn für mich noch viel Schwarzes Loch ist. Und ich bin nicht der einzige.

Um nur zu sagen, wie objektiv ich in dieser Angelegenheit bin, versuche ich nicht:

• Ich denke immer noch, dass TinyMce und der alte Post-Bildschirm (mit Metaboxen) etwas Schönstes sind, das ich in der CMS-Welt gesehen habe. Funktionen, Filter, Erweiterungen und schönes Design. Ja, pure Schönheit und Vergnügen.
• Trotzdem habe ich Gutenberg vom ersten Tag an akzeptiert. Ja, lassen Sie all das "Alte" hinter sich, wechseln Sie und schauen Sie niemals zurück.

Sie wussten etwas, was ich nicht weiß. Sie besitzen Code. Aber ich bin mir nicht mehr sicher.

Zweitens, habe es vergessen und ist in diesem Zusammenhang sehr wichtig. Es wird hier schon einige Male erwähnt.
Ich mache die Dinge ein bisschen anders als andere. Der Grund, warum ich Gutenberg (einer von ihnen sowieso) vom ersten Tag an akzeptiert habe, ist, dass ich persönlich keinerlei Probleme haben werde, Leute davon zu überzeugen, dass ich Websites für die Verwendung von Gutenberg gemacht habe. Es ist ein großer Schock, wenn Sie ihnen etwas so anderes als TinyMce aufzwingen.
Ich mache alle Plugin- und WP-Core-Updates für alle kostenlos. Also in diesem Dilema, wenn sie zwischen Gutenberg und dem Stoppen von Updates für den Rest der Zeit wählen müssen. Ich denke, ihre Wahl ist offensichtlich,

Viele andere Entwickler, Unternehmen, berechnen für Updates. Dieses Dilema wird dann also nicht so unbeschwert sein.

@khromov Ich arbeite für Alley, die Fieldmanager unterhält. Wir überwachen aktiv den Faden, während die Produktrichtung bestimmt wird. Es wäre fair zu sagen, dass die WordPress.org-Benutzerbasis im Allgemeinen keinen Fieldmanager verwendet, aber das Plugin hat eine umfassende Akzeptanz als Bibliothek und benutzerdefiniertes / Unternehmens-Framework.

Ich möchte auch +1 @Rarst und @kevinwhoffman. Die vollständige Unterstützung bestehender Metaboxen könnte weiterhin eine Zukunft ermöglichen, in der wir "Legacy" -Metaboxen durch TBD-Gutenberg-Äquivalente ersetzen. Die derzeitige Unsicherheit in Bezug auf die Abwärtskompatibilität muss jedoch so schnell wie möglich verringert werden.

Die Anzahl der Plugin-Installationen von WordPress.org kann nicht die einzige Metrik für das Einschließen oder Ausschließen eines Plugins oder einer Bibliothek sein. Ich kenne eine einzelne Site, die Fieldmanager ausgiebig nutzt und fast 24 Millionen eindeutige Besucher pro Monat bedient.

Obwohl nur wenige Entwickler ein bestimmtes Plugin verwenden, sind sie für die Entwicklung und Pflege von Websites verantwortlich, die überproportional viel Verkehr und viel Sichtbarkeit erhalten.

Sie können also nicht aus dieser Diskussion ausgeschlossen werden. Ich bin der Meinung, dass das Gutenberg-Team von Automattic mit dem VIP-Team zusammenarbeiten sollte, um einen Einblick in diese Anwendungsfälle zu erhalten.

Diese Unternehmensprojekte bewegen sich langsamer. Es gibt eine Menge Arbeit, die in das Upgrade von Metaboxen und anderen UI-Elementen investiert wird, die keine eigentliche Codierungsarbeit sind. Es gibt nicht einmal genügend Unternehmensentwickler, um alle diese Websites im Zeitraum 5.0 zu aktualisieren.

Wie von anderen Personen in diesem Thread hervorgehoben, muss es einen Upgrade-Pfad geben, der dieses Tempo berücksichtigt. Auf diese Weise können Änderungen im Rahmen proaktiver Wartungsarbeiten schrittweise vorgenommen werden.

@ fklein-lu siehe oben, wir hören zu und Sie können jederzeit Kontakt aufnehmen, wenn Sie am Code zusammenarbeiten möchten!

Was VIP und den Unternehmensmarkt betrifft, so gehe ich davon aus, dass es nächste Woche im WordCamp for Publishers in Denver mehr als nur ein paar Gespräche zu diesem Thema geben wird. Das heißt, wir haben uns an Gutenberg-Entwickler & @m gewandt, aber AFAIK wird keiner teilnehmen können.

In Bezug auf die Zeitleiste "5.0" gehen die von mir befragten Unternehmensingenieure derzeit davon aus, dass es einen ausreichend einfachen Opt-out-Pfad gibt, um den vorhandenen TinyMCE-Editor und die vorhandenen Metaboxen zu verwenden. Glauben Sie, dass das Gutenberg-Team auch dieser Annahme das 👍 gegeben hat.

Und ich habe eine Website, die Jetpack verwendet und nur 2 eindeutige Besucher pro Tag hat.
Hör auf, so leicht beleidigt zu sein. Es ist WordPress, keine Diskussion über die neue Joomla-Version. :) :)

@ fklein-lu Stimme dir absolut zu. Aber wenn irgendetwas das "Werkzeug der Wahl" für Metabox-Felder wäre, würde ich denken, dass es die vorgeschlagene Fields-API wäre .

@davisshaver Ich denke, das ist die kluge Sache zu tun. Wenn WordPress versucht, den Verfallsansatz ohne Abwärtskompatibilität zu stärken, kann ich leicht jemanden sehen, der alte Teile des Codes in ein "paralleles", Legacy-basiertes alternatives Post- und Metabox-System portiert und es als Plugin oder ähnliches verpackt. Persönlich ist das das absolut Letzte, was ich mir erhoffen würde. Auch dies ist definitiv alles harte Arbeit, also wünsche ich allen, die daran beteiligt sind, die WordPress-Community in dieses neue unerforschte Land zu bringen, viel Glück.

Vielen Dank an alle, die sich hier gemeldet haben und Bedenken und Ideen geäußert haben. Dies wird ein langer Thread, aber ich werde versuchen, ein paar Punkte zu klären.

Beabsichtigt WordPress, die Metabox-API offiziell zu verwerfen?

Nein.

Die Frage, die noch nicht vollständig beantwortet ist, lautet: Wie funktionieren Meta-Boxen im Kontext des Gutenberg-Editors? Sollten sie gleich bleiben oder sich weiterentwickeln? Wie können wir uns mit möglichst wenig Störungen den Entwurfszielen nähern?

Dieses Problem besteht nicht aufgrund mangelnden Verlangens, sondern aufgrund mangelnder Ressourcen. Das Hauptaugenmerk dieses Projekts liegt auf der Bereitstellung einer umfangreichen Oberfläche zur Bearbeitung von Inhalten, die für die direkte Bearbeitung von Benutzerinhalten durch den Begriff der Blöcke optimiert ist. (Nachdem ich Meta-Boxen ausgiebig für verschiedene Projekte verwendet habe, glaube ich, dass Blöcke für viele dieser Anforderungen einen besseren Fortschritt bieten und gleichzeitig eine bessere Benutzererfahrung bieten können.)

Es gibt jedoch mehrere Möglichkeiten, wie Meta-Boxen und Erweiterbarkeit behandelt werden können:

• Wenn wir feststellen, dass eine Meta-Box registriert ist, können wir auf die alte Schnittstelle zurückgreifen, nichts ändert sich.
• Wir könnten die Bearbeitung des Inhalts und das Ändern von Metainformationen in zwei Bildschirme oder Stufen aufteilen.
• Wir können versuchen zu sehen, wie machbar es ist, diese so zu rendern, wie sie (PHP) unter dem Inhalt sind: # 2251.
• Ein Theme / Plugin / CPT kann die Registrierung der neuen Schnittstelle nach Bedarf aufheben.
• Verschiedene Elemente, die auf Meta-Boxen beruhten, konnten in Blöcke für die Benutzeroberfläche konvertiert werden (Daten werden weiterhin separat gespeichert).
• Wir könnten API-basierte Meta-Box-Erweiterbarkeit wie die Fields-API implementieren.

Oder eine beliebige Kombination davon.

Wir würden uns auf jeden Fall über jede Hilfe der Community beim Aufbau der besten Lösung freuen, da auch hier der Mangel an Sicherheit kein Mangel an Willen ist. Nur dass die möglichen Lösungen in der Praxis untersucht und Kompromisse - Design und Entwicklung - klar formuliert werden müssen.

Nein.

Danke , ich denke, viele Leute haben gerade ausgeatmet.

Die Frage, die noch nicht vollständig beantwortet ist, ist, wie Meta-Boxen im Kontext des Gutenberg-Editors funktionieren.

Warum _are_ Meta-Boxen im Kontext des Gutenberg-Editors?

Die Antwort scheint zu sein, dass Gutenberg darauf abzielt, den gesamten Post-Editor _screen_ durch eine JS-gesteuerte Implementierung zu ersetzen. Ich hatte die Entwicklung nicht verfolgt, um mir die Gründe dafür bewusst zu werden.

Aber ich denke immer noch, dass dies ein sehr berechtigter Punkt war - wenn der Umfang von Gutenberg eine Editor-Komponente sein soll, dann scheint das Ersetzen des _screen_-Bereichs zu ehrgeizig. Wenn der Umfang von Gutenberg (zumindest teilweise) das Ersetzen von WordPress als Ganzes ist, ist es unglaublich breiter und anspruchsvoller. Nicht, dass es einfach wäre, den "gerechten" Editor zu ersetzen.

Es gibt jedoch mehrere Möglichkeiten, wie Meta-Boxen und Erweiterbarkeit behandelt werden können

Gutenberg soll die Hauptkomponente _editor_ ersetzen, und die vorhandene Administrator-Benutzeroberfläche funktioniert weiterhin nur? Wird dies in Betracht gezogen, wenn nicht warum?

Ich kann nur für das von mir erstellte Field Manager-Plugin sprechen, das wir derzeit in über 60 verschiedenen Projekten verwenden. Ich werde kurz erwähnen, was diese Änderung für sie zu bedeuten scheint, in der Hoffnung, dass dies jedem helfen kann, über sein eigenes Szenario nachzudenken.

Da ich mir die Mühe gemacht habe, eine stark entkoppelte Architektur mit gemeinsamen abstrakten Klassen und Schnittstellen zu erstellen, muss ich nur einen neuen "Speicherort" hinzufügen. Hier sind die Architekturkomponenten, die für meinen Punkt relevant sind:

• Standort: Hier wird die Feldgruppe angehängt (z. B. Beitrag, Seite, Taxonomiebegriff usw.) mit einer Variante für jeden Standort (z. B. Standort für Post und Einstellungen funktioniert mit Meta-Boxen). Diese Klasse instanziiert alle unten genannten beweglichen Teile
• Standortdatenspeicher: Die Ebene, die für das Abrufen und Speichern der Daten verantwortlich ist, mit einer Variante für jeden Standort (z. B. Post-DataStore arbeitet mit dem Post-Meta, Einstellungen funktionieren mit Optionen usw.)
• Standortansicht: Bei Bedarf ist es wie bei der Einstellungsseite eine Ansichtsklasse, die die Vorlage und alle Hilfsfunktionen enthält

Wenn ich nun im Kontext von Gutenberg diesen neuen Editor unterstützen möchte, muss ich persönlich nur einen neuen Speicherort namens Gutenberg hinzufügen. Dieser Speicherort hat:

• Eine eigene Initialisierungsmethode, die es mit dem Gutenberg-Editor verbindet. Ich kann mir vorstellen, dass dies hauptsächlich auf Javascript basiert, daher registriert und lädt meine Bibliothek die für diesen Zweck erforderlichen allgemeinen Skripte.

• Eigene Ansicht / Vorlage: Ich muss für jeden Feldtyp eine Reaktionskomponente erstellen. Dies ist keine große Sache, die Ansichtsebene ist ziemlich einfach zu erstellen, wenn alle anderen Teile richtig eingerichtet sind. Diese Komponenten werden dann in die Metabox-Reaktionskomponente verschachtelt. Dies alles ist sehr ähnlich zu dem, was ich bereits für die PHP-basierten Metaboxen HTML getan habe, dh Felder HTML> Feldgruppe HTML> Speicherort (Einstellungsseite HTML, Metabox usw.)

• Eigene Datenspeicherklasse. Ich kann mir nicht vorstellen, dass sich diese Klasse stark vom Post-Standort-Datenspeicher unterscheidet, da dies auf Post-Meta basiert (ich kann mir vorstellen, dass niemand daran denkt, Post-Meta bald zu verwerfen).

• Neues Stück: die Endpunkte. Diese neuen reaktionsbasierten Komponenten müssen in der Lage sein, mit dem Datenspeicher zu kommunizieren, um Werte abzurufen und beizubehalten. Da diese vollständig auf der Clientseite ausgeführt werden, benötigen sie Endpunkte als Brücke, um mit dem Standortdatenspeicher zu kommunizieren, und den Metaspeicher, um die Komponenten abzurufen, die in einem beliebigen Kontext geladen werden sollen usw.

Wenn mir nichts Wichtiges fehlt (ich gebe zu, ich hatte noch keine Zeit, Gutenberg auszuprobieren), ist dies mehr oder weniger der Kern dessen, was ich tun müsste, um diesen neuen "Standort" nativ zu unterstützen. Ich habe auch integrierte Überprüfungen für jeden Speicherort und seine Filter, um sicherzustellen, dass das, was der Entwickler verlangt, möglich ist, z. B. wenn ich versuche, einem Beitragstyp "Projekte" eine Feldgruppe hinzuzufügen, wobei das Format, wenn der Beitragstyp "Video" ist ", aber dass CPT keine Postformate unterstützt, wird die Bibliothek eine Ausnahme auslösen. Ich hoffe, dass ich mit diesem neuen Standort das gleiche Feedback geben kann, z. B. wenn ich einem Gutenberg-Standort, in dem der Beitragstyp "Bewertungen" lautet, eine Feldgruppe hinzufüge, hoffe ich, dass ich wissen kann, ob dieser Beitragstyp vorhanden ist wurde registriert, um Gutenberg zu unterstützen.

Das endete etwas länger als ich erwartet hatte, mein schlechtes. Ich würde gerne von jemandem hören, der an der Gutenberg-Entwicklung beteiligt ist, oder von einem Autor von Bibliotheken mit ähnlichen Bedenken, der Feedback hat, das er teilen kann.

Vielen Dank.

Gutenberg soll die Haupteditor-Komponente ersetzen und die vorhandene Admin-Benutzeroberfläche funktioniert weiterhin nur? Wird dies in Betracht gezogen, wenn nicht warum?

Gutenberg begann nur mit dem Editor. Das Kickoff-Ziel bestand darin, mehrere unterschiedliche Schnittstellen unter einer einzigen einheitlichen Blockschnittstelle zu vereinheitlichen. Es wurde schnell klar, dass wir den gesamten Schreibfluss einschließlich der Einstellungen und der Veröffentlichung berücksichtigen mussten, um ein überzeugendes Erlebnis rund um diese einheitliche Blockschnittstelle zu schaffen.

Wenn die Hauptstärke von WordPress darin besteht, jedem das Erstellen umfangreicher Beiträge zu erleichtern, können wir nicht nur für diejenigen von uns entwerfen, die bereits wissen, wie man den Editor verwendet. Wir müssen Benutzer berücksichtigen, die WordPress noch nie zuvor verwendet haben, und was sie von einer modernen Publishing-Oberfläche erwarten. Andernfalls würden wir einer bereits schweren Schnittstelle nur eine kognitive Belastung hinzufügen.

Wir sind noch nicht fertig und es ist nicht einfach, aber wir arbeiten jeden Tag daran.

☝️ Ich habe den Titel und die Beschreibung des Tickets aktualisiert, um hoffentlich einige Missverständnisse auszuräumen.

Der neue Gutenberg-Editor und die Zukunft von ButterBean

Wie im obigen Kommentar angefordert, liste ich das ButterBean-Meta-Box-Framework auf. Ich kann bei Bedarf ein neues Ticket erstellen.

Repo: https://github.com/justintadlock/butterbean/tree/dev

Zu Testzwecken ist das Framework in diesem Plugin enthalten: https://github.com/justintadlock/custom-content-portfolio

ButterBean ist ein Drop-In-Framework, das mit Backbone.js und Underscore.js erstellt wurde. Es ist stark vom Customizer in Core WP modelliert.

Es ist ein junges Framework, aber ich habe geplant, dieses Jahr mehrere Plugins zu verwenden. Im Moment zögern ich und andere, dies aufgrund der Richtung von Gutenberg zu tun. Und ich bin mir nicht einmal sicher, ob ich in React nicht einfach von vorne anfangen soll oder welches JS-Framework letztendlich als nächstes zum Kern-WP hinzugefügt werden soll.

Haken verwendet

Die folgenden primären WP-Kern-Hooks werden verwendet (ziemlich Standard für die meisten Meta-Box-Frameworks, wie ich mir vorstellen kann):

load-post.php
load-post-new.php 
add_meta_boxes
save_post 
admin_enqueue_scripts
admin_footer 
admin_print_footer_scripts

Erstellt # 2265, um relevante Hooks für CMB2 zu dokumentieren.

Design-Label hinzugefügt, um die Leute zu ermutigen, zusätzliche Modelle hinzuzufügen.

Im Allgemeinen bin ich der Meinung, dass Daten, die nicht Teil des angezeigten Inhalts sind, nicht Teil des Haupteditorbereichs sein sollten. Nicht alles ist ein Block.

1) Die meisten meiner benutzerdefinierten Meta-Boxen werden mit Fieldmanager . In meinen Augen sollten diese "Just Work" sein, ohne dass neben der Aktualisierung zusätzliche Arbeit für mich erforderlich ist. cc / @mboynes und @bcampeau, da sie möglicherweise in der Lage sind, dieser Diskussion einen Wert zu

2) Einige unserer benutzerdefinierten Meta-Boxen sind eine Mischung aus jQuery und PHP. Zum Beispiel haben wir eine Meta-Box "Eins oder keine", bei der es sich um ein Radio mit einer Schaltfläche "Löschen" handelt. Unter der Annahme, dass dies nicht funktioniert, würde ich erwarten, dass es Beispiele dafür gibt, wie ich dies in Gutenberg erstelle, und dass ich viel Zeit habe, um auf eine Version von WordPress zu aktualisieren, die Gutenberg vorschreibt, bevor mein Code kaputt geht.

3) Ich habe eine andere Metabox, die jQuery- und PHP-Code kombiniert, wodurch die Schaltfläche zum Veröffentlichen deaktiviert wird, bis eine Auswahl getroffen wurde. Ähnlich wie bei meinem zweiten Beispiel würde ich unter der Annahme, dass dies nicht funktioniert, erwarten, dass es Beispiele dafür gibt, wie ich dies in Gutenberg erstelle, und dass ich viel Zeit habe, um auf eine Version von WordPress zu aktualisieren, die Gutenberg vorschreibt Mein Code bricht.

4) Ich habe das Meta-Feld für Kategorien in der Vergangenheit entfernt und durch Folgendes ersetzt: 1) eine Radioauswahl 2) Eine Version ohne die Möglichkeit, neue Kategorien hinzuzufügen (dies war dumm).

5) Ich habe post_submitbox_misc_actions , um der Veröffentlichungs-Metabox Optionen hinzuzufügen, die sich nicht in ihrer eigenen Metabox befinden müssen.

Was ich mit einer erheblichen Zeitspanne meine, würde ich ~ 2 Jahre ab dem Zeitpunkt sagen, an dem die Gutenberg-API eingefroren ist.

Während wir gerade dabei sind, möchte ich alle hier daran erinnern, dass nicht jeder nur Metaboxen verwendet, um den Post-Bildschirm zu erweitern. Einige von uns verwenden auch die folgenden Haken:

• 'edit_form_top'
• 'edit_form_after_title'
• 'edit_form_before_permalink'
• 'edit_form_after_editor'
• 'edit_form_advanced'

Ich möchte nur dem zustimmen , was edit_form_[POSITION] Hooks gesagt hat. Piklist wird häufig für Meta-Boxen, Workflows und andere Dinge verwendet.

Nochmals vielen Dank für Ihre Zeit Jungs.

Die Frage, ob Gutenberg ein Editorersatz oder ein Bildschirmersatz ist, ist so schnell wie möglich zu beantworten, nicht nur für diejenigen, die sich mit Abwärtskompatibilität befassen, sondern auch für diejenigen, die Gutenberg entwickeln. Die Antwort auf diese Frage wirkt sich auf viele Entscheidungen aus, die täglich getroffen werden, wie Gutenberg funktioniert und wo sich die Kontrollen befinden.

Seit der ersten Beta ist klar, dass wir bereits auf dem besten Weg sind, den Bildschirm zu ersetzen, aber diese Entscheidung, den Bildschirm zu überarbeiten, hat auch zu Problemen mit der Unterstützung von Meta-Boxen und fehlenden Hooks geführt. Wenn die Antwort auf diese Probleme "nicht den gesamten Bildschirm ersetzen" lautet, mache ich mir Sorgen, dass unter der Annahme eines Bildschirmaustauschs bereits so viel Arbeit geleistet wurde, dass es schwierig wäre, zurück zu gehen.

Erstens ist es großartig, echte Fortschritte zu sehen.

Eine Beobachtung ist, dass Bearbeitungsbildschirmerweiterungen selten isoliert funktionieren. Beispielsweise ändert ACF die sichtbaren Felder basierend auf JS-Änderungsereignissen im übergeordneten Auswahlfeld.

Wie können wir diese Daten weiterhin Metaboxen und anderem Plugin-Code zur Verfügung stellen, da das DOM in einem Gutenburg-Kontext anders sein wird und React wahrscheinlich weniger für externe Ereignis-Listener geeignet ist? Eine Möglichkeit besteht darin, dass der Redux-Store Metaboxen zur Verfügung gestellt wird, aber ich weiß nicht, ob dies möglich, erwünscht oder ausreichend flexibel ist.

Dies wird noch problematischer, wenn Metaboxen in einen Iframe geladen oder in die Seite eingefügt werden.

Seit der ersten Beta ist klar, dass wir bereits auf dem besten Weg sind, den Bildschirm zu ersetzen, aber diese Entscheidung, den Bildschirm zu überarbeiten, hat auch zu Problemen mit der Unterstützung von Meta-Boxen und fehlenden Hooks geführt. Wenn die Antwort auf diese Probleme "nicht den gesamten Bildschirm ersetzen" lautet, mache ich mir Sorgen, dass unter der Annahme eines Bildschirmaustauschs bereits so viel Arbeit geleistet wurde, dass es schwierig wäre, zurück zu gehen.

Ich verstehe vollkommen, wie viel Arbeit in Richtung des "Bildschirm" -Austauschansatzes geleistet wurde. Aber ein Projekt, das mit dem Ziel eines "Post Content Editor" -Ersatzes begann, hätte nicht in die Community zurückkehren sollen, bevor einseitig entschieden wurde, dass es den gesamten Editor-Bildschirm ersetzen würde?

Ich möchte die große Arbeit, die geleistet wurde, nicht ablehnen (der Editor sieht wirklich fantastisch aus), aber zu viel WordPress basiert auf Metafeldern, die nicht ausschließlich "Inhalt" sind, und viele davon passen überhaupt nicht in die gleicher Gutenberg-Container (sofern er nicht vollständig gezwungen wird). Für mich scheint es eher "wir haben eine Lösung und müssen ein Problem dafür schaffen" als umgekehrt, wie es die ursprüngliche Aussage von Gutenberg lautete (der Post-Content-Editor ist ziemlich chaotisch, Shortcodes sind alles andere als benutzerfreundlich - trotz Ansätzen wie Shortcake -, etc).

Das @ brentjett-Modell vom 4. Juli scheint sowohl für "überarbeitete Metaboxen", die nicht in den Inhalt passen ("Einstellungsbereich"), als auch für Meta-Boxen, die leicht in einen Gutenberg-Block konvertiert werden können (Ereignisinformationen), geeignet zu sein.

@rilwis Ich denke, Sie sollten

Als Inspiration für das Design können Sie kostenlose und kommerzielle (Screenshots) Backend-Admin-Themen überprüfen. Oder irgendeine andere Plattform.

Dashboard, aber stell dir Gutenberg vor:

Möglicherweise löst die vorgeschlagene Fields-API einige Probleme bei der Unterstützung von Metaboxen im neuen Editor

Das Szenario, das wir in Betracht ziehen sollten, ist, was passiert, wenn WordPress mit Gutenberg aktualisiert wird und die Plugins, die die Meta-Boxen implementiert haben, nicht .

Dies ist das "Worst-Case-Szenario", das die größte Gefahr für die Beeinträchtigung der Administratorerfahrung darstellt. Angesichts der Anzahl der Websites, die mit Meta-Box-Plugins betrieben werden, einschließlich der bekannten Player und der benutzerdefinierten einmaligen Lösungen, ist dies jedoch keine Seltenheit.

Sich auf diese zu aktualisierenden Meta-Box-Plugins zu verlassen, sollte nicht Teil der Gleichung sein, es sei denn, wir sind bereit, umfangreiche Änderungen zu berücksichtigen. Die Fields-API ist eine großartige Idee, aber wir sollten nicht davon ausgehen, dass eine Verbesserung der Art und Weise, wie benutzerdefinierte Felder in Zukunft behandelt werden, Auswirkungen auf Code hat, der geschrieben wurde, bevor eine solche API vorhanden war.

Es ist klar, dass:

• Wir werden die Abwärtskompatibilität in keinem großen Maßstab brechen.
• Wir werden die Editorseite nicht mit einem Erkennungsmechanismus aufteilen.
• Wir werden einen einzigen Editor und Bearbeitungserfahrung haben.
• Es gibt viele Anwendungsfälle, die die aktuelle Gutenberg-Implementierung nicht berücksichtigen kann.

Deshalb:

Der Weg nach vorne besteht darin, den Bildschirm für die Nachbearbeitung so zu überdenken, dass das Neue und das Alte berücksichtigt werden. Dies bedeutet sehr wahrscheinlich, dass die aktuelle Gutenberg-Implementierung in irgendeiner Weise zurückverfolgt wird. Es ist eine Designherausforderung, nicht das Ende der Welt.

@dmccan Nein, diese Aussagen sind nicht "klar", da jede Lösung bisher vorgeschlagen wurde:

• Teilt die Administratorerfahrung zwischen neu / alt auf.
• Verlässt sich auf Plugin-Updates, um ihre Meta-Boxen zu blockieren.
• Verlässt sich auf eine nicht vorhandene Fields-API.
• Erfordert die Abmeldung der neuen Benutzeroberfläche, um das Problem insgesamt zu vermeiden, wodurch die Administratorerfahrung erneut aufgeteilt wird.

Ich habe das Worst-Case-Szenario nicht als melodramatisch hervorgehoben. Ich habe es getan, um die Einschränkungen zu definieren, innerhalb derer wir uns dem Problem nähern sollten.

Es scheint also, dass Gutenberg wahrscheinlich für lange Zeit ein Feature-Plugin bleiben sollte, das die Leute auswählen können, ob sie möchten, oder ob sie sich abmelden möchten, wenn nicht, möglicherweise sogar als Plugin mit Core.

Das Lösen aller Probleme, die gelöst werden müssen, um eine einzige Editorerfahrung zu erzielen, nimmt viel Kalenderzeit in Anspruch. Schauen Sie sich einfach das ursprüngliche ASP.NET von Microsoft an und wie schlecht es das allgemeine Webproblem gelöst hat. Schließlich tauchte AJAX auf und der Rest ist Geschichte.

Eine zu schnelle Änderung kann dazu führen, dass WordPress zu einer echten Nur-Legacy-Plattform wird.

PS Die Anforderung "Einzeleditor" scheint unrealistisch zu sein. Wenn die Benutzer die Möglichkeit hätten, das Alte oder das Neue zu verwenden, könnte sich das Neue im Laufe der Zeit weiterentwickeln, bis es keinen Vorteil mehr gibt, das Alte zu verwenden. Aber solange es Installationen gibt, die die vorhandenen Hooks verwenden (glaube ich), ist es unverantwortlich, sich für eine einzelne Editorlösung zu entscheiden. #jmtcw

@kevinwhoffman - Ich denke, wir sind uns einig, aber vielleicht war ich nicht ausführlich genug.

Ich denke, meine Stichpunkte sind klar und die endgültige Lösung wird sie umfassen. Zum Beispiel glaube ich nicht, dass WordPress die Abwärtskompatibilität in großem Maßstab beeinträchtigen wird, ungeachtet dessen, was Leute, die nach Lösungen suchen, an dieser Stelle vorschlagen könnten.

Die bisher vorgeschlagenen Lösungen fehlen, und hier kommt meine Schlussfolgerung, dass wir die aktuelle Gutenberg-Implementierung überdenken müssen, um sowohl neue als auch alte zu berücksichtigen. Ich denke, dass dies wirklich der einzige Weg nach vorne ist.

@mikeschinkel - Ich kann mir nicht vorstellen, dass Gutenberg 2017 die einzige

Auf jeden Fall schlage ich einen Backtrack vor, um Gutenberg in eine aktualisierte Version des aktuellen Editor-Bildschirms zu integrieren, anstatt alles wegzuwerfen und sich dann zu fragen, wie wir mit allen wesentlichen Funktionen umgehen könnten. Ich denke, das ist machbar und möglicherweise kein so großer Rückschritt, wenn sich die Leute damit abfinden. Ein solcher Kurs wäre wahrscheinlich schneller und bietet eine bessere Endbenutzererfahrung.

Vielleicht sollten sie (Kerncodierer) mit dem Matt sprechen. Er hat das alles angefangen und sie haben jetzt keine Antworten.

@dmccan Eine Sache, von der ich glaube, dass sie von entscheidender Bedeutung sein wird, ist, dass alles, was implementiert wird, ein einfaches Erweiterbarkeitsmodell hat. WordPress ist bekannt für sein einfaches Erweiterungsmodell mit Plugin-Aktion und Filter-Hooks. Ohne dieses wird Gutenberg für WordPress genauso schlecht sein wie das derzeitige Medienverwaltungssystem, das sehr schwer zu erweitern ist.

Nebenbei bemerkt, obwohl ich React oder Vue noch nie verwendet habe (ich bin ein PHP-Entwickler), hat mich die Diskussion über React, die ein Build-System erfordert und dass viele Leute Vue als viel einfacher zu verwenden empfanden als React, sehr besorgt gemacht ob Gutenburg ein leicht zu erlernendes und zu verwendendes Erweiterungsmodell haben wird oder nicht, und ob dies bedeutet, dass wir WordPress weiterhin für Client-Projekte verwenden können.

Nur mein Feedback, um mein Anliegen zur Kenntnis zu nehmen, keine Notwendigkeit, direkt darauf zu antworten.

Ich glaube zu wissen, worum es geht.
Es ging nie um Content Editor, nie um "Schreibfluss", "Brechen mit alten ... rückwärts" usw.

Es geht um einen vollblütigen visuellen Front-End-Themeneditor.

Entschuldigen Sie, dass Sie alle E-Mails gesendet haben. Mein letzter Kommentar zu diesem speziellen Thema.

@Rarst @kevinwhoffman : Ich bin total mit Ihnen darüber, ob Gutenberg ein Editor- Ersatz oder ein Bildschirm- Ersatz ist oder nicht. Es ist ein gut durchdachter Punkt. Und ich hoffe, das Entwicklerteam kann zum Ausgangspunkt und zur Natur von Gutenberg - einem Redakteur - zurückkehren und alles andere so lassen, wie es jetzt ist. Sie sind 2 verschiedene Teile und können mit oder ohne einander verwendet werden. Es ist also besser, sie als getrennte Dinge zu behalten.

Außerdem habe ich # 2308 erstellt, um die relevanten Hooks des Meta Box-Plugins aufzulisten.

@ahmadawais Danke für die Erwähnung.

@nylen Es lohnt sich, Posts 2 Posts zur Liste der zu berücksichtigenden Plugins hinzuzufügen. Obwohl es nicht mehr unterstützt wird, gehe ich davon aus, dass es immer noch weit verbreitet ist.

@nylen Ich die benutzerdefinierten Felder meines Plugins-

Ich bin damit einverstanden, dass die Kommentare zu Gutenberg Editor genau das sind, der Teil zur Bearbeitung von Inhalten. Ich bin mir nicht sicher, warum oder wie es zu einem vollständigen Bildschirmersatz abgelenkt wurde. Alle gängigen Seitenersteller machen es richtig. Ersetzen Sie TinyMCE einfach durch etwas anderes, das das Erstellen von Inhalten erleichtert.

Außerdem sind Meta-Boxen normalerweise nicht Teil des Inhalts, und selbst wenn sie inhaltsbezogen sind, machen sie normalerweise keinen Sinn, ein Block zu sein.

Nehmen Sie zum Beispiel ein Personalverzeichnis. Warum sollte ich wollen, dass die Felder für die Personeninformationen ein Block sind? Es ist nicht so, dass Sie möchten, dass sie andere Blöcke hinzufügen, wenn sie nur Vorname, Nachname usw. eingeben sollen.

tldr; Gutenberg sollte den TinyMCE-Editor nur für Beitragstypen ersetzen, die eine Inhaltszusammensetzung benötigen.

Ich füge hier nur meine zwei Cent hinzu.

Warum nicht einfach so lassen, wie es jetzt ist? Was ich meine ist das.

• Behalten Sie die beiden Bearbeitungsoptionen bei, wenn Sie den Mauszeiger über den Post-Titel bewegen, wie er jetzt ist. Ändern Sie ihn jedoch so, dass Sie standardmäßig durch Klicken auf den Titel zu Gutenberg gelangen. Lassen Sie dann den Link Edit zu Gutenberg und einen zusätzlichen Link zum Bearbeitungsbildschirm für Klassen. Nennen wir es vielleicht so etwas wie Classic Edit .
• Fügen Sie eine Art Support-Flag für den Post- und Page-Post-Typ hinzu, damit Gutenberg deaktiviert werden kann, wenn ein Entwickler dies möchte. Wenn Gutenberg nicht aktiviert ist, muss der Titellink zur "klassischen" Bearbeitungsseite wechseln. Entfernen Sie den Link Edit zu Gutenberg, und der Text des Links Classic Edit in Edit geändert
• Bei benutzerdefinierten Beitragstypen wird Gutenberg unterstützt, z. B. für den Editor, das ausgewählte Bild usw. Auf diese Weise muss ein CPT Gutenberg nicht unterstützen.
• Aktualisieren Sie dann das Design der klassischen Bearbeitungsseiten. Die Meta-Boxen und die Seitenleisten-Stile wurden aktualisiert, um sie an das Gutenberg-Design anzupassen. Verschieben Sie sogar die Meta-Boxen für Auszüge und Kommentare wie in Gutenberg in die Seitenleisten.

Ich denke, das würde alle glücklich machen. Gutenberg ist standardmäßig für die Post- und Page-Posts-Typen aktiviert. Wenn Entwickler Meta-Boxen anstelle von Gutengerg verwenden müssen, können sie dies. Es würde Plugins und Theme-Entwicklern Zeit geben, auf Gutenberg umzusteigen, und es würde Endbenutzern die Möglichkeit geben, sich an Gutenberg anzupassen, ohne ihren Workflow durch die Änderung des Editors zu beeinträchtigen.

Und es wird Entwicklern die Zeit geben, die Idee der Verwendung von Gutenberg an die Endbenutzer zu verkaufen. Menschen neigen dazu, Veränderungen nicht zu mögen. Es wäre viel besser, sie sich an den neuen Editor gewöhnen zu lassen, als nur eine harte Veränderung.

Dies würde auch die beiden trennen, was die zwei unterschiedlichen Speichermethoden ermöglichen würde. Gutenberg kann JS verwenden und classic kann weiterhin PHP verwenden.

Ich würde eine Art Warnung hinzufügen, z. B. wenn ein Benutzer einen Beitrag mit Gutenberg gespeichert und dann versucht hat, ihn mit classic zu bearbeiten, um ihn wissen zu lassen, dass beim Speichern des Beitrags der vorherige Speicher des Beitrags aus dem anderen Editor überschrieben wird. Es könnte so etwas wie ein Post-Meta geben, das angibt, welcher Editor zuletzt verwendet wurde.

Es ist eine Idee. Es mag eine dumme Idee sein, aber ich denke, sie würde alle Bedenken lindern, die viele Entwickler haben.

Ich stimme voll und ganz den Punkten zu, die viele Menschen heute zum Umfang von Gutenberg angesprochen haben. Dieses Projekt begann zunächst als (dringend benötigte) Verbesserung des Inhaltseditors. Wenn ich diesen Thread durchlese, kann ich nicht anders, als das Gefühl zu haben, dass wir Probleme schaffen, die nicht existieren müssen . Wenn wir uns an den ursprünglichen Plan halten, Gutenberg zum Editor hinzuzufügen (ohne den Vollbildmodus zu ersetzen), werden so viele Probleme gelöst, nicht nur in Bezug auf Meta-Boxen.

Ich befürchte, dass durch die vollständige Überarbeitung des Bildschirms so viele Probleme für nicht-technische Inhaltseditoren entstehen werden. Der durchschnittliche Blogger / Autor wird einen völlig anderen Bildschirm und eine andere Panik sehen. Wenn das Update nur auf den Editor abzielt, kann das Onboarding-Erlebnis wesentlich besser gesteuert werden.

Eine andere Möglichkeit, dies zu erreichen, besteht darin, denselben Workflow wie Beaver Builder zu verwenden . Das heißt, Sie behalten die normale Post-Edit-Seite (mit den üblichen Meta-Box-Abschnitten usw.) bei, dann kann Gutenberg über eine Schaltfläche gestartet werden. Dies kann Sie dann zu einem neuen Bildschirm führen. Ähnlich wie die Kommentare zum Targeting des Ablenkungsfreien Schreibmodus.

Ich stimme auch Leuten zu, die vorschlagen, die vorhandene Meta-Box-Benutzeroberfläche beizubehalten und nur den Inhaltseditor zu ändern.

Ich denke, die meisten von uns erkennen, dass der wichtigste Faktor für die Weiterentwicklung einer Plattform die Innovation ist. Es ist offensichtlich, dass WordPress langsam versucht, einen JS-basierten Ansatz zu entwickeln, um umfassendere Erfahrungen zu erzielen, die mit denen aller anderen übereinstimmen (und diese übertreffen!). Wenn wir ehrlich sind, können sich das gesamte Metabox-System und die aktuelle Benutzeroberfläche des Bearbeitungsbildschirms etwas veraltet anfühlen, aber als Entwickler sind wir so daran gewöhnt, dass es für uns selbstverständlich ist und wir nicht berücksichtigen, wie viel Lernkurve dort vorhanden ist ist dazu.

Das Lesen dieses gesamten Threads verdeutlicht zwei Dinge für mich:

• Es ist offensichtlich, dass das Kernteam auf einen vollständig js-basierten Bearbeitungsbildschirm drängen möchte, und imho, das ist in Ordnung
• Wenn wir alle den oben genannten Punkt akzeptieren können, können wir das Gespräch möglicherweise auf die bisherigen Unterstützungs- und Migrationsstrategien ausrichten

Sobald wir verstehen, wie die js-Version der Metaboxen irgendwann funktionieren wird (gibt es eine vorgeschlagene API?), Können wir darüber nachdenken, wie wir eine Brücke schaffen können, die unsere vorhandene Technologie (Plugins, Feldmanager usw.) macht. arbeite mit diesem neuen Ansatz.

Wenn bereits eine API-bezogene Diskussion stattfindet, könnte jemand mich und andere Personen, die nicht wissen, wo dies geschieht, in die richtige Richtung weisen? Vielen Dank!

Gibt es einen Grund, den Editor nicht in zwei Bildschirme aufzuteilen, die durch Registerkarten navigiert werden?

Meiner Ansicht nach ist Gutenberg,

• Ein Versuch, den Editorbildschirm aufzuräumen
• Ein Versuch, dem Kern Seitenerstellungs- / Layoutfunktionen hinzuzufügen
• Ein Versuch, den Bedarf an Metaboxen zu minimieren, indem Entwicklern das Erstellen neuer Inhaltsblöcke erleichtert wird.

Die Probleme, wie oben hervorgehoben und wie die meisten von uns Entwicklern und Endbenutzern fühlen und vorhersehen können, sind, dass Gutenberg,

• Entfernt die Formatauswahl im Editorstil von den Autoren
• Zwingt Autoren, einen nicht intuitiven Workflow zu verwenden, der viele Mausklicks erfordert, um Blöcke hinzuzufügen
• Bricht viele ältere Plugins, von denen einige beibehalten werden und andere nicht.
• Konvertiert WordPress in eine Tweet-Plattform.

Die Verwendung von Guttenberg zum Erstellen von Inhalten ist genauso umständlich wie das Entwerfen einer E-Mail-Vorlage in Mautic oder MailChimp. Die Benutzeroberfläche von Guttenberg eignet sich gut für das Template-Design, jedoch nicht für die Erstellung von Langform-Posts.

Wir sollten uns auf die Erhöhung der Fluidität des Workflows konzentrieren und nicht auf die Einführung einer Stop-Start-Benutzeroberfläche für die Erstellung von Inhalten.

Die Benutzeroberfläche für Guttenberg sieht gut aus, aber es ist unrealistisch zu erwarten, dass Endbenutzer damit zufrieden sind, während sie sich in der Nähe ihrer aktuellen Form befindet. Es behindert die Erstellung von Inhalten.

Der Textblock ist so gut wie unbrauchbar. Ein Text-Widget sollte Autoren nicht auf die Verwendung weniger Schriftformate beschränken. Dies wird viele Autoren ärgern.

Hier sind meine Vorschläge:

• Führen Sie Tabify Edit Screens in den
• Verschieben Sie Metaboxen in eine eigene Seitenregisterkarte im Editorbildschirm.
• Verwenden Sie eine nicht reaktionsbasierte Seite für die Metaboxen (Seite versteckt hinter einer Editor-Registerkarte)
• Verwenden Sie eine standardmäßige TinyMCE-basierte Leinwand (oder einen ähnlich funktionsreichen Editor), die für Langform gut geeignet ist und nicht darauf besteht, dass Autoren Blöcke verwenden.
• Führen Sie Guttenberg Blocks als Addon zu TinyMCE oder dem TinyMCE-Lookalike ein.
• Führen Sie Shortcake in den TinyMCE-basierten Editor ein, sodass Autoren den Inhalt von Blöcken visuell sehen und Autoren Inhalte direkt im Seitenfluss bearbeiten können, ohne auf eine Bearbeitungsschaltfläche für jeden Block klicken zu müssen.
• Machen Sie es Entwicklern einfach, Guttenberg neue Blöcke hinzuzufügen, indem Sie add_shortcode () in die Blockerstellung einbinden, z. B. add_shortcode ('tag', 'function', 'guttenberg true / false'). Passen Sie add_shortcode so an, dass der Shortcode automatisch mit Guttenberg kompatibel ist. Auf diese Weise können Entwickler einige / viele ihrer Metaboxen problemlos in Shortcodes konvertieren, die in Guttenberg funktionieren.

Was ich wirklich sage ist, dass Guttenberg in drei Aufgaben unterteilt werden muss:

• Editor Bildschirm bereinigen
• Verbesserte Editor-Benutzeroberfläche
• Verbessertes Editor-Erweiterungs-Framework.

Ich würde sagen, die meisten Leute verwenden WordPress, um Inhalte in Langform zu erstellen, und möchten nicht gezwungen werden, Blöcke zu verwenden, um ihre Inhalte zu erstellen. Blöcke eignen sich hervorragend zum Erstellen von Seitenlayouts, sind jedoch ärgerlich, wenn sie jedes Mal verwendet werden, wenn ein Beitrag geschrieben wird.

Ich habe eine Kundin, die in den 80ern ist. Sie möchte nur Inhalte erstellen. Sie möchte nicht gezwungen werden, den Umgang mit dem Editor-Bildschirm neu zu lernen. Es hat über ein Jahr gedauert, bis sie sich an Visual Composer gewöhnt hat, und das ist ein einfach zu verwendender Seitenersteller.

Ich bin vom ursprünglichen Thread-Thema abgewichen, aber das muss gesagt werden: Guttenberg wird WordPress töten.

Wenn Guttenberg in seiner aktuellen Form eingeführt wird, wird WordPress gegabelt und die Guttenberg-Version stirbt.

Vielleicht ist der neue Editor sinnvoller, wenn Sie WordPress für eine Blogging-Site verwenden und ein PHP-Thema dafür erstellen, aber heutzutage verwenden viele Leute WordPress als CMS zum Erstellen von Webanwendungen mit React, PODS / ACF und der WordPress REST-API. Daher müssen Metaboxen und Beziehungsfelder für eine erweiterte Verknüpfung zwischen CPTs unterstützt werden.

Zunächst einmal denke ich, dass Gutenberg großartig sein wird.

Abgesehen davon denke ich, dass wir uns alle einig sein können, dass das Brechen von Websites / Funktionen das Vertrauen bricht, und das ist nicht cool. Wir alle wollen uns gegenseitig vertrauen können und unsere Kunden wollen / müssen uns vertrauen.

Ich denke, das Beste, was wir tun können, ist, einen Filter einzuschließen, mit dem Entwickler zum "Legacy" -Editor zurückkehren können.

Auf diese Weise können wir unsere eigene Logik anwenden, um festzustellen, ob wir für Gutenberg bereit sind oder nicht. Wenn ein Benutzer eine Meta-Box verwendet, die in Gutenberg vollständig beschädigt wird, können wir in den Legacy-Modus zurückkehren.

Dann können wir in unserem eigenen Tempo daran arbeiten, unsere Meta-Boxen oder Ideen so zu migrieren, dass sie zu Gutenberg passen, während alte Posts, die von unseren "Legacy" -Meta-Boxen abhängen, ordnungsgemäß funktionieren.

Warum können die Legacy-Metaboxen nicht an den Orten (im Kontext) gerendert werden, für die sie registriert sind, und funktionieren weiterhin wie bisher?

Rendern Sie also zuerst den (optionalen) Gutenberg-Editor, gefolgt von einem registrierten (Legacy-) Meta-Feld für normalen / erweiterten Kontext (mit dem registrierten Titel), dann die Seitenleiste mit der neuen Spalte "Post-Einstellungen" und darunter jede registrierte (Legacy-) Seite Kontext-Meta-Box (mit dem registrierten Titel).

Natürlich würde die Legacy-Meta-Box genauso gestaltet sein wie die neue Post-Einstellungen-Box. Alles würde gut integriert aussehen.

Möglicherweise würde es ein Legacy-Meta-Box.php-Skript erfordern, das bei Bedarf geladen wird, z. B. wenn add_meta_box aufgerufen wird.

Wenn wir aktuelle Meta-Box-Lösungen immer nur als "Legacy" betrachten und von ihnen verlangen, dass sie den alten Editor verwenden, ohne jemals über die Gründe nachzudenken, warum sie überhaupt verwendet werden, und dann an besseren Möglichkeiten arbeiten, diese Funktionalität im neuen Editor bereitzustellen Aktuelle Websites bleiben nur erhalten und werden niemals aktualisiert. Dies ist ein großes Problem für Benutzer, die Client-Sites verwalten.

Der Grund, warum wir in fast allen unseren Projekten ACF-Felder verwenden, besteht darin, die Daten so zu steuern, dass sie auf der Website konsistent angezeigt werden. Hier sind zwei Beispiele, an denen wir gerade arbeiten. Ein großer Veranstaltungsort und ein Festival mit Werken / Installationen, die mit Künstlern verknüpft, aber separat angezeigt werden müssen. In beiden Fällen macht der "Inhalt", das Stück, das Gutenberg ersetzt, nur etwa 10% des Inhalts auf dem Bearbeitungsbildschirm aus und ist tatsächlich das am wenigsten wichtige Stück. Für die Veranstaltungsseite sind die wichtigen Daten Ereignistyp, Ereigniskategorie, Datum, Uhrzeit, Ort, Organisator usw. Sie können einen aussagekräftigen Ereigniseintrag veröffentlichen, ohne Inhalte in den Editor eingeben zu müssen. Für das Festivalgelände müssen wir in der Lage sein, einen Künstler auszuwählen und mit einem Werk zu verknüpfen, den Arbeitsort auf dem Festivalgelände auszuwählen und ein ausgewähltes Bild hochzuladen. Auch hier ist der Inhalt ein Extra, keine Notwendigkeit. Bei all dem "normalen" Seiteninhalt auf diesen Websites ist Gutenberg nicht flexibel genug (und sollte es auch nicht standardmäßig sein, glaube ich nicht), und wir würden weiterhin einen umfassenderen Seitenersteller (Beaver Builder) zum Besseren verwenden Gestaltungsmöglichkeiten.

Der andere Schlüsselfaktor bei all dem ist die Reihenfolge des Inhalts auf dem Bearbeitungsbildschirm. Für ein Ereignis müssen Sie einen Titel festlegen, aber dann möchten Sie in einem idealen Bearbeitungsablauf einige der wichtigsten Informationen wie Datum, Uhrzeit usw. eingeben, bevor Sie einen "Inhalt" in den "Editor" eingeben. Wir müssen die Möglichkeit haben zu steuern, wo sich der Inhalt auf der Bearbeitungsseite vor oder nach dem "Inhalt" befindet.

Die Idee, nur einen weiteren Tab mit allen "Legacy" -Metaboxen zu erstellen, wäre schrecklich. Es würde den Bearbeitungsfluss für viele CPT-Anwendungen vollständig unterbrechen und den Inhalt vor den Benutzern auf eine Weise verbergen, die meiner Meinung nach sehr schwer zu entdecken wäre.

Das Projekt muss viel schlauer sein. Ein Prozess mit Registerkarten könnte großartig funktionieren, wenn Sie (in einer Art Seitenvorlage) auswählen könnten, welche Bits sich auf welcher Registerkarte befinden. Sie benötigen außerdem einen Mechanismus, mit dem Sie den Benutzer durch die einzelnen Registerkarten führen können. Ich glaube jedoch auch, dass Sie für kürzere CPT-Elemente die Möglichkeit haben MÜSSEN, alles auf einer Seite mit bestimmten Schlüsselelementen über dem Editorinhalt zu halten (erforderliche Blöcke, wenn Sie so wollen).

Alles in allem scheinen die meisten Lösungen, über die gesprochen wird, nicht die Flexibilität des aktuellen Bearbeitungsbildschirms zu haben.

Aus diesem Grund habe ich Angst vor der Zeitachse von 5.0. Es scheint, als könnte sie rechtzeitig großartig sein, aber wenn sie überstürzt wird, wird die Fragmentierung allen guten Willen sowohl von Entwicklern als auch von Kunden zerstören. WordPress setzt auf Flexibilität, Abwärtskompatibilität und allgemeine Benutzerfreundlichkeit. Wir können das nicht für das neue glänzende Spielzeug opfern. Schauen Sie sich die PHP-Anforderungen für WordPress an, wir sprechen buchstäblich Jahre bevor PHP 5.6 oder 7 eine Anforderung sein wird. Die Community hat erkannt, dass es notwendig ist, Websites nicht zu beschädigen, egal wie frustrierend dieser lange Zeitraum ist. Ist das nicht genau das gleiche Problem?

Änderungen wie diese, die letztendlich für die Plattform großartig sind, müssen gut durchdacht und verwaltet werden, da sie sonst das Fundament riskieren, auf dem WordPress basiert.

@avocadesign - Einige gute Punkte. Wir werden in Zukunft in der Lage sein, JavaScript-Meta-Boxen zu registrieren, obwohl es derzeit so aussieht, als ob zwei Standorte vorhanden sind ... was nicht so flexibel ist, wie Sie es erwähnt haben.

@avocadesign - gut erklärt. Der post_content steht nicht immer im Mittelpunkt eines Posts und Ihre 'Events & Künstler' sind ein gutes Beispiel. Es wäre großartig, einige Screenshots zu sehen, die das Back-End und das Front-End dieser Beitragstypen zeigen, damit wir Entwicklern helfen können, zu visualisieren, wie WP als CMS verwendet wird und wie ein typischer Client über einen Beitragsbearbeitungsbildschirm funktioniert.

@avocadesign

Wenn wir aktuelle Meta-Box-Lösungen immer nur als "Legacy" betrachten und von ihnen verlangen, dass sie den alten Editor verwenden

In dem, was ich vorgeschlagen habe (über Ihrem Kommentar), werden die "Legacy" -Metaboxen entweder unter dem Gutenberg-Editor (falls der Beitragstyp dies erfordert) oder unter dem Block "Post-Einstellungen" (je nach Kontext, für den sie registriert sind) positioniert. Ich sehe keine Anforderung, den alten Editor beizubehalten.

Ich bin damit einverstanden, dass eine Oberfläche mit Registerkarten nicht funktioniert. Was denkst du über meinen Vorschlag? Aus meiner Sicht würde es Ihnen die gewohnte Flexibilität geben und es Ihnen ermöglichen, auf das neue System umzusteigen, wenn Sie bereit sind.

Wenn Gutenberg Teil des Kerns werden würde, könnten Sie eine noch bessere Benutzeroberfläche für die von Ihnen erwähnten Beispiele erstellen. Es würde teilweise aus einem benutzerdefinierten Festivalblock (eine Art WYSIWYG-Formular) und zugehörigen Einstellungen in einem oder mehreren (JS-basierten) Abschnitten mit Post-Einstellungen bestehen. Der Benutzer würde von einer schnelleren Schnittstelle mit direktem Feedback profitieren.

WordPress setzt auf Flexibilität, Abwärtskompatibilität und allgemeine Benutzerfreundlichkeit. Wir können das nicht für das neue glänzende Spielzeug opfern.

Ich stimme dir nicht zu. Ich denke, Sie sollten dem Gutenberg etwas mehr Ehre machen. Sie arbeiten hart an einer Lösung, die für alle funktioniert. Sie hören zu und suchen nach Anwendungsfällen (genau wie der, den Sie erwähnen). Noch ist nichts in Stein gemeißelt, noch ist die Veröffentlichung von Gutenberg ein Teil davon.
Wenn Gutenberg nicht alle derzeit diskutierten Probleme behebt, können Sie darauf vertrauen, dass es nicht Teil der Version 5.0 ist. Wir haben gesehen, dass dies in der Vergangenheit auch bei anderen Funktionen mehrfach vorgekommen ist.

Hier ist ein Beispiel für eine Schnittstelle, die ich mit erweiterten benutzerdefinierten Feldern für einen Kunden erstellt habe, der Hotelimmobilien verwaltet.

• Der benutzerdefinierte Beitragstyp "Eigenschaft" verwendet 18 benutzerdefinierte Felder auf 10 Registerkarten.
• Auf den Registerkarten werden alle relevanten Informationen auf einem Bildschirm angezeigt und sind für den Editor per Knopfdruck zugänglich.
• Zu den Feldtypen gehören neben ACF-Galerien und Beziehungsfeldern auch einfache Text- und Zahlenfelder.
• Die Unterstützung für editor wurde in der Registrierung für benutzerdefinierte Beitragstypen nicht deklariert. Dies bedeutet, dass die gesamte Benutzeroberfläche auf benutzerdefinierten Meta-Boxen basiert.

Diese Art der Benutzeroberfläche steht stellvertretend für viele benutzerdefinierte WordPress-Websites, auf denen eine Reihe von benutzerdefinierten Feldern eine Mischung aus On-Page-Inhalten und "unsichtbaren" Metadaten enthält, die zum Organisieren von Posts verwendet werden.

Die Community muss wissen, was mit dieser Art von Schnittstelle passiert, wenn Gutenberg eingeführt wird, und ich denke nicht, dass es eine realistische Erwartung ist, @elliotcondon zu bitten, alles rechtzeitig vor dem Start auf React zu migrieren.

@ Kevinwhoffman

Die Community muss wissen, was mit dieser Art von Schnittstelle passiert, wenn Gutenberg eingeführt wird

Sie haben Recht, aber das Ziel dieser Ausgabe Nr. 952 ist es, diese Antwort zu finden, indem Sie Alternativen diskutieren und vorschlagen. Was würde was nicht funktionieren. Irgendwann in der Zukunft, wenn jeder denkt, dass wir alle zu etwas gekommen sind, das in allen Legacy- und zukünftigen Fällen funktionieren würde, kann es nur dann implementiert werden und der (Benutzer-) Community kann erklärt werden, wie es funktionieren wird. Derzeit ist es einfach zu früh, um eine Antwort des Teams auf diese Frage zu erwarten.

Ich denke, der von Ihnen bereitgestellte Anwendungsfall und der von

In Bezug auf Ihr Beispiel würde mein Vorschlag (siehe einige Reaktionen oben) einfach alle Kästchen anzeigen, wie im Screenshot gezeigt (natürlich mit dem neuen Gutenberg-Stil).

@ Kevinwhoffman

Gutenberg wird sich höchstwahrscheinlich für CPTs entscheiden, ähnlich wie Ihr CPT die Unterstützung für den aktuellen Editor nicht deklariert. Ich verstehe nicht, warum es jemals nicht für CPTs entschieden werden würde, da die meisten Dinge in WordPress extrem flexibel sind und Gutenberg nicht anders sein wird. Es funktioniert derzeit nur für Beiträge.

Ich bezweifle sehr, dass Gutenberg an einer solchen Schnittstelle überhaupt etwas ändern würde, und es ist auch nicht beabsichtigt, dies zu tun. Abgesehen davon könnte es interessant sein, die Angebote von Gutenberg zu erkunden und zu prüfen, ob Sie mit dieser Funktion ein überzeugenderes Bearbeitungserlebnis für Ihren Kunden schaffen können.

Sie können beispielsweise einen Eigenschafts- / Eigenschaftsblock erstellen, mit dem Ihr Client schnell und einfach Eigenschaftsinformationen in andere Posts usw. einbetten kann. Während der Bearbeitung in Gutenberg können sie dann dieselben Informationen ändern, die Sie in ACF sehen, während sie die in Gutenberg angezeigten Eigenschaftsinformationen anzeigen. Gutenberg überholt nicht die Administrationsoberfläche von WordPress, sondern ersetzt die Funktionalität des Editors und wird höchstwahrscheinlich zu blockbasierten Inhaltsvorlagen führen.

Gute Dinge kommen aus Gutenberg, keine Kopfschmerzen!

Hier ist der Bearbeitungsbildschirm für Ereignisse für die oben genannte Site mit ACF-Feldern über post_content und dem Standard-Metaboxon für den Ereigniskalender unter post_content.

Die Site wird für viele, viele nicht technische Benutzer geöffnet. Wir sprechen nicht über ein geschultes Redaktionsteam. Wir sprechen über Joe Average, der WordPress noch nie zuvor verwendet hat oder jemals geschult wurde, außer der Hilfe, die wir auf der Site anbieten.

Wir haben dies so festgelegt, um sicherzustellen, dass Benutzer den Ereignistyp und die Kategorie sowie die Kopfzeile und die vorgestellten Bilder für jedes Ereignis finden und eingeben. Wir können auch die vorhandenen Meta-Box-Positionen verwenden, um relevante Hilfedokumentationen auf dem Bildschirm bereitzustellen, damit sie das Ereignis bearbeiten und neue Benutzer auf nicht aufdringliche Weise unterstützen können.

Beachten Sie auch, dass wir als Administrator angemeldet sind. Nicht-Administratorbenutzer haben verschiedene Meta-Boxen in der Seitenleiste ausgeblendet, um die visuelle Unordnung, die sie sehen, weiter zu reduzieren.

Der "Inhalt" ist bei weitem nicht so relevant wie die verschiedenen Meta-Boxen, um erfolgreich an einem Ereignis teilzunehmen. Ein Ereignis wird auf der Site nicht angezeigt, wenn ein Datum nicht korrekt eingegeben oder eine Kategorie ausgewählt wurde. Das, was mich an dieser ganzen Diskussion beunruhigt, sind Modelle wie in Ausgabe Nr. 1352, in denen die Meta-Boxen in einem zusammenklappbaren Bereich am unteren Bildschirmrand angezeigt werden. Ich kann Ihnen aus unserer Erfahrung garantieren, dass ungeschulte Benutzer die Meta-Boxen niemals sehen würden, nur das Datum und den Ort direkt in den Inhaltsbereich als einfachen Text eingeben und sich dann beschweren würden, dass ihre Veranstaltung nicht im System angezeigt wird. Es ist für nicht geschulte Benutzer in Post-Typen, die strukturierte Informationen benötigen, einfach nicht erkennbar genug.

Außerdem haben wir Felder in dieser Benutzeroberfläche benötigt. Wenn das Meta-Feld ausgeblendet ist, wird ein Benutzer eine Warnung erhalten, kann jedoch die Ursache des Problems nicht leicht finden.

Metaboxen oder die nächste Iteration ihrer Art von Funktionalität müssen erstklassige Bürger sein, und wir müssen sie über dem Inhalt, neben dem Inhalt oder unter dem Inhalt platzieren können, um für unsere Kunden nutzbare Schnittstellen zu schaffen.

Gutenberg wird sich höchstwahrscheinlich für CPTs entscheiden, ähnlich wie Ihr CPT die Unterstützung für den aktuellen Editor nicht deklariert.

Die Registrierung der Unterstützung für Gutenberg in CPTs wurde nicht bestätigt, und ehrlich gesagt scheint es eher so, als würde man das Problem der Meta-Boxen vermeiden, als es zu lösen. Wenn die einzige Möglichkeit für vorhandene Websites, auf Gutenberg zuzugreifen, darin besteht, die Unterstützung per Code zu registrieren, würde dies das potenzielle Publikum erheblich einschränken.

Wir sollten auch nicht so tun, als würden benutzerdefinierte Meta-Boxen nur in benutzerdefinierten Beitragstypen verwendet. Sie sind genauso wahrscheinlich auf regulären Posts und Seiten vorhanden.

Gutenberg überholt nicht die Admin-Oberfläche von WordPress, sondern ersetzt die Funktionalität des Editors ...

Das ist ungenau. Wie es heute existiert, ist Gutenberg ein Vollbild-Ersatz für den Nachbearbeitungsbildschirm.

@ BE-Webdesign & @ kevinwhoffman

Warum sollten CPTs auch auf die Aspekte von Gutenberg verzichten müssen, die deutlich besser sind als der aktuelle Bearbeitungsbildschirm?

Die Veröffentlichungssteuerelemente, die nach oben verschoben werden, damit sie nicht mit Inhalten verwechselt werden, und eine sauberere Gesamtästhetik sind definitiv die Stärken dieses Projekts.

Da wir keinen vernünftigen Plan haben, wie eine äquivalente Funktionalität wie derzeit für CPTs mit komplexen Anforderungen (über Meta-Boxen) erstellt werden kann, ignorieren wir einen großen Teil der Benutzerbasis und verweisen sie auf eine zweite Klasse, die letztendlich nicht unterstützt wird.

IMHO das ist einfach nur scheiße.

Ich behaupte nicht einmal, dass Metaboxen sofort funktionieren müssen, wie sie derzeit existieren. Möglicherweise gibt es eine neue und bessere Möglichkeit, diese Art der Schnittstellenflexibilität zu implementieren.

Was mich beunruhigt, ist, dass das Entwicklerteam die Probleme vieler Entwickler mit der Durchsetzung eines ersten Ansatzes "post_content" hier nicht wirklich zu verstehen scheint. Wir verwenden den Beaver Builder auf ALLEN unseren Websites, mit Ausnahme von CPTs, bei denen eine strukturierte Datenausgabe erforderlich ist. Ein Tool zum Erstellen von Seiten, wie es Gutenberg ist, eignet sich hervorragend für Posts und Seiten mit individuellen Inhaltsanforderungen. Es ist schrecklich für strukturierte Daten. Bei strukturierten Daten sind Schnittstellenkonsistenz, erforderliche Felder und andere Layoutprioritäten jedes Mal wichtiger als Freiforminhalte.

@ Kevinwhoffman

Wir sollten auch nicht so tun, als würden benutzerdefinierte Meta-Boxen nur in benutzerdefinierten Beitragstypen verwendet. Sie sind genauso wahrscheinlich auf regulären Posts und Seiten vorhanden. Das ist ungenau. Wie es heute existiert, ist Gutenberg ein Vollbild-Ersatz für den Nachbearbeitungsbildschirm.

Ja, aber es ersetzt nicht die gesamte Administrationsoberfläche, auf die ich mich bezog. Sie vergleichen ein unvollständiges Projekt mit der aktuellen Erfahrung. # 2251 wird, wenn es fertig ist, die allmächtigen Meta-Boxen wieder einführen, so dass es nicht allzu unterschiedlich und viel besser wird. Es wird wahrscheinlich einige Dinge geben, die bestimmte Plugin-Autoren möglicherweise optimieren müssen, aber zum größten Teil bin ich zuversichtlich, dass die Dinge reibungslos verlaufen werden.

@avocadesign

Warum sollten CPTs auch auf die Aspekte von Gutenberg verzichten müssen, die eindeutig besser sind als der aktuelle Bearbeitungsbildschirm?

Niemand hat gesagt, dass sie meines Wissens sind? Es gibt keinen allzu großen Unterschied zwischen dem Hinzufügen der Editorunterstützung für ein CPT und dem Hinzufügen der Unterstützung für den Blockeditor.

Da wir keinen vernünftigen Plan haben, wie eine äquivalente Funktionalität wie derzeit für CPTs mit komplexen Anforderungen (über Meta-Boxen) erstellt werden kann, ignorieren wir einen großen Teil der Benutzerbasis und verweisen sie auf eine zweite Klasse, die letztendlich nicht unterstützt wird.

Ich denke, es gibt einen anständigen Plan, vielleicht ist er nicht klar, aber ich bin sehr zuversichtlich, dass Gutenberg die Bedürfnisse der überwiegenden Mehrheit aller Arten von Benutzern erfüllen und sogar übertreffen wird, wenn alles gesagt und getan ist.

Niemand hat gesagt, dass sie meines Wissens sind? Es gibt keinen allzu großen Unterschied zwischen dem Hinzufügen der Editorunterstützung für ein CPT und dem Hinzufügen der Unterstützung für den Blockeditor.

Ich mache mir Sorgen, dass der Schritt, über den viele in diesem Thread gesprochen haben, Gutenberg für CPTs zu aktivieren, dazu führen wird, dass viele der derzeit komplexen Anwendungsfälle in Gutenberg kurz- bis mittelfristig ignoriert werden und Anwendungsfälle wie die Ereignisse effektiv erzwungen werden eine oben abgebildete, um das vorhandene System zu verwenden, da Gutenberg nicht flexibel genug ist. Dies zwingt diese derzeit komplexen Anwendungsfälle effektiv dazu, die anderen Vorteile des Projekts zu verpassen.

Uns wird oft gesagt, "mach dir keine Sorgen, es wird in Ordnung sein", aber du hast Recht @ BE-Webdesign, wenn du vorschlägst, dass der Plan für einige von uns überhaupt nicht klar dargestellt ist, ich kann es einfach nicht sehen alles, wie dies kurzfristig zufriedenstellend gelöst werden kann - wenn es dann frei ist, auf die Diskussion oder das Thema hinzuweisen, um mich aufzuklären.

Bearbeiten:
Was ich unter "kurzfristig" verstehe, ist die Veröffentlichung von 5.0 für die Öffentlichkeit. Anfang 2018 scheint hier das Ziel zu sein. Längerfristig in 2 oder 3 Jahren kann ich sehen, dass dies viel erfolgreicher gelöst wird.

@BennyVL & @dmccan Flexibilität ist hier das Hauptproblem. Korrigieren Sie mich, wenn ich falsch liege, aber nichts von dem, was ich von den Entwicklern vorschlage, die daran arbeiten, ist so flexibel wie das, was wir derzeit haben.

Mit ACF und anderen Plugins kann ich Metaboxen einfach über dem Inhalt (unter dem Titel), unter dem Inhalt und in der Seitenleiste registrieren. Das Design der Schnittstelle liegt bei mir. Es wird nicht erzwungen, dass der Editor an erster Stelle steht, es wird nicht vorgeschrieben, dass der Editor überhaupt anwesend ist. Ich kann neue Metaboxen registrieren, andere abmelden oder verschieben.

Was ich will, ist eine Lösung, die langfristig so flexibel bleibt. Ob die Metaboxen auf ein glänzendes neues JS-Format aktualisiert werden müssen, zu richtigen Blöcken werden müssen oder eine andere Änderung erforderlich ist, um dies zu ermöglichen, stört mich nicht wirklich. Ich möchte, dass die Flexibilität, die wir derzeit genießen, in Gutenberg enthalten ist, unabhängig von der Methode, mit der wir dorthin gelangen.

Was ich will, ist eine Lösung, die langfristig so flexibel bleibt. Ob die Metaboxen auf ein glänzendes neues JS-Format aktualisiert werden müssen, zu richtigen Blöcken werden müssen oder eine andere Änderung erforderlich ist, um dies zu ermöglichen, stört mich nicht wirklich. Ich möchte, dass die Flexibilität, die wir derzeit genießen, in Gutenberg enthalten ist, unabhängig von der Methode, mit der wir dorthin gelangen.

Das ist das Ziel und was die meisten Menschen wollen.

Ich habe viel Geschwätz über das Meta-Box-Problem gehört und was mit ihnen mit diesem neuen Editor passieren wird. Mein persönlicher Standpunkt ist, dass Gutenberg sich nur auf den Editor und nicht auf den gesamten Seitenbearbeitungsbildschirm konzentrieren sollte. Aber es scheint, dass die Entscheidung bereits getroffen wurde.

Hallo Leute,

Ich bin der Hauptentwickler für Carbon Fields und wollte die Liste der von uns verwendeten Aktionen / Filter hinzufügen, die möglicherweise betroffen sind:

Filter:

• postbox_classes_{$page}_{$id}

Aktionen:

• init
• admin_menu
• admin_init
• wp
• admin_enqueue_scripts
• in_admin_header
• admin_notices
• admin_print_footer_scripts
• save_post
• edit_comment
• media_buttons
• edit_form_after_title (Positionierung von Zucker - nicht kritisch)

Meine Fragen:

• Wenn wir ältere Meta-Boxen behalten wollen, wie würden sie mit Datenänderungen interagieren?
• Welche Art von Ereignissen (jQuery? Eine exponierte Implementierung eines Emitters?) Und welche Ereignisse können wir genau vom neuen Editor erwarten (z. B. über Erfolg, Misserfolg usw. der Übermittlung)?
• Werden diese Ereignisse für ältere Meta-Boxen oder nur für React-Implementierungen verfügbar sein?

PS:
Ich möchte mich nur beim Gutenberg-Team für die harte Arbeit und Mühe bedanken und freue mich, dass WordPress auf moderne Tools und Lösungen umstellt (auch wenn die Reise beängstigend erscheint)!

Die Unterstützung von Meta-Boxen ist sehr wichtig ...

... für Tausende von WordPress-Entwicklern und -Nutzern.

WordPress kann den großen Plugin-Player nicht ignorieren ...

... wie Advacend Custom Fields Pro (https://github.com/elliotcondon/acf/issues/622), WooCommerce oder Yoast SEO.

Ich bin verantwortlich für das Toolset- Projekt, das benutzerdefinierte Typen, Felder und Taxonomie stark verwendet.

Wir wollen unsere Plugins mit Gutenberg kompatibel machen.

Das verstehe ich:

• Wir müssen eine neue API verwenden, um die benutzerdefinierten Felder und Taxonomien auf Seiten und Posts anzuzeigen, wenn sie Gutenberg verwenden.
• Wir müssen nichts gegen Gutenberg für CPTs tun, da sie den normalen WordPress-Editor und nicht Gutenberg verwenden.

Ist das richtig? Wenn ja, können Sie mich bitte auf die Dokumentation zur API für die Anzeige benutzerdefinierter Boxen auf Gutenberg verweisen?

Ich denke, die Dokumente entwickeln sich noch weiter. Es gibt einige Dokumente unter https://github.com/WordPress/gutenberg/tree/master/docs - http://gutenberg-devdoc.surge.sh/

Ich höre, was @ BE-Webdesign und andere über die Absicht sagen, Störungen zu minimieren - danke, das ist beruhigend -, wollte aber nur meinen 5p-Wert hinzufügen (ok, ok, meinen üblichen 105p-Wert).

Jeder, der schon seit einiger Zeit entwickelt, wird sich an den Schmerz erinnern, Webschnittstellen für maßgeschneiderte Datenbanken manuell zu erstellen - langweilig, zeitaufwändig, fehleranfällig und in Bezug auf die Entwicklerzeit sehr teuer.

WordPress plus Advanced Custom Fields (Pro) ist ein großartiges Tool zum effizienten Erstellen maßgeschneiderter datenbankgesteuerter Websites (und sogar Intranet-Datenverwaltungstools) mit attraktiven Frontends, strengen Dateneingabeprüfungen, intuitiven und konsistenten Benutzeroberflächen usw. Diese Systeme funktionieren möglicherweise nicht für enorme Mengen relationaler Daten skalierbar sein, aber in sehr vielen Fällen müssen sie es nicht sein; Dies sind einfache Systeme, die für Kunden kostengünstig erstellt werden können. Dies macht WordPress zu einem wirklich nützlichen CMS (und praktisch zu einem leichten RDBMS), nicht nur zu einer Blogging-Plattform.

Ich (und ich bin sicher, viele andere) kleine Unternehmen verwenden WP + ACF (oder ähnliche benutzerdefinierte Daten-Plugins), um maßgeschneiderte Websites und Systeme für Kundenorganisationen und Einzelpersonen zu erstellen, die kein großes IT-Budget haben. Wenn die Einführung von Gutenberg ohne Berücksichtigung der Unterstützung bestehender Bearbeitungs- / Dateneingabeflüsse, Metaboxen usw. erfolgt, habe ich zwei "nicht technische", aber dennoch erhebliche Probleme:

1 / Meine Endbenutzer müssen neu geschult werden (für uns als Technikfreaks ist es leicht zu vergessen, wie verwirrt nicht-technische Benutzer durch Änderungen an der Benutzeroberfläche werden können. Ich habe das Plugin zum Zurücksetzen von Kennwörtern für Kennwörter geschrieben, weil ich so viel Zeit beim Sortieren verloren habe Benutzer, die durch den in 4.3) eingeführten neuen Prozess zum Zurücksetzen von Passwörtern völlig behindert wurden.

2 / Neben dem Upgrade meiner eigenen Plugins für einen anderen Metabox-Ansatz muss ich Zeit damit verbringen, alle meine Client-Sites mit professioneller Sorgfalt zu aktualisieren und zu testen, um sicherzustellen, dass alle Plugins von Drittanbietern von mir stammen using haben es auch geschafft, ihre Codebasis korrekt zu aktualisieren. (Und dies in einer Situation, in der ich keine Kontrolle darüber habe, wie schnell die Plugins von Drittanbietern entweder vor oder (noch schlimmer) irgendwann nach der Version 5.0 aktualisiert werden - daher wird die Workload-Planung wirklich schwierig.)

In keinem der oben genannten Fälle würde ich es für richtig halten, meinen Kunden weitere Gebühren für diese zusätzliche Arbeit in Rechnung zu stellen. Schließlich habe ich die Plattform ausgewählt, auf der ihre Websites und Systeme erstellt werden sollen, und es ist nicht so, als hätten sie Änderungen oder Verbesserungen angefordert. Vielleicht bin ich in dieser Hinsicht "zu nett" oder naiv, aber wie die Leute oben erwähnt haben, ist es ein Vertrauensproblem. Wir vertrauen darauf, dass WordPress uns nicht durch eine Unterbrechung der Abwärtskompatibilität in die Knie zwingt, damit unsere Kunden darauf vertrauen können, dass wir sie nicht wegen unerwarteter zusätzlicher Gebühren stechen. Das Nettoergebnis ist, dass ich plötzlich eine Menge zusätzlicher unbezahlter Arbeit habe, die irgendwie passt - möglicherweise dringend, wenn Websites durch das Upgrade sofort aktiv beschädigt werden - und gleichzeitig weiterhin genug bezahlte Arbeit leistet, um über Wasser zu bleiben.

Ich benutze WordPress sehr gerne und habe viel Zeit investiert, um die Seile zu lernen, meine eigenen praktischen Projekt-Frameworks usw. zu entwickeln - bis zu dem Punkt, an dem ich jetzt den größten Teil meines Lebensunterhalts (und meine Familie usw. ernähren) über WordPress-basierte Entwicklungsprojekte verdiene. Ich habe auch versucht, etwas zurückzugeben, indem ich mir die Zeit genommen habe, nützliche kleine Plugins, die ich auf WordPress.com entwickelt habe, offiziell zu veröffentlichen, weil ich OSS, Community-basierte Entwicklung usw. schätze. Ich denke, dies ist hauptsächlich ein Plädoyer, um die Probleme zu lösen in dieser Ausgabe erwähnt Thread so weit wie möglich zu Herzen; Ansonsten stimme ich zu, dass die Gefahr besteht, dass die Codebasis gespalten wird. Als WordPress-Fan und Plugin-Mitwirkender würde ich dies für ein WIRKLICH schlechtes Ergebnis halten. Als Solo-Entwickler, der sich auf WP verlässt, um seinen Lebensunterhalt zu verdienen, muss ich mich möglicherweise aus wirtschaftlichen Gründen für die gegabelte (dh ordnungsgemäß abwärtskompatible) Version entscheiden. Bitte lass das nicht zu!

@konamac macht einige großartige Punkte, von denen ich einige in einem anderen Thread gepostet habe.

Um dies zu vermeiden , ist

1. Es gibt keine eindeutige Antwort auf die zukünftige Unterstützung bestehender Metaboxen. Dies ist ein äußerst frustrierender und hartnäckiger Schritt gegen Entwicklungsagenturen und Themen- / Plugin-Autoren. "Gutenberg ist Open Source, also finden Sie es selbst heraus" ist unverantwortlich.

2. Gutenberg ist großartig. Ich liebe die Benutzeroberfläche, das visuelle Design und ich denke, dies ist der Weg der Zukunft in Bezug auf die Bearbeitung von Inhalten. Aber es ist weit dahinter, wo es sein muss, um es für eine Version 4.9 oder 5.0 in Betracht zu ziehen.

3. Alles, was ich im Vermächtnis tun sollte, sollte ich in Gutenberg tun können.

4. Bildschirmoptionen
5. Meta-Boxen (ACF, Yoast usw.)
6. Permalinks?! Ich kann nicht einmal verstehen, warum dies in 1.0 noch nicht bearbeitet werden kann
7. Der klassische Inhaltsblock wird in Localhost-Umgebungen NICHT ordnungsgemäß geladen
8. Die Dokumentation MUSS der Schlüssel sein, um verschiedene Stilblöcke zu erstellen. Nennen Sie mehrere Beispiele und Anwendungsfälle. Nicht jeder Theme-Entwickler ist ein Backend, also nehmen Sie nicht an. Sei kristallklar
9. Blockeinstellungen brauchen Arbeit. Es ist sehr schwierig zu sagen, welche Einstellungen pro Block verfügbar sind. Scheint zufällig. Wann muss ich Blockeinstellungen bearbeiten und wann nicht?
10. Die gesamten Kommentar-Tags rund um den Gutenberg-Texteditor sind ... traurig zu sehen.

Einige von uns sind äußerst frustriert über diesen Prozess. Es sollte eine absolut einfache Antwort sein.

Wird Gutenberg die derzeitige Verwendung von Metaboxen / ACF schützen, und gibt es Pläne, diese Unterstützung auf unbestimmte Zeit sicherzustellen?

Wir müssen nicht wissen, was die Lösung gerade ist - wir wissen, dass Sie es herausfinden. Aber wir haben noch keine klare Antwort darauf. Insbesondere ACF muss genau so funktionieren, wie es immer ältere Clients unterstützen muss, die NICHT damit einverstanden sind, für die Aktualisierung belastet zu werden - insbesondere, wenn es darum geht, irgendwann den Legacy-Editor zu entfernen (wie können Sie überhaupt anfangen, diese Konversation jetzt zu führen?! )

Liebe Gutenberg. Aber ich muss mich dem Chor anschließen - das wird lächerlich. Die Art und Weise, wie das Projektteam diese Erwartung kommuniziert hat, war nicht einfach. Ja oder Nein ist alles was wir suchen.

@ BE-Webdesign

Wenn es fertig ist, werden die allmächtigen Meta-Boxen wieder eingeführt

Kann ich daher vorschlagen, dass Sie einen ganzen Beitrag zu diesem Thema schreiben, dass Sie tatsächlich angegeben haben, dass Meta-Boxen, wie sie jetzt sind, bitte bleiben werden. Dies würde viele besorgte Entwickler in der Community verhindern, die sich Sorgen um ihr Geschäft machen.

Zusätzlich möchte ich das Team ermutigen, dies zu einer Priorität zu machen, um diese jetzt hinzuzufügen. Dies würde einen Großteil der Negativität rund um das Projekt verhindern, da bin ich mir sicher.

Wie in # 2308 angegeben, habe ich die Hooks kopiert, die das Meta Box-Plugin beim Erstellen / Speichern von benutzerdefinierten Feldern verwendet:

• Skripte und Stile werden mit admin_enqueue_scripts die Warteschlange gestellt. Wir überprüfen den aktuellen Bildschirm (über get_current_screen ), um sicherzustellen, dass Skripte und Stile nur für diese Seiten in die Warteschlange gestellt werden. Für das Core-Plugin wird nach Post-Typen geprüft. Bei Erweiterungen (Begriff Meta, Benutzer Meta, Einstellungsseite) wird mehr nach Taxonomien, Benutzerprofilseite oder Einstellungsseiten gesucht.
• Wir verwenden auch print_media_templates , um Unterstreichungsvorlagen zu drucken.
• Zu den Skripten, die wir im Plugin verwenden, gehören: Farbauswahl, Unterstrich, Backbone, Medienskripte, Tinymce (für das Editorfeld)
• Wir verwenden init , um alle Hooks für das Plugin zu initialisieren.
• Meta-Boxen werden mit add_meta_boxes Hooks registriert.
• Versteckte Meta-Boxen verwenden default_hidden_meta_boxes .
• Wir schließen uns auch post_edit_form_tag an, um das Hochladen von Dateien zu ermöglichen.
• Wir verwenden save_post_{$post_type} und edit_attachment , add_attachment , um Metawerte für Posts und Anhänge zu speichern.

Was ist falsch daran, Hooks zu erstellen, um Metaboxen über / unter / Seitenleiste von Gutenberg anzuzeigen?

Ich dachte, ich könnte genauso gut das tun, was Entwickler von Drittanbietern am besten können, und einen weiteren massiven Schraubenschlüssel in die Arbeit werfen.

Mattias sagt uns, dass Metaboxen als Blöcke neu interpretiert werden können, die in post_meta gespeichert sind. Wenn dies ein Ziel für die Zusammenführung ist, müssen einige Probleme behoben werden:

Viele Metaboxen registrieren the_editor($custom_id); , damit dies im Kontext von Gutenberg unterstützt wird. Entweder sind vom ersten Tag an eine Schnittstelle und eine API zum Erstellen verschachtelter Blöcke erforderlich, oder wir sagen, dass Metaboxen nur die Editorschnittstelle zweiter Klasse haben können , ohne die Vorteile von Blöcken. Dies ist besonders problematisch für die große Anzahl von Agenturen, die derzeit mit flexiblen ACF-Layouts entwerfen, da sie eine Möglichkeit benötigen, separate Gutenberg-Blöcke für verschiedene Kontexte und Bereiche zu erstellen. Selbst "in Blöcken denken" sehe ich keinen guten Weg, um das Problem "Inhaltsbereich gefolgt von Vorlagenteil gefolgt von Inhaltsbereich" zu lösen, ohne die Verschachtelung in "Metablocks" vom ersten Tag an zu unterstützen.

Daraus ergibt sich das technische Problem der Verschachtelung in Bezug auf Blöcke, die nicht in post_content gespeichert sind. Laut Mattias können Blöcke in Postmeta gespeichert werden. Wenn ein Block jedoch definieren kann, wo er gespeichert ist, wie funktioniert die Verschachtelung, wenn ein übergeordneter Block in Postmeta gespeichert wird und der Benutzer ein untergeordnetes Element hinzufügt, das in einem anderen post_meta gespeichert wird ... (Oder im pathologischen Fall enthält ein verschachtelter Block, den Tha in Postmeta speichert, einen Block, der in demselben Postmeta-Feld gespeichert ist.

Dies führt zu einem dritten Metabox-Problem. Wenn Gutenberg ein vollständiger Ersatz für Bearbeitungsseiten ist und kein Ersatz für the_editor() , wie können Benutzer Blöcke auf anderen Seiten und in anderen Kontexten, z. B. Metaboxen oder benutzerdefinierten Admin-Panels, die the_editor() in die Warteschlange stellen und verwenden?

Wenn Benutzer die Option Gutenberg erhalten und dies für sie ebenso revolutionär ist wie behauptet, könnte es sich für Agenturen als katastrophal erweisen, wenn sie diese neue Schnittstelle in diesen Fällen nicht bereitstellen können.

Es gibt keine eindeutige Antwort auf die zukünftige Unterstützung bestehender Metaboxen.

Ich habe wiederholt gesagt, dass wir Meta-Boxen berücksichtigen werden. Die einzige Unsicherheit besteht darin, was technisch machbar ist und wie es in der neuen Benutzeroberfläche angezeigt wird.

Wir versuchen nicht, irgendetwas zu beschädigen - Shortcodes, benutzerdefinierte Felder usw. - alles sollte noch funktionieren. Die Benutzeroberfläche für die Interaktion mit ihnen kann sich ändern (es sei denn, Sie deaktivieren Gutenberg vollständig), und bestimmte Anwendungsfälle für Meta-Boxen eignen sich besser für vorwärts gerichtete Blöcke.

Gutenberg ist großartig. Ich liebe die Benutzeroberfläche, das visuelle Design und ich denke, dies ist der Weg der Zukunft in Bezug auf die Bearbeitung von Inhalten.

Freut mich zu hören!

Permalinks?! Ich kann nicht einmal verstehen, warum dies in 1.0 noch nicht bearbeitet werden kann

Weil die REST-API dies noch nicht unterstützt. Jede Hilfe ist willkommen: https://github.com/WordPress/gutenberg/issues/1285

Ich habe wiederholt gesagt, dass wir Meta-Boxen berücksichtigen werden.

@mtias Ich denke, die Verwirrung hinsichtlich der Unterstützung von Meta-Boxen resultiert aus @m, was darauf hindeutet, dass ein Legacy-Plugin verfügbar sein wird, um vorhandene Funktionen wiederherzustellen. Es wäre hilfreich zu klären, welche Aspekte der vorhandenen Benutzeroberfläche (Meta-Boxen, Meta-Box-Positionen, Hooks usw.) weiterhin mit Gutenberg funktionieren und welche Aspekte erfordern, dass das Legacy-Plugin weiter funktioniert.

Ich habe wiederholt gesagt, dass wir Meta-Boxen berücksichtigen werden.

@mtias Ich entschuldige mich, ich muss Ihre Klarstellung an anderer Stelle verpasst haben. Froh zu hören! Machen Sie die aktuelle Iteration optisch ansprechender und zielgerichteter und es wird ein großer Erfolg.

Ich verstehe, was Sie über die Unterstützung der REST-API sagen. Ich werde den Thread nach Updates durchsuchen.

Danke für das Aufklären. Jetzt, wo ich diese Einsicht habe, bin ich Gutenberg mit voller Kraft voraus - alle meine Ängste werden beiseite gelegt.

@kevinwhoffman Richtig , ich denke, das Herzstück des Problems ist, dass "vorhandene Funktionalität" auch die Präsentation umfasst - und da Gutenberg die Benutzeroberfläche erheblich ändert, würde die Deaktivierung der Benutzeroberfläche das Deaktivieren des Plugins erfordern. Es wird daran gearbeitet, wie Meta-Boxen in die neue Benutzeroberfläche passen und wie alte Meta-Boxen ohne Eingreifen des Entwicklers unterstützt werden können. Ich weiß nicht genau, wie das funktionieren wird, daher konnte ich kein bestimmtes Ergebnis versprechen. Ich denke auch, dass dies zu einer klareren Darstellung der Funktionen von Meta-Boxen führen könnte.

@brograhamer keine Entschuldigung nötig, es ist ein großer Thread! Wir wollen nichts beschleunigen, und dies ist ein ziemlich großes Projekt mit vielen beweglichen Teilen. Manchmal scheinen einige Dinge vernachlässigt zu sein, aber das bedeutet nicht, dass wir nicht vorhaben, sie zu lösen.

Ich erstelle derzeit eine Web-App mit ACF mit 10 benutzerdefinierten Beitragstypen, die den Tinymce-Editor nicht verwenden. Ich verwende die Titelfunktion und durchschnittlich 15 ACF-Felder für jedes CPT.
Derzeit können Sie festlegen, welche Funktionen (z. B. Editor, Miniaturansicht, Auszug usw.) von einem CPT unterstützt werden.
Ist es möglich, den Absatzblock "Write your story" sowie das Symbol "Block einfügen" im Bearbeitungsbildschirm auszublenden / zu entfernen?

@ cr101 Ich denke, wenn Sie den "Editor" von Ihren CPT-Unterstützungen

Auf der anderen Seite können mit der Version 1 der Metaboxen die Metaboxenfenster von unten erweitert werden. Wenn wir dies beibehalten, sollten wir sicherstellen, dass es für CPTs ohne "Editor" -Unterstützung immer "offen" ist. Es ist möglicherweise nicht erforderlich, wenn die Metaboxen immer unter dem Editor angezeigt werden (wie einige der obigen Designvorschläge).

Ich bin mir nicht sicher, ob dies der richtige Ort dafür ist, aber was ist mit den benutzerdefinierten Kernmetafeldern? Es wurde viel über Plugins von Drittanbietern gesprochen, aber was ist mit den wichtigsten benutzerdefinierten Metafeldern? Ich weiß, dass diese nicht wirklich so beliebt sind, aber ich kann mir ein paar Websites vorstellen, an denen ich gearbeitet habe und die sie verwenden.

Gibt es einen Plan für die Integration der wichtigsten benutzerdefinierten Metafelder in Gutenberg?

Hallo @jawittdesigns ,

Ich bin mir ziemlich sicher, dass die Kernmetaboxen (zumindest die meisten von ihnen) bereits in Gutenberg neu implementiert wurden! Sie bieten einige schönere Arbeitsabläufe im Umgang mit Taxonomien usw.

Nicht jeder nutzt WordPress zum Bloggen. Viele von uns verwenden WordPress als CMS. Wir erstellen derzeit eine Web-App mit der WordPress REST API und ACF. Wir haben 10 benutzerdefinierte Beitragstypen und jedes CPT verfügt über 20 benutzerdefinierte Felder. Alle CPTs sind über bidirektionale Beziehungen unter Verwendung der Felder ACF-Beziehung und Post-Objekt sowie des ACF-Post-2-Post-Plugins miteinander verknüpft

Gutenberg nützt uns in seiner aktuellen Form nichts, da wir nicht einmal den aktuellen Editor verwenden. Wir verwenden nur das Titelfeld für unsere CPTs und der Rest sind benutzerdefinierte Felder, die in der Tabelle post_meta gespeichert werden.

Ich bin der festen Überzeugung, dass der Gutenberg-Herausgeber in seinem gegenwärtigen Zustand nicht Teil des Kerns werden sollte. Ich erkenne, dass WordPress als Projekt etwas für diejenigen Site Builder spielen muss, die nicht mit ihren eigenen benutzerdefinierten Themen arbeiten. Der Gutenberg-Editor scheint jedoch ein direkter Angriff auf diejenigen von uns zu sein, die erweiterte benutzerdefinierte Felder verwenden, um komplexe Inhalte einzugeben ziemlich "idiotensicher" für Websitebesitzer, indem sie ihnen eine ganz bestimmte Möglichkeit geben, ihre Inhalte einzugeben. Der Gutenberg-Editor in seinem aktuellen Zustand scheint ein direkter Angriff auf diejenigen von uns zu sein, die ACF verwenden.
Mit dem Gutenberg-Plugin sendet der Bearbeitungslink in der Kopfzeile den Benutzer direkt in die Gutenberg-Oberfläche, in der KEINE der ACF-Meta-Boxen angezeigt wird und die oben auf dem Bildschirm keine Registerkarte mit Bildschirmoptionen enthält, um sie zu aktivieren. Ja, der Benutzer kann zum Seiten- / Post-Array zurückkehren und die Option „Klassischer Editor“ auswählen und dann die Meta-Boxen anzeigen. Dies bedeutet jedoch, dass der Site-Editor einen zusätzlichen Schritt ausführen muss, um zu den ACF-Feldern zu gelangen. Nicht gerade optimal, wenn man bedenkt, dass das Ziel der Verwendung von ACF in vielen Fällen darin bestand, die Bearbeitung komplexer Layouts für einen nicht-technischen Redakteur flüssiger und unkomplizierter zu gestalten.

Was für ein langjähriges Problem das war!

Mit der Zusammenführung von # 3345 und # 3554 befindet sich die Meta-Box-Unterstützung in einem Zustand, den wir gerne als _feature complete_ bezeichnen. Beachten Sie, dass dies anders ist als _complete_, da offensichtlich noch viel zu tun ist, um die Meta-Box-Erfahrung zu verbessern, insbesondere in Bezug auf das Styling, die komplexere JavaScript-Behandlung und die Festlegung von Regeln für das Zurückgreifen auf den klassischen Editor.

Vielen Dank an alle, die konstruktiv an dieser Ausgabe teilgenommen haben. Ich verstehe, dass es ein schwieriger und gelegentlich kontroverser Prozess war. Eine Dokumentation darüber, wie Gutenberg mit Meta-Boxen umgeht und wie Sie (wenn Sie es vorziehen) Meta-Boxen als mit Gutenberg nicht kompatibel markieren können, finden Sie im Handbuch .

Wenn Sie auf Fehler stoßen, die mit bestimmten Plugins oder Meta-Boxen verbunden sind, öffnen Sie bitte ein neues Problem, damit es korrekt nachverfolgt und behoben werden kann.

In Bezug darauf sollte dies bei weitem nicht vollständig sein.

@coffeeneed Wenn Sie konstruktiv sein