Das Gutenberg-Entwicklungsteam bestätigt, dass die Meta Box-API nicht offiziell veraltet ist

Die Diskussion darüber, wie Gutenberg mit Metaboxen umgehen wird, hat sich am Wochenende aufgeheizt, nachdem ein Teilnehmer das GitHub-Problem mit Bedenken hinsichtlich der Entfernung der Metabox-Unterstützung aus dem neuesten Meilenstein kommentiert hatte.

„Wie ich sehe, wurde dieses wichtige Problem aus allen Meilensteinen entfernt“, sagte @steveangstrom. „Es wurde wieder weniger priorisiert, während Glocken und Pfeifen für die Blog-Bearbeitung viel Arbeit bekommen und zu Betas hinzugefügt werden. Das ist sehr besorgniserregend für die Zukunft von WordPress als CMS.“

James Nylen, einer der leitenden Entwickler des Projekts, versicherte den Anhängern des Themas, dass das Gutenberg-Team das Problem nicht vergessen habe, sondern dass es „ein äußerst kompliziertes Problem ist, mit dem wir uns gerade erst zu befassen beginnen, zusammen mit vielen, viele andere Prioritäten, damit der Editor gut funktioniert.“ Er bat die Community auch um Hilfe bei der Planung und dem Testen von Implementierungen zur Unterstützung von Metaboxen.

Diese Antwort ließ viele Dinge unklar. Die Diskussionsteilnehmer, von denen viele Entwickler besorgt sind über die Aussicht, alle ihre Metaboxen als React-Komponenten neu schreiben zu müssen, fragen sich, warum Metaboxen nicht neben dem neuen Gutenberg-Editor funktionieren können und warum sich das Team dafür entschieden hat, Metaboxen darin aufzunehmen den Umfang des Projekts.

„Ist es möglich, den vorhandenen TinyMCE-Post-Editor durch Gutenberg zu ersetzen, während der Rest der Benutzeroberfläche, einschließlich Metaboxen und vorhandener Hooks, unverändert bleibt?“ fragte Kevin Hoffmann. Als Nylen klarstellte, dass Gutenberg, wie er heute geschrieben wurde, ein post_content Editor sein soll, fasste Hoffman die Bedenken zusammen, die viele Entwickler geäußert haben:

Wenn Gutenberg wirklich ein post_content Editor sein soll, dann sollten Meta-Boxen in Ruhe gelassen werden, da sie sich nicht mit post_content .

Darüber hinaus ist die Notwendigkeit einer API zum Übersetzen von PHP-Metaboxen in React-Metaboxen ein fabriziertes Problem. Es muss kein Problem sein, ist aber zu einem Problem geworden, weil irgendwann entschieden wurde, dass das Umschreiben des post_content Editors auch die Funktionsweise von Metaboxen komplett ändern sollte.

Sie haben die enorme Herausforderung beim Schreiben einer solchen API in #2251 beschrieben. Das Übersetzen von PHP-Metaboxen in React für eine beliebte Lösung für benutzerdefinierte Felder wie ACF ist herausfordernd genug, ganz zu schweigen davon, dies für jede heute existierende Metabox-Implementierung zu tun, ob beliebt oder nicht. Es skaliert nicht.

Da die Gutenberg-Mitarbeiter mitteilten, dass sie gerade erst begonnen haben, sich mit dem Meta-Box-Problem zu befassen, ist jetzt klar, warum es keine Roadmap dafür gibt, wie das Projekt mit „alten“ PHP-Meta-Boxen umgehen wird. Im Juli sagte Nylen: „Wenn ich raten müsste, wo wir hier landen werden: Aktuelle Metaboxen werden in einen „Legacy“-Bereich verschoben und wir werden APIs, Dokumentation und Beispiele für die Registrierung von Metabox-Blöcken im „neuen Stil“ bereitstellen -dinger.“

