Das WordPress Core Fields API-Projekt sucht neue Führung

Im Jahr 2014 übernahm der leitende Entwickler von Pods, Scott Kingsley Clark, die primäre Führungsrolle für das Metadaten-UI-Projekt. Im Jahr 2015 wurde das Metadaten-UI-Projekt als Fields-API wiedergeboren.

Die Fields-API wurde entwickelt, um die Registrierung von Feldern auf verschiedenen Bildschirmen im Admin-Bereich über eine einzige API zu ermöglichen. Neue Meta-Boxen und darin enthaltene Felder könnten zu Beiträgen hinzugefügt werden, während neue Abschnitte und Felder zum Profilbildschirm hinzugefügt werden könnten.

Das Ziel der API ist die Integration mit allen verschiedenen Verwaltungsbildschirmen, einschließlich Beiträgen, Bedingungen, Benutzern, Medien und Kommentaren, und die Bereitstellung einer Standardisierung.

Clark leitet das Projekt seit drei Jahren und gab trotz erneutem Interesse im letzten Jahr im Slack-Kanal des Projekts bekannt, dass er zurücktritt.

Schweren Herzens muss ich die Fackel für dieses Projekt weitergeben. Nach Hunderten von Stunden meiner Zeit glaube ich nicht mehr, dass ich Änderungen im WordPress-Kern bewirken kann.

Die Fields-API-Vision war zu groß, zu viel Aufwand für eine einzelne Person. Ich bin fest davon überzeugt, dass WordPress eine Fields-API braucht, aber der Weg dorthin, wo wir mit der Fields-API stehen, war lang und beschwerlich.

Die Wahrheit ist, dass ich vor Jahren beim Bau des ersten und zweiten Prototyps ausgebrannt bin. Nicht alle waren sich einig, wie der Code gestaltet werden sollte, er durchlief viele Überarbeitungen, basierend auf dem Feedback der wichtigsten Mitwirkenden. Ich konnte einfach nicht genug Leute dafür begeistern, ich konnte nicht genug Unternehmen und Leute dazu bringen, sich dafür zu interessieren, es zu unterstützen.

Ich muss jemand anderem ihre Chance lassen, ich ziehe sie herunter. Wenn in Zukunft jemand die Führung übernimmt, helfe ich gerne, wo ich kann. Aber ich bin nicht in der Lage, den Fields-API-Vorschlag/das Projekt weiter zu leiten. Es tut mir leid, bitte akzeptieren Sie meine Entschuldigung und ich hoffe, Sie können mir verzeihen, dass ich dieses Projekt nicht über die Ziellinie gebracht habe. Ich glaube immer noch, dass es ein so wichtiger Teil des zukünftigen Erfolgs von WordPress ist.

Scott Kingsley Clark

Die Irrungen und Wirrungen der Leitung eines Open-Source-Projekts

Im folgenden Interview erklärt Clark, warum er sich persönlich für den mangelnden Fortschritt des Projekts verantwortlich fühlt, warum die API für die Zukunft von WordPress wichtig ist und überlegt, was er hätte anders machen können.

Möchten Sie die Fackel an eine bestimmte Person weitergeben?

Nein, ich bin mir nicht sicher, wer den Antrieb und die Schlagkraft haben würde, das Projekt durchzuziehen. Es ist ein groß angelegtes Projekt, das mit einer langfristigen Vision angegangen werden sollte, aber in kleinen Schritten, um es in den WordPress-Kern zu schaffen. Es ist viel verlangt von jemandem, es hat für die Leute im Moment auch keine Priorität, da sie durch die baldige Veröffentlichung von Gutenberg abgelenkt sind.

Warum ist die Fields-API ein wichtiger Bestandteil der Zukunft von WordPress?

Die Leute schauen sich heute WordPress an und fragen sich, wie sie jemals ohne die REST-API überlebt haben. Nun, zumindest weiß ich, dass ich es tue! Das Gleiche gilt für die Fields-API, obwohl sie noch nicht da ist. Es gibt so viele Fälle, in denen es frustrierend ist, Lösungen für WordPress über all die verschiedenen Hooks hinweg zu erstellen.

