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 releaseRelease A release is the distribution of the final version of an application. A software release may be either public or private and generally constitutes the initial or new generation of a new or upgraded application. A release is preceded by the distribution of alpha and then beta versions of the software.. 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 makemake A collection of P2 blogs at make.wordpress.org, which are the home to a number of contributor groups, including core development (make/core, formerly "wpdevel"), the UI working group (make/ui), translators (make/polyglots), the theme reviewers (make/themes), resources for plugin authors (make/plugins), and the accessibility working group (make/accessibility). it, please leave a comment on this post with your thoughts.

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

Enhancing register_meta() in 4.6

Note: 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 makemake A collection of P2 blogs at make.wordpress.org, which are the home to a number of contributor groups, including core development (make/core, formerly "wpdevel"), the UI working group (make/ui), translators (make/polyglots), the theme reviewers (make/themes), resources for plugin authors (make/plugins), and the accessibility working group (make/accessibility). 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.

  • ReleaseRelease A release is the distribution of the final version of an application. A software release may be either public or private and generally constitutes the initial or new generation of a new or upgraded application. A release is preceded by the distribution of alpha and then beta versions of the software. 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

A specification for the Fields API

specification defines how a part of the web platform works. For example, CSS is a spec, which browsers look to when implementing their layout engines.

A feature is drafted in spec, which serves as a prop to push forward discussion on how the feature should work. The spec author focuses on understanding and explaining the theoretical, and typically is not the implementer. An implementer might try to get a feature working, realize the spec is too vague or problematic, and give feedback to the author.

The Fields API is an opportunity for immense growth in the project. It is also a large problem space that needs a lot of discussion leading to agreement on what a coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. implementation should look like.

Let’s try writing a spec to push this effort forward. To start, I’ve talked to Scott about how the Fields API implementation works and made a spec. Comments are welcome — this is a draft and intended to spark conversation!

We’ll walk through the spec together at the next 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. meeting, Monday 20:00 UTC 2016 in Slack #core-fields.

#feature-plugins, #fields-api

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:

  • @sc0ttkclark built the User Profile implementation, replicating everything that the User Profile screen currently does but it’s through the Fields API, still some things left to do to complete it
  • @nicholas_io built the Widget form implementation, allowing for widgets to register their own fields and not have to build tedious custom form markup and saving, still some tweaks and a revision to makemake A collection of P2 blogs at make.wordpress.org, which are the home to a number of contributor groups, including core development (make/core, formerly "wpdevel"), the UI working group (make/ui), translators (make/polyglots), the theme reviewers (make/themes), resources for plugin authors (make/plugins), and the accessibility working group (make/accessibility). in the structure
  • @diddledan built the Nav Menu Item implementation, after reviewing my User Profile implementation
  • @idealien and @tomharrigan are still working on fleshing out a Post Editor implementation

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 releaseRelease A release is the distribution of the final version of an application. A software release may be either public or private and generally constitutes the initial or new generation of a new or upgraded application. A release is preceded by the distribution of alpha and then beta versions of the software. 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

Fields API chat summary – October 5th, 2015

Present: @sc0ttkclark, @nicholas_io, @tomharrigan, @ericlewis, @potatomaster

Logs: https://wordpress.slack.com/archives/core-fields/s1444021200000000

  • I just got 100 hours from 10up to work on Fields API!
  • I will be working on getting the WP 4.3 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. changes put into 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., my first pass doesn’t have unit tests passing yet
  • We’ll be fleshing out Control classes, based on Customizer control classes and expand the main control class into individual classes as opposed to a ‘switch’
  • We laid out a few implementations we’d like to get into prototyping
    • User profile fields (piggy backing existing UIUI User interface of section heading + fields) @sc0ttkclark
    • Settings API (cue the oooh’s and aaah’s sound effect) @sc0ttkclark
    • Post editor (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. boxes + fields) @tomharrigan
    • 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 @nicholas_io
    • Future: Term editor (sections + fields)
    • Future: Comment forms?
  • We want to improve the main Fields API readme to better explain the project, offer more links to information about the Customizer API since it’s what we based the Fields API on, and flesh out more examples
  • We need more examples, so any use-cases we can put together for any object type, would be handy to start putting that code together (structures, not custom implementations or overrides)

