Neuer Vorschlag fordert Mitwirkende auf, die Zusammenführung experimenteller APIs von Gutenberg mit WordPress Core zu stoppen

Die Praxis, experimentelle APIs von Gutenberg in den WordPress-Kern zu integrieren, könnte bald zu Ende gehen. Ein neuer Vorschlag, der von Adam Zielinski, einem von Automattic gesponserten Mitarbeiter, veröffentlicht wurde, fordert die Mitwirkenden auf, APIs zu stabilisieren, bevor sie mit dem Kern zusammengeführt werden.

Im Laufe der Jahre wurden ungefähr 280 experimentelle APIs aus dem Gutenberg-Plugin zusammengeführt, die Zielinski in einem Ticket prüfte, das er im April für die Ausgabe eröffnete. Beim Abwägen des Bestrebens, sich schnell zu bewegen, mit der Iteration des/der Editoren gegen die Verpflichtung von WordPress zur Abwärtskompatibilität, ist die Anzahl der experimentellen APIs unhaltbar geworden, und die Praxis, sie in den Kern zu integrieren, wird jetzt aktiv überdacht.

Offiziell sind die experimentellen APIs als solche gekennzeichnet, um von der Nutzung durch Dritte abzuraten, da sie sich voraussichtlich ändern werden. In der Praxis verwenden Leute, die für den Blockeditor bauen, sie sowieso, weil sie im Kern sind und die Funktionen erweitern möchten, die diese APIs ermöglichen.

„Plugin- und Theme-Autoren sind gezwungen, sich auf die __experimental Funktionen zu verlassen, die jederzeit entfernt oder rückwärtsinkompatibel geändert werden könnten“, sagte Zielinski und wiederholte die Frustration und Bedenken, die viele Entwickler in den letzten Jahren mit dem Projekt hatten. „Es ist eine ernsthafte Wartungsbelastung. Jede neue Gutenberg/WordPress-Veröffentlichung bedeutet potenziell bahnbrechende Änderungen.“

WordPress-Core-Committer Peter Wilson kommentierte das Ticket und sagte, er sei dafür, experimentelle APIs auf Spitzenprodukte zu beschränken. Er verdeutlichte die Notwendigkeit dieser Änderung und führte eine Vielzahl negativer Auswirkungen an, die diese zentralen experimentellen APIs auf das Ökosystem hatten:

• Kern-Committer, die nicht bereit sind, bestimmte Bibliotheksfunktionen zu verwenden, um Kernaufgaben zu erleichtern, weil sie der Zuverlässigkeit nicht vertrauen
• Entwickler aktualisieren keine WP-Client-Sites mehr. Als Core-Committer, der sich seit Jahren bemüht, die Abwärtskompatibilität aufrechtzuerhalten, enttäuscht mich das. Als Mitglied des Sicherheitsteams ist das sehr besorgniserregend
• Entwickler, die sich dafür entscheiden, Kopien von Paketen in Themen und Plugins aufzunehmen, anstatt sich auf die wp.* Globals zu verlassen. Auch dies beunruhigt mich aus Sicherheitsgründen, aber es erhöht auch die JavaScript-Nutzlast erheblich mehr als die Aufrechterhaltung der Abwärtskompatibilität
• Berichte über Abwärtskompatibilitätsbrüche in Nebenversionen: „Sie erwarten nicht, dass eine 5.9.1-Version die Reaktionsfähigkeit einer Reihe von Bildern auf unseren Websites außerhalb des Blockeditors beeinträchtigt“
• Entwickler erwägen, niemals Kernblöcke zu verwenden, weil sie zu instabil sind: „Ich habe aufgehört, Kernblöcke zu verwenden/erweitern, weil sie sich zu sehr verändert haben, und ich habe ACF-Blöcke verwendet, damit ich zumindest weiß, dass ich Blöcke erstellen kann, die dies nicht tun Unterbrechung. Zugegeben, die Benutzeroberfläche ist nicht so gut wie Kernblöcke, aber ich werde jederzeit Stabilität gegenüber Blöcken nehmen, die brechen.

Das Gutenberg-Plug-in sollte als Feature-Plug-in fungieren, bei dem Unterbrechungen der Abwärtskompatibilität erwartet werden, während Mitwirkende Funktionen aufpolieren, bevor sie in den Kern integriert werden. Zu den Wurzeln dieses Ansatzes zurückzukehren und den Editor weniger experimentell zu gestalten, steht im Mittelpunkt dieses Vorschlags.

„Die Instabilität zwischen den Versionen beginnt bereits, einige der größten externen Befürworter der Block-Editoren zu entfremden“, sagte Wilson.

Die Aufrechterhaltung dieses Instabilitätsniveaus könnte Menschen davon abhalten, auf WordPress aufzubauen, und sie zu anderen einfacheren Projekten verdrängen, die auf andere Weise verwaltet werden. Es ist möglich, dass die Notwendigkeit, sich auf experimentelle APIs zu verlassen, Entwickler davon abgehalten hat, mehr Produkte zu entwickeln, was die Akzeptanz von Blockeditoren verlangsamt.