Der Konsistenz halber ist es der Wilde Westen da draußen. Sie bekommen eine Meta-Box registriert und füllen sie mit allem, was Sie wollen. Sie benötigen Ihr eigenes CSS, um die Formularfelder zu gestalten, und jeder hat seine eigene Vorstellung davon, wie diese Oberfläche aussehen soll. Sie sind für Ihre eigenen responsiven Layouts verantwortlich, die für Mobilgeräte geeignet sind, es gibt einfach so viel, was Sie selbst erledigen müssen. Sie sollten in der Lage sein, das Erscheinungsbild anzupassen, aber jeder Ort, an dem Sie ein Feld oder Formular hinzufügen möchten, sollte wirklich eine geeignete API haben.

Stellen Sie sich langfristig vor, Felder in WordPress zu registrieren, wie Sie Beitragstypen registrieren. Stellen Sie sich vor, dass Felder und ihre Konfigurationen für die REST-API verfügbar und über die WordPress-App oder andere benutzerdefinierte Apps zugänglich sind.

Die ganze Welt öffnet sich, weil Sie eine konsistente API haben, die ganze Welt macht Sinn, weil Sie eine konsistente Schnittstelle für diese Felder über die verschiedenen Bearbeitungsbildschirme hinweg haben. Posts, Begriffe, Kommentare, Benutzer, Medien und sogar der Customizer hätten alle die gleiche zugrunde liegende API, um Gruppen, Panels und Felder zu ihren Bildschirmen hinzuzufügen.

Wenn Gutenberg nach Einführung der Fields-API erstellt worden wäre, wäre die Migration für die Leute nicht so schwierig gewesen. Gutenberg hätte automatisch alle Fields-API-Schnittstellen anzeigen können, wie es für die Abwärtskompatibilität der Meta-Box der Fall ist. Es hätte auch viel schöner ausgesehen.

Nehmen Sie sich etwas Zeit zum Nachdenken, was hätten Sie anders machen können, um mehr wichtige Mitwirkende für das Projekt zu gewinnen und es zu einer höheren Priorität zu machen?

Ich bin mir nicht sicher, es ist ein heikles Gleichgewicht zwischen Input und Vertrauen in das Endergebnis. Zunächst ging es bei dem Feedback darum, wie fremd die API für WordPress sei, sie fragten, ob sie in ihrer Struktur anderen APIs wie dem Customizer ähnlich sein könnte.

Wir haben den Code verschrottet und von Grund auf als Fork des Customizers neu erstellt, es unterstützte sogar, dass der Customizer auch die Fields-API verwendet. Auf dem Höhepunkt der Entwicklung hatten wir alle Bereiche der Fields API implementiert.

Core-Releases gingen ziemlich schnell voran, es gab viele Codeänderungen von WordPress-Release zu Release, mit denen wir Schritt halten mussten, weil wir im Wesentlichen ein Projekt erstellt hatten, das ein riesiger Patch für WordPress war.

Es waren nicht genügend Hooks vorhanden, um das zu tun, was wir tun mussten, und viele Abschnitte waren aufgrund von Codeentscheidungen, die sich selbst als „endgültig“ markierten, nicht erweiterbar, was bedeutet, dass Sie eine bestimmte Klasse nicht erweitern können, um ihre Funktionsweise anzupassen.

Ich wünschte, ich hätte bei all den großen WordCamps in den USA und Europa dabei sein und mich im Wesentlichen für dieses Feature einsetzen können. Unterstützer und so zu sammeln, fühlt sich in gewisser Weise wie Politik an. Ich hing in Core-Dev-Meetings herum und versuchte, es zur Sprache zu bringen. Ich habe versucht, das Feature zu legitimieren, indem ich einen eigenen Kanal im offiziellen WordPress Slack habe, Updates auf https://make.wordpress.org/core/ poste und wöchentliche Meetings abhalte.

Letztendlich habe ich meiner Zeit für die Entwicklung Vorrang vor der Zeit gegeben, die Truppen zu sammeln. Das war der Untergang, ich begann nach den ersten Umschreibungen schnell auszubrennen, da ich neben der Fields-API noch viele andere Aufgaben an anderer Stelle hatte.

