Fields API Chat Summary: September 13th, 2023

These are the notes from the first post-WCUS chat we had on Thursday, September 13th, 2023 at 12:00 PM CDT in the #core-fields channel of Make WordPress Slack.

Key Links

Proposed agenda items

A few agenda items were proposed in the channel by @alexstandiford including the following items. (Marked to show what we ended up getting through so far)

  1. ☑ Broadly speaking, what is the scope for V1?
  2. ☐ Can we define the independent pieces of this project? If not, what do we need to know in order to understand those pieces?
  3. ☐ Is it realistic to expect that we could split this project into smaller pieces, lead by groups of the contributors?
  4. ☐ How do we approach presenting this to coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.? How often to we provide updates?
  5. ☐ General discussion around the findings and conclusions surrounding the JSON fields API pitch. Could defining the JSONJSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML. help us understand the components that make the fields APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways.?

What we talked about in the chat

We ended up spending over an hour discussing only that first item: What we as contributors think that V1 should and should not include. Feedback was varied so I gathered the list of things people came up with and turned that into a survey that contributors could vote on.

Survey: What to include in a V1 proposal

We also invite everyone in the community to provide feedback on what you think the V1 proposal for Fields API should include.

Fill out the survey to let us know what you’d like to see in a V1 of the Fields API

The survey will close on Wednesday, September 20th, 2023 at 12:00 PM (UTC-5) and we will share the results in the planned Fields API chat that day.

Remaining areas to research

We still have a few more screens to add research documentation for and those are these:

  • Users
    • User registration form
  • Media – Media modal
  • CustomizerCustomizer Tool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings. API – @sc0ttkclark will take this on
  • Nav Menus (classic)
    • Name Menu form
    • Nav Menu Item form

If you’d like to help out, hop into #core-fields and or GitHub repository and let us know what area you’d like to contribute to.

Next scheduled chat

We will be meeting again in #core-fields on Wednesday, September 20th, 2023 at 12:00 PM (UTC-5)

See many of you then!

#feature-plugins, #fields-api, #options-meta, #summary

Fields API Progress Summary: WCUS Contributor Day 2023

We had a solid day of progress today at the WCUS Contributor DayContributor Day Contributor Days are standalone days, frequently held before or after WordCamps but they can also happen at any time. They are events where people get together to work on various areas of https://make.wordpress.org/ There are many teams that people can participate in, each with a different focus. https://2017.us.wordcamp.org/contributor-day/ https://make.wordpress.org/support/handbook/getting-started/getting-started-at-a-contributor-day/.. I sat down at an empty table and before long it was full of people who were eager to help bring the vision of the Fields APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. to fruition.

If you aren’t familiar yet with what we’ve been planning, check out the post below about the kick-off we had at the start of this year. Otherwise, continue on below to see what we’ve accomplished and what’s left in the Research phase.

Progress at Contributor Day

Research has continued and we now have docs for many of the areas we had planned plus new areas we discovered together.

Research docs

  • Settings API@joedolson (ahead of Contributor Day)
  • Meta Box API@sc0ttkclark
  • List Tables@codearachnid
    • ✅ Quick Edit
    • ✅ Custom Columns
  • Taxonomies@wvega
    • ✅ Add term form
    • ✅ Edit term form (separate from the Add term form in how you work with it)
  • Users
    • User profile@ohryan
    • Add new user form
    • Add new user form (/networknetwork (versus site, blog)/ variation)
    • Add existing user to site form (Multisitemultisite Used to describe a WordPress installation with a network of multiple blogs, grouped by sites. This installation type has shared users tables, and creates separate database tables for each blog (wp_posts becomes wp_0_posts). See also network, blog, site)
  • Media – Media modal
  • Comments – Add new comment (front of site) – @cr0ybot
  • BlockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. Editor
  • CustomizerCustomizer Tool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings. API
  • Nav Menus (classic)
    • Name Menu form
    • Nav Menu Item form
  • Widgets (classic)@cr0ybot

Proposal draft work

We also had help from @lauriewood who spent time writing a proposal draft for us that we can use to build from with more technical details.

Comparison sheet

I put together a comparison sheet that goes over coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. APIs vs a few popular plugins. It may help you visualize what we are doing here.

What’s next?

Our next meeting

