Table of Contents generated with DocToc
- Not all control types are working including Media and Color. We need to put additional effort into the JS side of things.
- Create merge proposal for WordPress 4.8 and path towards implementing Fields API into various admin areas.
@sc0ttkclark, @technosailor
- Our internal implementation of the Edit User screen replaces core's entirely using the Fields API.
- Backwards compatible with existing actions and hooks being used to extend the Edit User screen.
- Add custom markup and styling to match uniform layout.
@sc0ttkclark, @brentvr
- Our internal implementation of the Edit Post screen will replace core's entirely using the Fields API.
- Backwards compatible with some existing actions and hooks being used to extend the Edit Post screen.
- Create Basic Starter example code.
- Create example use-case(s) and code.
- Register sections / controls based on what's on the Post Editor screen currently.
- Add additional output type for outputting a section with no meta box.
- Complete backwards compatibility with existing actions and hooks.
@sc0ttkclark, @technosailor
- Our internal implementations of the Add Term and Edit Term screen replaces core's entirely using the Fields API.
- Backwards compatible with existing actions and hooks being used to extend the Add Term and Edit Term screens.
- Create example use-case(s) and code.
@sc0ttkclark
- Our internal implementation of the Edit Comment screen will replace core's entirely using the Fields API.
- Backwards compatible with some existing actions and hooks being used to extend the Edit Comment screen.
- Create Basic Starter example code.
- Create example use-case(s) and code.
- Register sections / controls based on what's on the Comment Editor screen currently.
- Add additional output type for outputting a section with no meta box.
- Complete backwards compatibility with existing actions and hooks.
@sc0ttkclark, @technosailor
- Our internal implementation of the Settings pages replace core's entirely using the Fields API.
- Register Sections and Fields to Settings API based on what's been registered to the Fields API
- Settings API calling Fields API for config and rendering, not testable because functions can't be overridden in wp-admin/includes/template.php
- Implementations for Discussion and Media settings pages.
- Create Basic Starter example code.
- Create example use-case(s) and code.
- Create custom control types for some of the advanced / unique inputs.
@nicholasio, @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.
WP_Widgetintegration- Create Basic Starter example code.
- Create example use-case(s) and code.
@diddledan, @sc0ttkclark
- Our internal implementation 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.
- Create Basic Starter example code.
- Create example use-case(s) and code.
- More compatibility work for CSS
- Look into Customizer integration
- Getting / saving values for nav menu item fields
Looking for contributors
- Add sections and controls to Media Edit
- Add sections and controls to Media Modal Add / Edit
- Create Basic Starter example code.
- Create example use-case(s) and code.
@sc0ttkclark
- 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 and building in addition configurations the REST API can consume for it's endpoint(s).