We certainly could use additional contributors involved with the project, especially as we seek to start more implementation prototypes of how things could work. Just hop into 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/. #coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.-fields or check out our Github repo. Over the next 5 weeks my involvement in the project will be greatly increased, so if you are going to get involved — now would be the right timing!

Next chat: Monday 20:00 UTC 2015 (every Monday)

#chats, #feature-plugins, #fields-api, #meeting-notes, #options-meta

Fields API: Request for review of direction

Over the past many months this year, I have been working with guidance from @helen on the new 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. with the intention of inclusion into WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.. It’s based on 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. API, so those who have experience with it will see a lot of similarities. The goal isn’t to create a duplicate API though, and in our proposal we would be implementing the Fields API within the Customizer API.

What does that bring to core as a whole? It gives core a very real and far reaching API to add fields to any type of object in a standard interface. Given the growth of the Customizer API and its inclusion of fields, @helen and I both agreed it’d be great to leverage everything it can do in our efforts here. The goal isn’t focused on the actual Customizer UIUI User interface or editing on the front-end, it’s all data-oriented.

We would create implementations behind the scenes in the various existing APIs such as the Customizer API (now) and Settings API (later) while maintaining backwards compatibility. We’re also hoping to implement the Fields API within the User profile screen. This would give core more flexibility towards revamping the User profile screen in the future, without having to tackle even more than just a UI refresh. That’s also not mentioning the fact that 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 and theme authors could leverage this API to extend WordPress with their own fields in the various areas. Future places we’d look at integrating Fields API with would be the Post editor, which I’ve pegged as our third focus, behind User profile fields and the Customizer API.

Anyways, that leads us to the point we’re at now, we have an API but we don’t have all of the built-in Field Types (control types) yet or the latest Customizer API changes from 4.3 merged upstream into the Fields API. There are unit tests that are running (and passing!) so that is going to help us on our road towards core for sure.

We need developers to give their feedback on the direction we’re heading. Here are the relevant links for those reviewing:

I’d love more feedback from anyone contributing to WordPress, or the *countless* plugin and theme developers who would use the Fields API. Please comment on this post, or if you’d like to discuss further, you can hop into our weekly meetings on Mondays (Monday 20:00 UTC 2015) in the WP 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/. #core-fields channel, or pingPing The act of sending a very small amount of data to an end point. Ping is used in computer science to illicit a response from a target server to test it’s connection. Ping is also a term used by Slack users to @ someone or send them a direct message (DM). Users might say something along the lines of “Ping me when the meeting starts.” me there anytime.

Update – 08/10/2015:

We now also have a growing list of developers who are behind this project and would implement it in their projects if it were merged into core.

#fields-api, #options-meta

Metadata API project reborn: The new Fields API project

Many of you will remember that a couple of years ago, @ericlewis and a group of us set out to start a project to makemake A collection of P2 blogs at make.wordpress.org, which are the home to a number of contributor groups, including core development (make/core, formerly "wpdevel"), the UI working group (make/ui), translators (make/polyglots), the theme reviewers (make/themes), resources for plugin authors (make/plugins), and the accessibility working group (make/accessibility). sense of all of the different APIs that arose from third party plugins and themes to build custom fieldCustom Field Custom Field, also referred to as post meta, is a feature in WordPress. It allows users to add additional information when writing a post, eg contributors’ names, auth. WordPress stores this information as metadata. Users can display this meta data by using template tags in their WordPress themes. solutions on top of WordPress. That project was nicknamed “Metamorphosis” and subsequently went by the “Metadata UIUI User interface/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.” project. As 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 authors dealing with and using custom fields and content types, we had been tackling the issues of developing for multiple object types in WordPress for years prior to getting together.

Now, @helen and I are pleased to (re)introduce to you what we’re hoping to be the fruits of all of this labor: Meet the new Fields API project.