We’re going to set up another meeting in #core-fields on SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. in September to get everyone together again. I’ll post here again as soon as we have a time set so others who are interested can join.

Research will continue

We have a few more docs to continue working on. We will coordinate who does what in the #core-fields Slack channel. If you’re interested in helping, feel free to mention me (@sc0ttkclark) there!

Proposing the Fields API

We will then be able to officially propose the Fields API based on our research and gather feedback on what we’ve put together. The proposed code will likely remain similar to what was proposed in 2017 but with more modern PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher 7+ code and potentially support for JSONJSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML. schema files if there’s appetite in core to expand beyond the Blocks JSON schema implementation and into other config areas.

#feature-plugins, #fields-api, #options-meta, #summary

Fields API Kick-off Chat Summary: January 5th, 2023

It’s been over 4 years since the Fields API project has been active and many things have changed for WordPress in that period.

Since then, many things were introduced into WordPress itself including things like:

  • BlockBlock Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. Editor
  • Full Site Editing has replaced the CustomizerCustomizer Tool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings. (which is now only used for classic themes)
  • New Navigation editing
  • Widgets are now legacy and have been replaced with new blocks and a new WidgetWidget A WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user. editor
  • Newer PHPPHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher compatibility (testing still in progress for PHP 8.0+) and talks of upping the minimum PHP version

All of that has led to @joedolson approaching me to determine if it’s worth bringing Fields APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. back with a new vision.

After some initial discussion, the passion reignited within me to get this going again and we ended up having our first kick-off meeting today to discuss where we’ve been, where we’re at, and where we want to go in 2023. This and future work will be organized through our SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. channel #core-fields

Read below for what we discussed and here’s a link to watch the video from our initial meeting.

Video recording

The kick-off discussion

Meeting notes

Introductions

  • @sc0ttkclark – Scott Kingsley Clark
    • Senior Software Engineer at Pagely / GoDaddy
    • Lead Developer of the Pods Framework
    • Previously Co-Lead of the Fields API project from 2013-2016 with @ericlewis and then Lead Developer from 2016-2017
  • @borkweb – Matthew Batchelder
    • Been working with WordPress since ~2004
    • Worked with The Events Calendar and now Director of Engineering at StellarWP overseeing their products and initiatives
  • @joedolson – Joe Dolson
    • Contributing to WordPress since about 2006
    • WP CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Committercommitter A developer with commit access. WordPress has five lead developers and four permanent core developers with commit access. Additionally, the project usually has a few guest or component committers - a developer receiving commit access, generally for a single release cycle (sometimes renewed) and/or for a specific component.
    • Working on the AccessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) team
    • Reached out to Scott about Fields API from the perspective of improving accessibility for the Settings page
  • @jason_the_adams – Jason Adams
    • Manager of Development at GiveWP
    • Matt and him want to get together about how to help create unified libraries for multiple projects across StellarWP and other companies
    • GiveWP has it’s own Field API that it’s been pushing forward as well
  • @peteringersoll – Peter Ingersoll
    • Worked with WP for about 10 years
    • Not a developer but a user/self-titled user advocate
    • Coming at this as a perspective as a user who is interested in how this will work

Overview of Fields API – where we started

  • Started work in November 2013 with @ericlewis as lead and @sc0ttkclark as co-lead
  • Started holding meetings back when Freenode IRCIRC Internet Relay Chat, a network where users can have conversations online. IRC channels are used widely by open source projects, and by WordPress. The primary WordPress channels are #wordpress and #wordpress-dev, on irc.freenode.net. was being used before Slack
  • Initial focus was around Post metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. fields and meta boxes in the Post Editor
  • Expanded over time to cover a generalized API to work with
    • Post meta boxes and their fields
    • Settings fields (replacing the Settings API)
    • User profile fields (edit profile, add new user)
    • Term fields (add term, edit term)
    • Comment fields (add comment on frontend, edit comment in dashboard)
    • Media fields (modal)
    • Customizer (allowing the Customizer to see Fields API configurations)
  • We built 3 different prototypes over time
  • Hundred of plugins in WP have their own Fields API and lots of devs have their own preference on code structure so there were lots of voices with different opinions for what the Fields API should look like
  • WP Core team (committers and contributors) were somewhat receptive but we couldn’t gain momentum
  • The block editor and other projects started up which reduced priority for getting Fields API into WP especially since it wasn’t just one small part of WP
  • @sc0ttkclark reached out for anyone else to take over the project as lead (while Scott supported) but couldn’t find anyone so the project became inactive

