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 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 and
register_meta() will return
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(
'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
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 conflict with others that may be registered with different arguments.
Additional helper functions
registered_meta_key_exists() have been added to make the innards of the global data more accessible.
$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. 🙂