Fields API — Where we’re at ![rw-book-cover](https://s.w.org/images/backgrounds/wordpress-bg-medblue.png) ## Metadata - Author: [[Make WordPress Core]] - Full Title: Fields API — Where we’re at - Category: #articles - Summary: Over the past few months, we’ve been working towards one of the most wide-reaching API’s to be suggested for core inclusion, apart from the REST API. It has the potential to touch nearly every area of WordPress that deals with forms and fields. - URL: https://make.wordpress.org/core/2016/03/14/fields-api-where-were-at/ Over the past few months, we’ve been working towards one of the most wide-reaching API’s to be suggested for core inclusion, apart from the REST API. It has the potential to touch nearly every area of WordPress that deals with forms and fields. The *Fields API* is nearly there, and we’re seeking more feedback on a number of areas we need to tie down before we go into the official proposal stage for core inclusion. ##### What is the Fields API? We just published [a specification for the Fields API](https://make.wordpress.org/core/2016/03/11/a-specification-for-the-fields-api/) last week and we’re seeking constructive feedback on that now. Please take a moment to read about it, ask questions, and voice your concerns with us so we can address those things before we go to the next official stage. There’s also some helpful [docs](https://github.com/sc0ttkclark/wordpress-fields-api/tree/develop/docs) which include [Terminology](https://github.com/sc0ttkclark/wordpress-fields-api/blob/develop/docs/terminology.md), [Registration of fields](https://github.com/sc0ttkclark/wordpress-fields-api/blob/develop/docs/registering-fields-shorthand.md), and [example code](https://github.com/sc0ttkclark/wordpress-fields-api/tree/develop/docs/examples). ##### What can you do with the Fields API right now? We’ve put together a number of implementations to show the potential of what the Fields API can accomplish inside of core. Each implementation is an example of what *could* end up in WordPress core, should the Fields API itself be merged. * **Edit User screen** ([@sc0ttkclark](https://profiles.wordpress.org/sc0ttkclark/), [@technosailor](https://profiles.wordpress.org/technosailor/)) + Our [internal implementation](https://github.com/sc0ttkclark/wordpress-fields-api/blob/develop/implementation/wp-includes/fields-api/forms/class-wp-fields-api-form-user-edit.php) of the Edit User screen replaces core’s entirely using the Fields API. + Here’s [a code example](https://github.com/sc0ttkclark/wordpress-fields-api/blob/master/docs/examples/user/address.php) to add more fields (and sections and controls) to the Edit User screen + Backwards compatibility hooks + **To-do:** Further custom markup and/or styling to match uniform layout * **Edit Post screen** ([@sc0ttkclark](https://profiles.wordpress.org/sc0ttkclark/), [@brentvr](https://profiles.wordpress.org/brentvr/)) + Our [internal implementation](https://github.com/sc0ttkclark/wordpress-fields-api/blob/develop/implementation/wp-includes/fields-api/forms/class-wp-fields-api-form-post.php) of the Edit Post screen will replace core’s entirely using the Fields API, we only have support for adding new sections / controls right now + **To-do:** Register sections / controls based on what’s on the Post Editor screen currently ([@brentvr](https://profiles.wordpress.org/brentvr/) is working on this now) + **To-do:** Add additional output types (no meta box, etc) + **To-do:** Backwards compatibility hooks * **Comment Edit** ([@sc0ttkclark](https://profiles.wordpress.org/sc0ttkclark/)) + Our [internal implementation](https://github.com/sc0ttkclark/wordpress-fields-api/blob/develop/implementation/wp-includes/fields-api/forms/class-wp-fields-api-form-comment.php) of the Edit Comment screen will replace core’s entirely using the Fields API, we only have support for adding new sections / controls right now + **To-do:** Register sections / controls based on what’s on the Comment Editor screen currently + **To-do:** Add additional output types (no meta box, etc) + **To-do:** Backwards compatibility hooks * **Settings Pages** ([@sc0ttkclark](https://profiles.wordpress.org/sc0ttkclark/), [@technosailor](https://profiles.wordpress.org/technosailor/)) + Our internal implementation of the Settings page screens replaces core’s entirely using the Fields API + We are working on adding these - **To-do:** Discussion - **To-do:** Media + [Settings API calling Fields API for config and rendering](https://github.com/sc0ttkclark/wordpress-fields-api/blob/develop/implementation/wp-admin/includes/template.php) (not testable, functions can’t be overridden in wp-admin/includes/template.php) + **To-do:** Custom control types for some of the advanced / unique inputs * **Widget Forms** ([@nicholasio](https://profiles.wordpress.org/nicholasio/), [@sc0ttkclark](https://profiles.wordpress.org/sc0ttkclark/)) + Our internal implementation of the Widget forms will integrate with WP\_Widget to allow form fields to be registered for widgets and rendered/saved automatically without the custom code *every* widget ends up needing currently. * **Nav Menu Items** ([@diddledan](https://profiles.wordpress.org/diddledan/), [@sc0ttkclark](https://profiles.wordpress.org/sc0ttkclark/)) + Our [internal implementation](https://github.com/sc0ttkclark/wordpress-fields-api/pull/68) of the Nav Menu Items overrides the core Walker class used for building the Nav Menu Item forms, and uses the Fields API to output registered controls. + **To-do:** More compatibility work for CSS + **To-do:** Look into Customizer integration + **To-do:** Getting/saving values for nav menu item fields * **Media** + We do not currently have an implementation for this yet, but one was proposed by [@wpsmith](https://profiles.wordpress.org/wpsmith/), and we are seeking additional help from anyone looking to make this happen + **To-do:** Add sections and controls to Media Edit + **To-do:** Add sections and controls to Media Modal Add/Edit * **REST API** + We currently have limited direct integration with the REST API, but we’d like to work with the REST API team towards [implementing REST API options](https://github.com/sc0ttkclark/wordpress-fields-api/issues/39) and building in addition configurations the REST API can consume for it’s endpoint(s) + register\_rest\_field integration ##### Possible Roadmap to Merge Here’s an example of how Fields API could eventually be merged into core, along with other implementations. * **Release 1:** Merge Fields API into core * **Release 2:** Merge Implementation 1 into core * etc.. So each release could focus on a different implementation, which of course is a great time to coincide to UX / design work on each area, like the User Profile screen. There’s lots of options here, but hey, let’s discuss it! ##### How to help If you’d like to help anywhere, please just reach out and I’ll get you into it. Every area needs review, some areas still need more work to finish, but any area could use additional help. So who do you contact or where do you go to help? ##### Next Meeting Agenda – March 14th, 2016 Our next meeting is [Monday, December 7, 2015, 08:00 PM UTC](https://www.timeanddate.com/worldclock/fixedtime.html?iso=20151207T2000) and it promises to be eventful. We plan on discussing a number of things including:, Fields API — Where we’re at, Make WordPress Core, 01gnmcy8f1kea2zrye1eavvqq9.