Rebooting Fields API – where we’re at

  • @joedolson approached @courane01 and @sc0ttkclark to see if we wanted to tackle Accessibility as a goal for a smaller reboot of the Fields API
  • The GitHub repository has been unarchived and is ready to start the next steps of getting things going again
  • Lots of test coverage for the API itself
  • A number of examples of how to work with the API
  • Implementations that were covered at the time (in WP 4.5)
  • Things that were in progress at the time (in WP 4.5)
  • @jason_the_adams gave a demo of the GiveWP Fields API
    • Uses a mid-level API to register the configurations
    • Implementations handle rendering those
    • The primary implementation is a Block Editor powered form editing experience
    • @borkweb and @sc0ttkclark provided positive feedback about the PHP side of things

Where we’re going

  • @sc0ttkclark What PHP version should we target?
    • PHP 5.6 is the current minimum and we’ll stick to that unless progress is made on upping the minimum WP version
    • If the minimum version is upped, we can revisit this and adjust our code to follow suit
  • @borkweb How we approach things in WP now is much different than back when the Fields API started
    • Is there merit in separation of data and output like what GiveWP is doing versus what the very coupled approach that the Fields API has right now
  • @joedolson Whether this can be potentially be used for the Block Editor may have a big impact on whether it has traction, though there are plenty places where it could be useful
  • @sc0ttkclark
    • Content areas like Posts and Terms, we’ll likely see more expansion of the Block Editor
    • There are a few places in WP that may not make sense to be in the block editor itself
      • Settings
      • User profile
      • Maybe others?
    • Those areas may eventually use ReactReact React is a JavaScript library that makes it easy to reason about, construct, and maintain stateless and stateful user interfaces. https://reactjs.org/. components to render but won’t live in the “Block Editor” that we know of today
    • We could separate the Fields API focus into specific component implementations, not unlike what we had before but with the goal being that we are registering structure – whether or not that is the same exact input used for each screen (some screens will need their own form implementations for their inputs that may not be HTMLHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. renders)
    • If we wanted to implement Fields API for the Block Editor, it could help register Components for the Inspector Panel for Blocks, which is currently an area with high copy/paste
      • Fields API could register Inspector Panel sections and components
    • PHP has grown up and it may be better to use objects than straight PHP arrays especially since that can work with IDEs and help with autocomplete for a better developer experience
    • With the Fields API, I want to make possible the idea that you can interact with the configuration of a form and add/change fields by registering new fields or adjusting their configurations
    • Knowing what the structure of a page is (outside of just basic actions that people use now to render HTML) gives devs the ability to take those configurations and consume them through WP-CLIWP-CLI WP-CLI is the Command Line Interface for WordPress, used to do administrative and development tasks in a programmatic way. The project page is http://wp-cli.org/ https://make.wordpress.org/cli/, the REST APIREST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/., and PHP for custom implementations like the WordPress iOSiOS The operating system used on iPhones and iPads. app and many other apps that need to represent the various edit screens
  • @borkweb So the Fields API project would morph into a data layer and one or more rendering implementations to consume that
  • @sc0ttkclark
    • We can focus on Settings page at first and go from there into the User profile, but leave everything else out until we gain traction and get something into Core
    • Don’t focus on legacy things like the Classic Editor or Customizer or the Widget forms
  • @joedolson Getting this built out and implemented is a challenge but I’m game
  • @sc0ttkclark We should figure out what we want to structure the Fields API off of, but use object oriented as much as possible and make the focus on better developer experience so we can help level up working with WP
    • We could look at the structure of GiveWP’s Fields API and other modern Fields APIs from other plugins/libraries
    • Avoid looking back at older/legacy plugins and libraries
    • Find a consensus on what makes sense that most people will be familiar with based on what’s popular/modern
    • The current Fields API is based on the Customizer API which has become antiquated already

Next steps

  • Meetings: Figure out the frequency of meetings and when our next meeting is
  • Viability: Get a gut-check from WP core dev team in the core meeting and through responses to this post on direction and our focus
  • Spec: Look at modern Fields APIs in modern plugins/libraries and figure out how we want that structure to look like through a new spec doc
  • Code: Start with a Settings API implementation collaborating with @joedolson and the Accessibility team to ensure that side is accessible
  • Testing: Ensure the API is well tested with unit tests
