WordPress 核心字段 API 項目正在尋求新的領導力
已發表: 2018-07-262014 年，Pods 首席開發人員 Scott Kingsley Clark 接任元數據 UI 項目的主要負責人。 2015 年，元數據 UI 項目重生為 Fields API。
字段 API 的開發允許通過單個 API 將字段註冊到管理區域中的不同屏幕。 新的元框和其中的字段可以添加到帖子中，而新的部分和字段可以添加到個人資料屏幕。
API 的目標是與所有各種管理屏幕集成，包括帖子、條款、用戶、媒體和評論，並提供標準化。
克拉克已經領導該項目三年了，儘管去年看到了新的興趣，但在該項目的 Slack 頻道中宣布他將辭職。
我必須懷著沉重的心情在這個項目上傳遞火炬。 經過數百小時的工作，我不再相信我可以在 WordPress 核心中進行更改。
Fields API 的願景太大了，對任何人來說都是一項艱鉅的任務。 我深信 WordPress 需要一個 Fields API，但我們使用 Fields API 的旅程是漫長而艱鉅的。
事實是，幾年前我在構建第一個和第二個原型時精疲力盡。 不是每個人都同意如何構建代碼，它根據核心貢獻者的反饋經歷了許多修訂。 我只是無法讓足夠多的人對此感到興奮，我無法獲得足夠多的公司和有興趣支持它的人。
我需要讓別人有機會，我把它拖下來了。 如果將來有人挺身而出，那麼我很樂意在力所能及的地方提供幫助。 但我無法繼續領導 Fields API 提案/項目。 對不起，請接受我的道歉，我希望你能原諒我沒有把這個項目帶過終點線。 我仍然相信它是 WordPress 未來成功的重要組成部分。
斯科特·金斯利·克拉克
領導一個開源項目的考驗和磨難
在接下來的採訪中，克拉克解釋了為什麼他對項目缺乏進展感到個人負責，為什麼 API 對 WordPress 的未來很重要，並反思了他可以做些什麼不同的事情。
您是否希望將火炬特別傳遞給任何人？
不，我不確定誰有動力和影響力來完成這個項目。 這是一個大型項目，應該以長遠的眼光來對待，但增量要足夠小，以使其成為 WordPress 核心。 對某人有很多要求，現在這也不是人們的優先事項，因為他們被古騰堡在不久的將來發布而分心。
為什麼 Fields API 是 WordPress 未來的重要組成部分？
今天人們看著 WordPress，想知道他們是如何在沒有 REST API 的情況下生存下來的。 好吧，至少我知道我知道！ Fields API 也可以這樣說，儘管它還沒有出現。 在很多情況下，跨所有不同的鉤子為 WordPress 構建解決方案是令人沮喪的。
為了保持一致性，這裡是狂野的西部。 您註冊了一個元框，然後用您想要的任何內容填充它。 您需要自己的 CSS 來設置表單字段的樣式，並且每個人對這個界面的外觀都有自己的想法。 您負責自己的響應式佈局，這些佈局對移動設備友好，您必須自己處理很多事情。 您應該能夠自定義外觀，但是您想要添加字段或表單的每個地方都應該有適當的 API。
從長遠來看，想像一下將字段註冊到 WordPress，就像您註冊帖子類型一樣。 想像一下字段及其配置可用於 REST API，並可通過 WordPress 應用程序或其他自定義應用程序訪問。
整個世界都是開放的，因為您擁有一致的 API，整個世界才有意義，因為您在各個編輯屏幕上為這些字段提供了一致的界面。 帖子、術語、評論、用戶、媒體，甚至定制器都將具有相同的底層 API 來將組、面板和字段添加到他們的屏幕。
如果 Gutenberg 是在 Fields API 出現之後完成的，那麼人們的遷移就不會那麼困難了。 Gutenberg 可以自動顯示所有 Fields API 接口，就像它為元框向後兼容所做的那樣。 它看起來也會更好。
花點時間思考一下，你可以做些什麼不同的事情來讓更多的核心貢獻者加入這個項目並將其變成一個更高的優先級？
我不確定，這是接受輸入和對最終結果充滿信心之間的微妙平衡。 起初，反饋是關於 API 對 WordPress 來說是多麼陌生，他們詢問它是否可以在結構上與其他 API 相似，例如 Customizer。
我們廢棄了代碼並從頭開始重建為定制器的一個分支，它甚至支持讓定制器也使用字段 API。 在開發的高峰期，我們已經實現了 Fields API 的所有領域。
核心版本進展得非常快，從 WordPress 版本到版本之間有很多代碼更改，我們必須跟上，因為我們基本上創建了一個項目，它是 WordPress 的一個巨大補丁。
沒有足夠的鉤子來做我們需要做的事情，而且由於代碼決定將自己標記為“最終”，因此許多部分不可擴展，這意味著您無法擴展特定類來自定義它的工作方式。
我希望我能參加美國和歐洲的所有大型 WordCamps，基本上是為這個功能遊說。 聚集支持者等等，在某種程度上感覺像是政治。 我在核心開發會議上閒逛，試圖提出來。 我試圖通過在官方 WordPress Slack 中建立一個專用頻道、在 https://make.wordpress.org/core/ 上發布更新以及每週召開會議來使該功能合法化。
最終，我優先考慮我的發展時間，而不是集結部隊的時間。 那是失敗，在最初的幾次重寫之後，我開始很快筋疲力盡，因為我在 Fields API 的其他地方還有許多其他職責。
儘管 WebDevStudios 和 10up 都給了我時間來推動它，但公司不會輕易地願意付錢讓你無限期地從事這樣的項目。 這不是一張空白支票，在某些時候我不得不重新開始計費工作。 從那時起，這一切都在我的空閒時間，在財務壓力和房屋買賣/購買期間很難管理。
核心需要一個 Fields API，但沒有足夠的人手來構建它。 你認為這是為什麼？
每個人都專注於別處。 WordPress有很多領域需要人們關注。 像可訪問性這樣的東西值得比它得到更多的關注。 但對我來說，重點似乎是 Gutenberg 和 REST API。
古騰堡尤其是人們貢獻和實施的巨大時間。 這是一個非常大的功能。 它的規模肯定比 Fields API 更大，就像一個全新的應用程序存在於 WordPress 中。 與它的集成需要大量的教育和試錯。 人們的關注點是現在需要的地方。 不幸的是，Gutenberg 在優先級和興趣級別方面排在 Fields API 之前。
您會給下一位 Fields API 項目負責人甚麼建議？
這是一個大工程，大家都會想說應該有一定的方式。 您必須評估選項並提出一些適合核心開始的小東西。 以此為基礎，但永遠不要忽視跨所有 WordPress 屏幕集成的長期目標。 即使是前端評論表單也可以通過 Fields API 蓬勃發展。
為什麼你覺得對項目負有個人責任而不是核心優先事項？
在某一時刻，我們有動力。 我們至少有三到四個活躍的人。 它崩潰了，因為我沒時間了。 這是我的短視，是我的錯。 在幾年的時間裡，我花了數百個小時來開發這個項目。 我應該給自己留更多的時間來組織功能提案文本並讓我們的貢獻者心中燃燒著火焰。
考慮到您在過去幾年為該項目投入的時間和精力，您是否有種將火炬傳遞下去的輕鬆感？
如果火炬被傳遞或撿起，我會感覺好很多。 主要的緩解是，它正式不再是我必須獨自攜帶的重量。 嘗試失敗沒關係，但仍然很悲傷。
我希望某人或某家公司能站出來並投入時間。 他們甚至可以重新點燃我自己心中燃燒的火焰。 現在，我少了一項主要的待辦事項。 我仍然有一個沉重的盤子，但它不再是那麼沉重的負擔。
雖然該項目的近期未來尚不清楚，但鼓勵有興趣接管它的人閱讀 Make.WordPress.Core 上標有 Fields API 標籤的帖子，以了解其歷史。 您還可以查看項目的 Github 頁面。
如果您有興趣接管該項目，您可以在 Twitter、Slack 或通過他的網站聯繫 Clark。