Es ist nicht so, dass Unternehmen Sie einfach dafür bezahlen wollen, auf unbestimmte Zeit an einem Projekt wie diesem zu arbeiten, obwohl sowohl WebDevStudios als auch 10up mir Zeit gaben, es voranzutreiben. Es war kein Blankoscheck, irgendwann musste ich wieder zu abrechenbarer Arbeit. Von da an war alles in meiner Freizeit und das war in Zeiten von finanziellem Stress und Hausverkauf/-kauf nur schwer zu bewältigen.

Es besteht eine Nachfrage nach einer Fields-API im Kern, aber nicht genügend Hände, um sie zu erstellen. Warum denkst Du, das ist?

Jeder konzentriert sich auf etwas anderes. Es gibt viele Bereiche von WordPress, die die Aufmerksamkeit der Leute erfordern. Es gibt Dinge wie Barrierefreiheit, die viel mehr Aufmerksamkeit verdienen, als sie bekommt. Aber der Fokus scheint mir auf Gutenberg und REST API zu liegen.

Besonders Gutenberg war ein enormer Zeitfresser für Menschen, die Beiträge leisteten, und Menschen, die etwas umsetzten. Es ist ein wirklich großes Feature. Es ist definitiv größer als die Fields-API, es ist wie eine ganz neue App, die in WordPress lebt. Die Integration damit erforderte viel Bildung und Trial/Error. Der Fokus der Menschen liegt dort, wo er gerade sein muss. Es ist nur bedauerlich, dass Gutenberg in Bezug auf Priorität und Interesse vor Fields API kam.

Welchen Rat würden Sie dem nächsten Fields-API-Projektleiter geben?

Dies ist ein großes Projekt, jeder wird sagen wollen, dass es auf eine bestimmte Art und Weise sein sollte. Sie müssen die Optionen bewerten und etwas Bissiges für den Kern vorlegen, um damit zu beginnen. Bauen Sie darauf auf, verlieren Sie aber nie das langfristige Ziel der Integration über alle WordPress-Bildschirme hinweg. Sogar die Front-End-Kommentarformulare könnten mit der Fields-API gedeihen.

Warum fühlen Sie sich persönlich dafür verantwortlich, dass das Projekt keine Kernpriorität ist?

Irgendwann hatten wir Schwung. Wir hatten mindestens drei bis vier Leute, die aktiv waren. Es fiel auseinander, weil ich keine Zeit mehr hatte. Es ist meine Kurzsichtigkeit, es ist meine Schuld. Ich habe Hunderte von Stunden damit verbracht, das Projekt über ein paar Jahre zu entwickeln. Ich hätte mir viel mehr Zeit nehmen sollen, um den Feature-Proposal-Text zu organisieren und das Feuer in den Herzen unserer Mitwirkenden am Brennen zu halten.

Wenn Sie bedenken, wie viel Zeit und Mühe Sie in den letzten Jahren in das Projekt gesteckt haben, fühlen Sie sich erleichtert, die Fackel weiterzugeben?

Wenn die Fackel weitergegeben oder aufgehoben wird, fühle ich mich viel besser. Die Haupterleichterung ist, dass es offiziell kein Gewicht mehr ist, das ich alleine tragen muss. Es ist okay, es zu versuchen und zu scheitern, aber es ist trotzdem traurig.

Ich hoffe, dass jemand oder ein Unternehmen auftaucht und Zeit investiert. Sie könnten sogar das Feuer in meinem eigenen Herzen wieder entfachen, das sich selbst ausgebrannt hat. Im Moment habe ich eine wichtige Aufgabe weniger. Ich habe immer noch einen kräftigen Teller, aber er ist nicht mehr so ​​schwer wie eine Last.

Während die unmittelbare Zukunft des Projekts unklar ist, werden diejenigen, die daran interessiert sind, es zu übernehmen, ermutigt, Beiträge zu lesen, die mit dem Fields-API-Tag auf Make.WordPress.Core gekennzeichnet sind, um mehr über seine Geschichte zu erfahren. Sie können sich auch die Github-Seite des Projekts ansehen.

Wenn Sie daran interessiert sind, das Projekt zu übernehmen, können Sie Clark auf Twitter, Slack oder über seine Website kontaktieren.