#feature-plugins, #fields-api, #options-meta, #summary

Additional register_meta() changes in 4.6

In the last 2 weeks, the direction of register_meta() has changed significantly from the original write-up. There was a meeting to discuss some of the changes and a recap of that discussion. Some other discussion after that meeting led to a much more simplified version of register_meta() that is now shipping in 4.6.

Here’s what registering metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. looked like in 4.5. This meta key has sanitization and authorization callbacks.

register_meta( 'post', 'my_meta_key', 'sanitize_my_meta_key', 'authorize_my_meta_key' );

The above code will continue to work in 4.6, though will not be considered completely registered. The callbacks will be registered, but the key will not be added to the global registry and register_meta() will return false.

Here’s what registering meta looks like in 4.6. This meta key will have sanitization and authorization callbacks, and be registered as public for the WordPress REST APIREST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/..

$args = array(
    'sanitize_callback' => 'sanitize_my_meta_key',
    'auth_callback' => 'authorize_my_meta_key',
    'type' => 'string',
    'description' => 'My registered meta key',
    'single' => true,
    'show_in_rest' => true,
);
register_meta( 'post', 'my_meta_key', $args );

The above will register the meta key properly and return true.

There will no longer be a check for unique object types and subtypes for meta keys. There is no CURIE like syntax involved. Instead, be sure to uniquely prefix meta keys so that they do not conflictconflict A conflict occurs when a patch changes code that was modified after the patch was created. These patches are considered stale, and will require a refresh of the changes before it can be applied, or the conflicts will need to be resolved. with others that may be registered with different arguments.

Additional helper functions get_registered_metadata(), get_registered_meta_keys(), unregister_meta(), and registered_meta_key_exists() have been added to make the innards of the global data more accessible.

The $wp_meta_keys variable should not be altered directly. It is possible that its structure will change in the future.

Any code currently using register_meta() and expecting pre-4.6 behavior will continue to work as is. Please report any breaks in compatibility that might be found.

For the full history, see #35658. 🙂

 

 

#4-6, #dev-notes, #options-meta

register_meta() Discussion Recap (July 14, 2016)

As announced yesterday, there was a discussion today covering the future of register_meta(), something that has been in progress for WordPress 4.6 in #35658. This is a recap. 🙂

Attendees: @helen, @ocean90, @rachelbaker, @mikeschinkel, @jsternberg, @sc0ttclark, @richardtape, @swissspidy, @joemcgill, @seancjones, @achbed, @jeremyfelt

Chat log.

Overview

In #35658, register_meta() uses object subtypes when registering metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. so that key registration can be considered unique.

In 4.6 trunktrunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision., this information is passed as part of the 3rd argument—array( 'object_subtype' => 'books' )—to register_meta() and $object_subtype = '' has been added as an extra argument to several other pieces as a way to support that.

After exploring a bit more, it’s clear that $object_subtype will continue to spread as an additional argument throughout many _meta() functions so that registered meta is handled properly.

An alternative is to use CURIEs to describe complex meta types in a single string—'comment:reaction' rather than 'comment' and 'reaction'—so that the extra argument is not needed. Instead, processing exists to turn that string into an object type and subtype.

Examples

  • post:post
  • post:books
  • term:category
  • user:user
  • comment:reaction

The main question for today’s discussion

Is CURIE like notation the right way forward for handling complex meta types?

Decisions

After a very good and thorough conversation about the above and other points, these are the decisions for moving forward with work on #35658:

  1. Meta keys will be registered using CURIE like syntax.
    • register_meta( 'post:book', 'isbn', $args );
  2. The : used in the string to register meta keys will also be used in filters.
    • sanitize_post:book_meta_isbn
  3. CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. object types will fallback to default subtypes if one is not specified.
    • post becomes post:post, comment becomes comment:comment, user becomes user:user, and term becomes term:categoryCategory The 'category' taxonomy lets you group posts / content together that share a common bond. Categories are pre-defined and broad ranging..
  4. Meta key registration for all/any subtypes of an object type will not be included in 4.6, but is likely something to add in the future.

Please check out the latest patches on #35658 and contribute code and thoughts on that ticketticket Created for both bug reports and feature development on the bug tracker. or share any questions/concerns in the discussion below.

