The Fields API.

Never heard of it? That’s OK. Outside of the inner development community, it is not widely known. The average WordPress user does not need to know about it. Before understanding how the Fields API fits into Gutenberg’s future, you must first understand what it is and the problems it was meant to fix.

The Fields API was a proposed solution to one of WordPress’ biggest problems: to build form fields in the admin and save data from those fields, developers need to know multiple APIs, depending on the specific admin screen.

Want to build a plugin settings screen? Use the Settings API.

Need some theme options? Build them with the Customize API.

Have some fields to output on the user screen? Here are two hooks and a mess of HTML table markup; sorry, no official API.

Those are just a few examples, but the truth of it comes down to this: to show something as basic as a text field to end-users, WordPress developers need to know how to do this in a variety of ways based on competing or even missing APIs.

There are historical reasons for this. New features were bolted on top of WordPress over time. In the mad rush to continue shipping features with each major update, few people stepped back and asked the fundamental question about the technical debt that would pile up over the past 16 years. Shipping end-user features helped the platform grow, but developers had to learn all-new functions and methods each time.

Adding to the technical burden, when the Gutenberg project launched, it introduced a new system in a different programming language.

The Fields API would have created a standardized system for outputting form fields and saving field data. It would work with all the existing admin screens and any new features added in the future. Developers could learn a single system and be able to build plugins that worked with practically any area of WordPress.

In 2014, Scott Kingsley Clark took over the Metadata UI Project. The initial idea was to create an API for adding custom fields (meta box fields) on the post-editing screen. Eventually, Clark and those working on the project realized the problem that needed solving was larger than meta boxes. WordPress needed an API that worked across the board. After a year, the project was relaunched as the Fields API.

After years of working on the code behind the project, Clark became burned out. He stepped down as the project’s lead in 2018. With no buy-in from the decision-makers for the WordPress project, there was little hope of it making it into core. At that point, the project was all but dead.

Gutenberg’s development was in full swing. Developers were gearing up for relearning how to add the same basic text fields and other form elements in whole new ways.

The Fields API, had it made it into WordPress before the block editor, could have alleviated the need for developers to learn a new system. However, that’s not where we’re at today. The Fields API never made it past the gatekeepers, and developers have one more thing to stay knowledgeable on.

The question is: how do we address this going forward?

How the Gutenberg Project Can Solve the Fields API Problem

What many don’t understand is that the Gutenberg project is larger than the content editor. The first iteration, Phase 1, of the project was to create a new editing experience. Phase 2 will create new admin screens for site editing using the same components for the editor. Custom text fields, select dropdowns, color options, or one of many other field types all run through the same reusable, component-based system.

That sounds remarkably similar to the Fields API. At the end of the day, the Fields API is simply a standardized method of reusing components to output form fields and save data, regardless of the screen in WordPress.

WordPress needs to be rebuilt from the ground up. Gutenberg provides us the opportunity to rewrite every admin page in WordPress using a standardized system for handling form fields.

From a technical standpoint, Gutenberg has dozens of components. These include a text control, button, checkbox, and much more. It covers the majority of use cases plugin and theme authors need for form fields. These things are not tied directly to the block system. They are simply components that can be used anywhere.

The next step would be setting the foundational layer for other admin screens. It will not be easy. There will be backward-compatibility mountains that the Fields API could have climbed for us years ago.

Given WordPress’ history, developers will likely continue using competing APIs for fields on various admin pages. And, if we’re still at that point in five years, the Gutenberg project will have failed for not going as far as it could have.

For success, the Gutenberg project needs to have a wider vision and a longer-term roadmap that addresses the issues of fields on every screen. Otherwise, projects with easier-to-learn APIs will be more enticing to developers.

The idea of Gutenberg-ifying the entirety of the WordPress admin will be off-putting to many, but WordPress has to solve its form fields issue at some point. It might as well reuse the components that will be seeing active development for years to come.