Plugin-Entwickler, die Meta-Box-Bibliotheken, Agenturen und andere Betroffene verwalten, folgen dem Ticket, um herauszufinden, wie man für WordPress 5.0 plant, das als Gutenberg-Release anvisiert wurde. Andrey Savchenko fragte, ob WordPress plane, die Meta-Box-API offiziell abzulehnen, woraufhin das Team schließlich eine klare Antwort erhielt. Matias Ventura antwortete:

„Beabsichtigt WordPress, die Metabox-API offiziell abzulehnen?“
Nein.

Die noch nicht vollständig beantwortete Frage ist, wie Meta-Boxen im Kontext des Gutenberg-Editors funktionieren. Sollen sie gleich bleiben oder sich weiterentwickeln? Wie können wir uns den Designzielen mit der geringstmöglichen Störung nähern?

Dieses Problem besteht nicht aus Mangel an Verlangen, sondern aus Mangel an Ressourcen. Der Hauptfokus dieses Projekts liegt auf der Bereitstellung einer reichhaltigen Oberfläche zur Bearbeitung von Inhalten, die die direkte Bearbeitung von Benutzerinhalten durch das Konzept von Blöcken optimiert. (Nachdem ich Meta-Boxen ausgiebig für verschiedene Projekte verwendet habe, glaube ich, dass Blöcke für viele dieser Anforderungen einen besseren Schritt nach vorne bieten und gleichzeitig eine bessere Benutzererfahrung bieten können.)“

Ventura listete mehrere Optionen auf, die das Team für den Umgang mit Metaboxen in Betracht gezogen hat, und bat die Community um Hilfe, um die beste Lösung zu entwickeln:

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

Auf die Frage gedrängt, warum Meta-Boxen in den Kontext des neuen Editors aufgenommen werden, erläuterte Gutenberg-Designleiter Joen Asmussen, wie das Team entschieden hat, Meta-Boxen in den Umfang des Projekts aufzunehmen:

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

Wenn die Hauptstärke von WordPress darin besteht, es jedem leicht zu machen, reichhaltige Beiträge zu erstellen, dann 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 Veröffentlichungsschnittstelle erwarten. Andernfalls würden wir einer ohnehin schon schweren Benutzeroberfläche nur kognitive Last hinzufügen.

Offen ist noch die Frage, wie Metaboxen in den Kontext des Gutenberg-Editors passen. Die Diskussionsteilnehmer möchten diese Frage aus Gründen der Abwärtskompatibilität und auch, weil sie laufende Entscheidungen in Bezug auf die Entwicklung von Gutenberg und das Bildschirmdesign betrifft, beantwortet bekommen.

„Ich verstehe vollkommen, wie viel Arbeit in den „Bildschirm“-Ersatzansatz investiert wurde“, kommentierte Xavi Ivars das Problem. „Aber hätte ein Projekt, das mit dem Ziel eines Ersatzes für den Post-Content-Editor begann, nicht an die Community zurückgehen sollen, bevor einseitig entschieden wurde, dass es den gesamten Editor-Bildschirm ersetzen würde?“

Die Meta-Box-API ist nicht veraltet, aber es gibt auch keinen klaren Weg, wie Gutenberg „alte“ PHP-Meta-Boxen unterstützen wird. Das Gutenberg-Team sagte, das Problem sei aufgrund fehlender Ressourcen nicht gelöst worden. Das Projekt braucht Community-Input und bessere Kommunikation, wenn das Team auf einer Lösung landen will, die die Mehrheit der WordPress-Sites nahtlos in die Gutenberg-Ära mit dem geringsten Bruch führt.

Derzeit ist die Machbarkeit des Renderns von Legacy-PHP-Metaboxen unter dem Inhalt mit Herausforderungen behaftet und steht noch zur Debatte. Wenn nicht genügend Zeit oder Client-Ressourcen für Entwickler vorhanden sind, um ihre Arbeit in JS-gesteuerte Metaboxen umzuschreiben, dann ist möglicherweise ein klarer Pfad zum Deaktivieren der Gutenberg-Schnittstelle für Websites erforderlich, die die alten „PHP“-Metaboxen beibehalten müssen .