Thanks everyone for attending today!

#4-6, #options-meta

register_meta() discussion on Thursday, July 14

Howdy!

There will be a meeting in #core at Thursday July 14, 19:00 UTC to discuss the changes in register_meta() for the 4.6 release. The dev notes have been published, but there is still work to be done to ensure things are great.

Of particular interest is a proposal to change to a CURIE like notation when working with the registration of metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress.. Instead of using two arguments (object type and subtype), there would be one argument containing both.

As an example, If a post type was registered with books as the slug and ISBN was stored as sanitized meta:

// In WordPress 4.5
register_meta( 'post', 'isbn', 'my_sanitize_callback' );

// In current trunk for 4.6
register_meta( 'post', 'isbn', array( 'object_subtype' => 'books', 'sanitize_callback' => 'my_sanitize_callback' ) );

// After proposed change
register_meta( 'post:books', 'isbn', array( 'sanitize_callback' => 'my_sanitize_callback' ) );

Please stop in #core at Thursday July 14, 19:00 UTC tomorrow if you are interested. If you can’t make it, please leave a comment on this post with your thoughts.

#4-6, #fields-api, #options-meta

Enhancing register_meta() in 4.6

Note: The direction of register_meta() has changed since this was published. Please see the most recent developer note explaining these changes.

In 4.6, register_meta() expands to support the registration of meta keys and what to expect from those keys. See #35658 for the discussion around this change.

The behavior of register_meta() is similar to register_post_type() in that the registration of this data is stored in the global scope. This makes an object’s meta data more accessible to parts of core and extending code.

Why make this change

In 4.5 and earlier, WordPress provided no method to explicitly register a meta key’s public state. Instead, register_meta() provided “protected” and “authenticated” meta. This can be used effectively for some things, particularly to determine what meta appears in the Custom Fields metabox when editing a post. It can not be used as a basis for arbitrarily showing meta keys and values to unauthenticated visitors.

What does this change involve

A global variable, $wp_meta_keys, contains all registered meta keys.

The function signature of register_meta() has changed to support 3 arguments, the last being an array. That array should contain data about the meta with these key/values:

  • sanitize_callback, a callable method to provide sanitization. This is the new version of the current 3rd parameter in register_meta().
  • auth_callback, a callable method to provide authorization. This is the new version of the current 4th parameter in register_meta().
  • object_subtype, a string containing an object subtype slug. If there is no object subtype, meta will not be registered and a WP_Error will be returned instead.
  • type, a string indicating what type of data the meta value will be. This is intentionally not restricted to a specific list of data types, however full names should be used when possible. (e.g. boolean, integer)
  • description, a string containing a basic description of the meta value.
  • single, whether code retrieving meta for this key should expect a single or multiple values when using something like get_post_meta().
  • show_in_rest, whether this should be shown as part of a post’s meta endpoint in the WordPress REST API. Note that this should be treated as experimental until the WordPress REST API provides support for meta.

The register_meta_args filter is available to add support for additional arguments. This need to explicitly whitelist further arguments is to reserve the right for core to add further arguments in the future; should you choose to use this filter, you should be prepared to follow along with further development. Your testing with trunk or betas is greatly appreciated!

By default, only WordPress core object types (post, user, term, comment) can be registered. To add support for custom object types, use the wp_object_types filter. This whitelisting is similar to the above.

Object sub types provide specific registration of meta keys to a type of data.

  • A standard WordPress post has an object type of “post” and an object subtype of “post”.
  • A custom post type registered with a slug of “my_cpt” has an object type of “post” and an object subtype of “my_cpt”.
  • A WordPress user has an object type of “user” and an object subtype of “user”.
  • A standard WordPress comment has an object type of “comment” and an object subtype of “comment”.
  • A standard WordPress category term has an object type of “term” and an object subtype of “category”.
  • A custom taxonomy registered with a slug of “my_tax” has an object type of “term” and an object subtype of “my_tax”.

Meta keys must be explicitly registered for each object type and subtype combination.

Additional helper functions get_registered_metadata(), get_registered_meta_keys(), unregister_meta(), and registered_meta_key_exists() have been added to make the innards of the global data more accessible.

The $wp_meta_keys variable should not be altered directly. It is possible that its structure will change in the future.