function fields_api_example_post_field_register( $wp_fields ) {

   // 1. Define a new section (meta box) for fields to appear in
   $wp_fields->add_section( 'post_type', 'my_cpt', 'my_meta_box',
      array(
         // Visible title of section
         'title'       => __( 'My Meta Box', 'mytheme' ),

         // Determines what order this appears in
         'priority'    => 'high',

         // Determines what order this appears in
         'context'     => 'side',

         // Capability needed to tweak
         'capability'  => 'my_custom_capability'
      )
   );

   // 2. Register new fields
   $wp_fields->add_field( 'post_type', 'my_cpt', 'my_custom_field',
      array(
         // Default field/value to save
         'default'    => 'All about that post',

         // Optional. Special permissions for accessing this field.
         'capability' => 'my_custom_capability',

         // Optional. Add an associated control (otherwise it won't show up in the UI)
         'control' => array(
            // Don't set 'id' and it will automatically be generated for you as
            'id' => 'mysite_my_custom_field',

            // Admin-visible name of the control
            'label'   => __( 'My Custom Field', 'mytheme' ),

            // ID of the section this control should render in (can be one of yours, or a WordPress default section)
            'section' => 'my_meta_box',

            // Control type
            'type'    => 'text'
         )
      )
   );

}
add_action( 'fields_register', 'fields_api_example_post_field_register' );

(Please note: The code above may not be the same as the final implementation, it will especially change over the next few weeks)

First of all, we split off the UI side of the project to focus solely on the API. This way, we’re not held up by anything as we move towards implementation inside of coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.. We can tackle each UI separately and that helps us keep the project nimble and on track.

The goals of this new API proposal will be to be implemented across WordPress objects as an API to register fields and sections for. We aim to cover these objects (not necessarily in this order):

  • 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. (retrofitting it beneath the existing Customizer API)
  • User profile screen
  • Post editor
  • Settings screens (retrofitting it beneath the existing Settings API)
  • And other areas in the future (Comment editor, Networknetwork (versus site, blog) Settings screens [see #15691], Media modals, etc)

This API offers a great deal of standardization across all of WordPress and code reusability. It’s paramount for third-party developers, who will be able to utilize these structures in their own plugins and themes, build apps and give access to other developers so they can contextually see what a sitesite (versus network, blog) really contains. I see the biggest use-case being able to expose the entirety of WordPress to 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 giving apps like the WordPress iOSiOS The operating system used on iPhones and iPads. app access to 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. boxes and custom fields to display real editor screens with field inputs based on the control types natively.

Areas we need help currently:

  • Examples and use cases for Customizer, User profile screen, Post editor, and Settings screens (submit issues in GitHubGitHub GitHub is a website that offers online implementation of git repositories that can can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ with your ideas, coordinate with us to refine them if you want)
  • Unit tests for core
  • Testing Customizer implementation, you’ll find the core files to replace under the /implementations/ folder in the repo
  • Brainstorming implementation classes for other object types to implement in the UI, starting with User profile screen

If you’re interested in joining our merry crew which includes @helen and a few of us, hop into 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/. #core-fields and join our weekly meetings every Monday (Monday 20:00 UTC 2015). You can check out the Fields API and submit PRs on GitHub, or pingPing The act of sending a very small amount of data to an end point. Ping is used in computer science to illicit a response from a target server to test it’s connection. Ping is also a term used by Slack users to @ someone or send them a direct message (DM). Users might say something along the lines of “Ping me when the meeting starts.” us in #core-fields throughout the week with questions or concerns.

#customize, #fields-api, #options-meta, #team-update

WP Metadata UI / API project update and new meeting time/place

It’s been a few weeks since we’ve posted an update, @mikeschinkel has been working hard on some new commits to give us some shortcuts for option arrays and things have stabilized there finally. We’re now focused on documenting field type development so we can get some contributors in there fleshing out the remaining field types.

We are also moving our “Office Hours” time and place, to Mondays @ 1800 UTC , but instead of 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. where people can’t sync up and collaborate, we’re moving it to our public Gitter room. Some other WP projects are using it and we’ve found it incredibly helpful to keep up with GitHubGitHub GitHub is a website that offers online implementation of git repositories that can can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ activity along with chat that can happen at all times of the day and it sticks around for you to read anytime you want to.

Our Gitter chat can be found here: https://gitter.im/wordpress-metadata/metadata-ui-api

Anyone can see the chat messages, and if you want to participate it’s just a GitHub login away. They have iOSiOS The operating system used on iPhones and iPads. / Mac apps too, so that’s helpful to some people as well.

If you’re interested in contributing, or if you want to check out what we’ve got and need some insight, just pingPing The act of sending a very small amount of data to an end point. Ping is used in computer science to illicit a response from a target server to test it’s connection. Ping is also a term used by Slack users to @ someone or send them a direct message (DM). Users might say something along the lines of “Ping me when the meeting starts.” us — anytime — in Gitter 🙂

#fields-api, #options-meta