Gutenberg-Mitarbeiter diskutieren die Nachteile der Verwendung von Iframes für Meta-Boxen

Auf GitHub findet eine lebhafte und produktive Diskussion über Gutenbergs Verwendung von iFrames für Metaboxen statt. Gestern hat der WordPress-Entwickler Kevin Hoffman eine Ausgabe mit dem Titel „Sind iFrames eine praktikable langfristige Lösung für Metaboxen?“ erstellt.

Gutenberg 1.5 führte die anfängliche Unterstützung für Metaboxen ein. Hoffman identifizierte mehrere Probleme mit Iframes, die aufgetaucht sind, als Entwickler begonnen haben, die aktuelle Meta-Box-Implementierung zu testen. Er führte einige Leistungstests durch, die zeigten, dass Gutenbergs Verwendung von Iframes die Anzahl der Asset-Anfragen verdreifacht, da es alle CSS- und JS-Assets in das übergeordnete Fenster sowie in alle Iframes einreiht.

„Im Allgemeinen wurde aus gut dokumentierten Gründen seit vielen Jahren von iFrames in der Webentwicklung abgeraten“, sagte Hoffman, bevor er eine Litanei von Problemen anführte, die Plugin-Entwickler bereits beim Testen von Gutenbergs Metabox-Unterstützung entdeckt hatten. „Können diese Probleme behoben werden, ohne dass das Design oder Plugin, das die Metabox generiert, geändert werden muss? Wir müssen bedenken, dass Code von Drittanbietern, der seit Jahren Metaboxen unterstützt, möglicherweise nicht den Luxus hat, aktualisiert zu werden, um innerhalb eines Iframes kompatibel zu sein.“

Gutenberg-Designleiterin Tammie Lister antwortete auf Hoffmans Bedenken und wies darauf hin, dass die aktuelle Implementierung von Metaboxen lediglich ein Experiment sei und nicht unbedingt das, was in WordPress 5.0 landen würde:

Es ist gut, ein wenig darüber nachzudenken, dass das, was wir heute für Metaboxen in Gutenberg haben, ein Experiment ist, in vielerlei Hinsicht ist es eine Warteschleife, während das Projekt die einzuschlagende Richtung ausarbeitet. Zu sagen, dass es „vorerst“ funktioniert, aber nicht das ist, was wir mitliefern würden.

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

Die Präsentation dieser Implementierung als Experiment, das „vorerst funktioniert“ (aber nicht ausgeliefert werden würde), kommt überraschend, nachdem Gutenberg 1.5 mit der Ankündigung eintraf, dass „diese Version die lang erwartete Unterstützung von Meta-Boxen enthält (muss getestet werden!)“.

Hoffman behauptet, dass der Iframe-Ansatz „vorerst“ nicht einmal funktioniert, da das Thema eröffnet wurde, um mehrere Hauptwege zu nennen, an denen er gebrochen ist. Wenn Gutenberg mit dem aktuellen Ansatz fortfährt, müssten viele Plugins modifiziert werden, um mit WordPress 5.0 kompatibel zu sein, was laut Hoffman den ganzen Zweck der Unterstützung älterer Metaboxen zunichte machen würde.

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

Edwin Cromley, ein Mitarbeiter des Projekts, sagte, dass das Team damit rechnet, dass bestimmte Themen und Plugins kaputt gehen und dass es nicht möglich ist, jeden möglichen Anwendungsfall zu berücksichtigen. Er räumte ein, dass die Iframe-Lösung die Projektziele möglicherweise nicht erfülle. Stattdessen plädiert er dafür, die beste Erfahrung für die überwiegende Mehrheit der Benutzer zu schaffen.

Der aktuelle Ansatz würde jedoch viele Websites da draußen beeinträchtigen, die WordPress hauptsächlich als CMS mit Metaboxen verwenden. Der WordPress-Core-Committer Scott Taylor äußerte Bedenken hinsichtlich benutzerdefinierter Post-Typen, von denen viele nicht den traditionellen Abschnitt „Inhalt“ zugunsten von Meta-Boxen verwenden.

„In dieser aktuellen Iteration ist die Unterstützung von Meta-Boxen ein Add-on, während Meta-Boxen in der Realität vieler Menschen die Benutzeroberfläche, die API, der Mechanismus SIND, den sie verwenden, um ihr CMS zu erstellen“, sagte Taylor. „iFrames sind der Gulag.

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

Hoffman plädierte dafür, den Umfang des Projekts zu reduzieren und sich auf die Editor-Komponente zu konzentrieren, eine weit verbreitete Meinung, die viele Plugin-Entwickler teilen und die in Yoasts Beitrag, in dem er einen alternativen Ansatz zu Gutenberg vorschlägt, ausführlich dargestellt wurde. Dieser Ansatz verschiebt die Änderungen am Bearbeitungsbildschirm, gibt Entwicklern mehr Zeit, ihre Plugins zu aktualisieren, und ermöglicht es dem Gutenberg-Team, eine angemessene Lösung für Metaboxen zu finden.

