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。