„Als Plugin-Autor, der derzeit viele __experimental APIs verwendet, würde ich gerne sehen, wie diese stabilisiert werden“, sagte der von WP Engine gesponserte Mitwirkende Nick Diego. „Die meisten bieten wichtige Funktionen, aber die Entwicklung eines Produkts, das auf einer __experimental API basiert, ist immer etwas beunruhigend. Solange der Prozess äußerst transparent ist, gut bekannt gemacht wird und wir Plug-in-/Theme-Autoren eine Anleitung zur Migration auf stabile Versionen zur Verfügung stellen, gefällt mir diese Initiative.“

Nach monatelanger Diskussion über das Ticket destillierte Zielinski die Bedenken der Mitwirkenden in den im Make WordPress Core-Blog vorgeschlagenen Aktionsplan ein.

Der Vorschlag weist darauf hin, dass die meisten der bestehenden experimentellen APIs, die bereits in den Kern integriert wurden, einen stabilen Alias ​​erhalten würden.

„Es würde die Abwärtskompatibilität bewahren und sollte die Bundle-Größe nicht merklich beeinflussen“, sagte Zielinski. „Einige werden eine andere Behandlung benötigen; Lassen Sie uns das von Fall zu Fall besprechen.“ Er empfahl den Mitwirkenden auch zu überlegen, ob eine vorhandene experimentelle API, die sich bereits im Kern befindet, entfernt werden muss. Er erwartet nicht viele Fälle davon, empfiehlt diesen jedoch, etablierte Praktiken der Kontaktaufnahme mit Plugin-Autoren, die Verwendung von Soft Deprecations und die Veröffentlichung von Core-Beiträgen zu verwenden.

„Ich sehe hier auch zwei Dinge im Spiel: die Verwendung und den Missbrauch von experimentellen APIs während des API-Designs (im Allgemeinen im Gutenberg-Plugin zu verwenden und zu testen) und das Fehlen eines sorgfältigen Prozesses, um sie zu stabilisieren, wenn sie Designkriterien erfüllen.“ Der leitende Gutenberg-Architekt Matias Ventura kommentierte das Originalticket. „Als de facto öffentlich zu betrachten sind diejenigen, die trotz ihrer Nomenklatur seit vielen Veröffentlichungen in stabiler Form existieren.“

Im Interesse der Erhaltung der Fähigkeit von WordPress, seine Abwärtskompatibilitätsversprechen zu erfüllen, empfiehlt der Vorschlag, experimentelle APIs auf das Gutenberg-Plugin zu beschränken und niemals in den Kern zu integrieren. In den Fällen, in denen eine stabile Funktion von einer experimentellen API abhängt, fand Zielinski eine einfache Antwort:

„Dann ist es nicht wirklich stabil. Lassen Sie uns zuerst die Abhängigkeiten stabilisieren.“

Dies ist im Wesentlichen ein neuer Weg, um voranzukommen, der die Stabilität und das Vertrauen in die APIs und Updates von WordPress erhöhen sollte, aber er hat einige Nachteile.

Benutzer und Mitwirkende können damit rechnen, dass Gutenberg-Funktionen möglicherweise langsamer in den Kern integriert werden, da sie sich nicht auf experimentelle APIs verlassen können, wenn sie in Hauptversionen zur Hauptsendezeit verbreitet werden. Zielinski merkte auch an, dass Mitwirkende auch Schwierigkeiten haben könnten, diese APIs umzugestalten, sobald sie ausgeliefert wurden und auf Millionen von WordPress-Sites verwendet werden.

Bisher hat der Vorschlag überwältigend positive Unterstützung erfahren, da viele der Meinung sind, dass diese APIs niemals im Kern hätten ankommen sollen, solange sie sich noch in der experimentellen Phase befinden.

„Ich bin sehr für diesen Ansatz“, sagte WordPress-Entwickler Mark Root-Wiley. „Ich erstelle benutzerdefinierte Themen und habe ein paar einfache Plugins. Bei beiden musste ich mich häufig mit experimentellen APIs und den Schwierigkeiten auseinandersetzen, mit ihnen auf dem Laufenden zu bleiben, wenn Funktionen in den Kern aufgenommen wurden, die nur durch eine experimentelle API deaktiviert, angepasst oder erweitert werden können.“

„Eine Rückkehr zu dieser Art von Stabilität im Kern würde viel dazu beitragen, den guten Willen der Entwickler zurückzugewinnen“, kommentierte WordPress-Mitarbeiter Dovid Levine den Vorschlag.

Die Frist für die Kommentierung des Vorschlags ist der 7. September, womit die Diskussion knapp drei Wochen vor der erwarteten Beta 1 von WordPress 6.1 abgeschlossen wäre. Dies gibt den Mitwirkenden etwas Zeit, um die experimentellen APIs vor der nächsten Hauptversion eingehender zu prüfen, falls sie einen Konsens darüber erzielen, sie auf das Gutenberg-Plugin zu beschränken.