„Ich denke, dieses Ziel wäre viel besser erreichbar, wenn Gutenberg bei der Überarbeitung des Editors bleiben würde, anstatt die gesamte Seite zu übernehmen“, sagte Hoffman. „Dann könnten wir die bestehenden Hooks belassen und Metaboxen könnten wie bisher miteinander kommunizieren. Auch das Einreihen von Vermögenswerten wäre kein Problem, da es so funktionieren würde, wie es heute funktioniert.

„Ich stimme diesem Konzept von Yoast voll und ganz zu, das meiner Meinung nach einen Großteil der bereits geleisteten Arbeit beibehalten und gleichzeitig den Umfang des Projekts auf die Editor-Komponente reduzieren würde.“

Gutenberg-Ingenieur Riad Benguella gab an, dass das Team nicht sehr daran interessiert ist, auf dieses Konzept hinzuarbeiten.

„Die Wiederverwendung von Gutenberg-Teilen zur Erstellung dieses Konzepts ist relativ machbar, aber dies ist nicht die UX, für die wir optimieren möchten. Wir möchten zuerst den bestmöglichen Editor erstellen und ihn für Menschen ohne Bedenken hinsichtlich der Abwärtskompatibilität verfügbar machen (Neuinstallationen, keine Metaboxen … )“, sagte Benguella.

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

Die WordPress-Entwicklergemeinde ist jedoch nicht dafür, diese Diskussion noch einmal zu verzögern. Viele sind gespannt darauf, endlich die Frage zu beantworten, wie Metaboxen in den Kontext des Gutenberg-Editors passen, damit sie wissen, wie man sich vorbereitet. Angesichts der zahlreichen Probleme mit dem Iframe-Ansatz erfordert das Rendern von älteren PHP-Metaboxen unter dem neuen Editor mehr Experimente und möglicherweise eine alternative Lösung.

„Warum Tausende von Stunden in die Entwicklung des idealen Editors investieren, wenn er nicht mit bestehenden Websites kompatibel gemacht werden kann?“ sagte Hoffmann. „Wenn der erste Eindruck ist, dass es die Benutzeroberfläche, auf die sie angewiesen sind, kaputt macht, werden Benutzer den idealen Editor überhaupt nicht erleben.“

„Ich denke, es könnte ein Fehler sein, dies zu weit hinauszuzögern“, sagte WordPress Core Committer Aaron Jorbin. „Vor allem, da viele Organisationen mindestens 1-2 Quartale für die Vorbereitung benötigen werden.“

Mark Kaplun schlägt vor, dass das Gutenberg-Team ein beliebtes Plugin als Maßstab für den Erfolg aktueller und zukünftiger Experimente zur Unterstützung von Metaboxen verwendet.

„Mein produktiver Vorschlag ist, Metaboxen nicht für bereit zu erklären, solange Yoast SEO darin nicht richtig funktioniert“, sagte Kaplun. „Es ist sowohl etwas komplex in Bezug auf die Interaktionen als auch auf einer Menge Websites installiert. Wenn Gutenberg damit nicht arbeiten kann, wird es wahrscheinlich niemand verwenden.“

Greg Schoppe, der die laufende Entwicklung von Gutenberg ausführlich getestet und geschrieben hat, schloss sich dem Gespräch an, um auch für Yoasts alternative Herangehensweise an das Projekt einzutreten.

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

„In diesem Fall schadet der Mangel an klarer Richtung und Unterstützung für die bestehenden Standard-Workflows den Entwicklern jetzt aktiv. Wie kann ich beim Aufbau eines Projekts vorankommen, ohne einen vertrauenswürdigen Satz von Hooks und Tools, auf die ich mich verlassen kann? Es ist skrupellos zu glauben, dass ein so großes Softwareprojekt den Standard-Workflow für Entwickler in einem einzigen Update völlig auf den Kopf stellen würde. und es ist verrückt, dass diese Gespräche gerade jetzt im November stattfinden, wenn der Plan ist, eine Fusion Anfang des Jahres genehmigen zu lassen.“

Die gestern eröffnete Diskussion um den iFrames-Ansatz für Metaboxen ist noch relativ neu, aber bisher sind die Antworten des Gutenberg-Teams nicht ausreichend auf die Bedenken der Entwickler-Community in diesem Thread eingegangen. Eine der größten Herausforderungen des Gutenberg-Teams ist es, einen Ansatz für Meta-Boxen zu finden, der die leistungsstarken CMS-Funktionen von WordPress bewahrt, ohne Benutzer und Entwickler zu verprellen. Sie zielen immer noch darauf ab, Anfang nächsten Jahres einen Fusionsvorschlag zu erstellen, aber da sich die Metaboxen noch in der Experimentierphase befinden, bringt der voraussichtliche Zeitplan des Teams das Projekt weiterhin in Konflikt mit der WordPress-Entwicklergemeinschaft.