Any code currently using register_meta() and expecting pre-4.6 behavior will continue to work as is. Please report any breaks in compatibility that might be found.

Example

Here’s what registering meta looked like in 4.5. This meta key has sanitization and authorization callbacks.

register_meta( 'post', 'my_meta_key', 'sanitize_my_meta_key', 'authorize_my_meta_key' );

The above code will continue to work in 4.6, though will not be considered completely registered. The callbacks will be registered, but the key will not be added to the global registry. A WP_Error object will be returned with this explanation.

Here’s what registering meta looks like in 4.6. This meta key will have sanitization and authorization callbacks, and be registered as public for the WordPress REST API.

$args = array(
    'object_subtype' => 'post',
    'sanitize_callback' => 'sanitize_my_meta_key',
    'auth_callback' => 'authorize_my_meta_key',
    'type' => 'string',
    'description' => 'My registered meta key',
    'single' => true,
    'show_in_rest' => true,
);
register_meta( 'post', 'my_meta_key', $args );

If you are currently using register_meta() and would like to maintain support for older versions of WordPress, the best method will be to check for the registration of the sanitization and authorization callbacks after calling register_meta() and then registering them manually if not present. This manual registration is all that register_meta() was previously doing. Continuing from the example above:

// Pre-WordPress 4.6 compatibility
if ( ! has_filter( 'sanitize_post_meta_my_meta_key' ) ) {
    add_filter( 'sanitize_post_meta_my_meta_key', 'sanitize_my_meta_key', 10, 4 );
}

if ( ! has_filter( 'auth_post_meta_my_meta_key' ) ) {
    add_filter( 'auth_post_meta_my_meta_key', 'authorize_my_meta_key', 10, 6 );
}

What’s next

While the initial work on this is largely driven by the need to move the WordPress REST API forward, its scope is not limited to solving the problem of public access to metadata. By having information about the meta keys used in a code base, it becomes much easier for other pieces of code to make decisions about what can be done with this data.

This data can one day be useful to everything from the Customizer, the editing experience for all object types, the Fields API, and many plugins that rely on metadata. Work will continue on transforming this $wp_meta_keys object and the methods surrounding it to be flexible and explicit. As WordPress core becomes familiar with register_meta() and more confident in the approach, the set of default arguments can and likely will expand to include more data about registered meta keys as required.

Feedback

Please leave any feedback you have on this new iteration of register_meta() in the comments below. Test it out in your plugins and themes to be sure it is working in a backwards compatible way. Try out the new function signature and register meta for objects and their subtypes. This continues to be a work in progress and feedback is important.

#4-6, #dev-notes, #fields-api, #options-meta, #rest-api

A data schema for meta

register_meta() is a tiny function, which lets you register a sanitization and authorization callback for post metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress., term meta, user meta or comment meta. We’re going to expand the utility of this function to describe the data type of the field. This will be useful for the REST APIREST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/rest-api/. as well as the Fields APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways.. This discussion has started in #35658, but I’d like to share the latest thoughts for general feedback. Imagine a “movie” custom post typeCustom Post Type WordPress can hold and display many different types of content. A single item of such a content is generally called a post, although post is also a specific post type. Custom Post Types gives your site the ability to have templated posts, to simplify the concept. which has a “star-rating” post meta field, which should accept the value 1, 2, 3, 4 and 5. REST API clients like the iOSiOS The operating system used on iPhones and iPads. app would want to know this information, so they can offer appropriate UIUI User interface for their users. Ditto for the Fields API. Here are some loose thoughts on what that API might look like. Here is a post meta field for “mood” that accepts any string. The value would fit in a single row. There would only be one row per post, as it is not “repeatable.” Repeatable might be a default.
<?php 
register_meta( 'post', 'mood', array( 'schema' => array( 
		'type' => 'string',
		'repeatable' => false
	)
) );
Here is a field that consists of an array of URLs. The value would fit in a single row, perhaps in JSONJSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML. format, i.e. ['some.url/','some.other/url'], and is limited to one row per post.
<?php 
register_meta( 'post', 'related_content', array(
	'schema' => array( 
		'type' => 'array',
		'items' => array(
			'type' => 'url',
		),
		'repeatable' => false
	)
) );
Here is a field that consists of an album as it relates to an artist and includes a number of properties. The value would fit in a single row, and multiple rows can exist for a single artist.
<?php 
register_meta( 'post', 'album', array(
	'object_subtype' => 'artist',
	'schema' => array( 
		'type' => 'object',
		'properties' => array(
			'name' => array(
				'type' => 'string'
			),
			'cover' => array(
				'type' => 'wp-image'
			),
			'genre' => array(
				'type' => 'string',
				'options' => array( 'Rock', 'R&B', 'Shoegaze' ),
			),
			'release-date' => array(
				'type' => 'date'
			)
		)
		'repeatable' => true
	)
) );
What do you think?

#fields-api, #options-meta, #rest-api

Fields API — Where we’re at

Over the past few months, we’ve been working towards one of the most wide-reaching APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways.’s to be suggested for coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. inclusion, apart from the REST APIREST API The REST API is an acronym for the RESTful Application Program Interface (API) that uses HTTP requests to GET, PUT, POST and DELETE data. It is how the front end of an application (think “phone app” or “website”) can communicate with the data store (think “database” or “file system”) https://developer.wordpress.org/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 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 which include TerminologyRegistration of fields, and example code.

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, @technosailor)
    • Our internal implementation of the Edit User screen replaces core’s entirely using the Fields API.
    • Here’s a code example to add more fields (and sections and controls) to the Edit User screen
    • Backwards compatibility hooksHooks In WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same.
    • To-do: Further custom markup and/or styling to match uniform layout
  • Edit Post screen (@sc0ttkclark, @brentvr)
    • Our internal implementation 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 is working on this now)
    • To-do: Add additional output types (no metaMeta Meta is a term that refers to the inside workings of a group. For us, this is the team that works on internal WordPress sites like WordCamp Central and Make WordPress. box, etc)
    • To-do: Backwards compatibility hooks
  • Term Add / Edit (@sc0ttkclark, @technosailor)
    • Our internal implementations of the Add Term and Edit Term screen replaces core’s entirely using the Fields API
    • Backwards compatibility hooks
  • Comment Edit (@sc0ttkclark)
    • Our internal implementation 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, @technosailor)
  • WidgetWidget A WordPress Widget is a small block that performs a specific function. You can add these widgets in sidebars also known as widget-ready areas on your web page. WordPress widgets were originally created to provide a simple and easy-to-use way of giving design and structure control of the WordPress theme to the user. Forms (@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.
    • To-do: WP_Widget integration (@nicholasio is working on this now)
  • Nav Menu Items (@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.
    • To-do: More compatibility work for CSSCSS Cascading Style Sheets.
    • To-do: Look into CustomizerCustomizer Tool built into WordPress core that hooks into most modern themes. You can use it to preview and modify many of your site’s appearance settings. 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, 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 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 UXUX User experience / 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 20:00 UTC 2015 and it promises to be eventful. We plan on discussing a number of things including:

  • The Fields API specification
  • Terminology of Fields
  • Proposed by @johnbillion: “Why would I, as a developer of Meta Field PluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party X, switch to using the Fields API?”

#feature-plugins, #fields-api, #options-meta

Fields API updates from Q4 of 2015

It’s been a while since I updated everyone here about progress on the Fields APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways.. I’ve been hard at work in the code and haven’t come up for air until now, but I’m planning on more regular updates in the coming weeks 🙂

Lots of progress since our last chat summary in early October, here’s a bird’s eye view of what we’ve been up to:

Where can we use help right now?

  • Review our User Profile screen implementation, let us know if it makes sense to you as a developer. It’s the kind of code you’ll be looking at needing for any custom screens you want to implement in plugins or themes, and it’s the kind of code we’re looking at using for other WordPress screens too (Post editor screen, Term editor screen, etc..)
  • Help us create use-cases for each type of object (Custom Post Types, Custom Taxonomies, Users, Comments, Media, Widgets, Nav Menu Items, etc..) — we’re specifically looking for what custom fields you could create for these use-cases and how it could make sense in real world scenarios. You can start out with just the structure, we can help you build the code for it.
  • We’re getting ready to release this on WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ as a pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party, we could use some help to write up a good readme and ensure it directs people to the correct places for involvement

So who do you contact or where do you go to help?

Oh and did I mention that every minute you help us, you make someone really really really happy in the future? It could be your future self that gets to reap the rewards of your hard work!

#feature-plugins, #fields-api, #options-meta