Meta handling in WordPress 4.1

In light of 4.1’s status as a short cycle release, I would propose a handful of changes to be made around meta to better prepare us for a future that is less dependent on /wp-admin/ and more dependant on APIs. These changes will pave the road for future enhancements to the WordPress mobile app, as well as any non-wp-admin interfaces we may encounter in the future.

What I would propose is:

1) We build wrapper functions for register_meta

Those wrappers would be:
  1. register_post_meta
  2. register_user_meta
  3. register_term_meta
These three wrapper functions would accept the following arguments:
  1. meta_key (string)
  2. meta_format (string|array)
  3. post_type/term (string|array) (where appropriate)
  4. sanitize_callback (string)
  5. auth_callback (string)

The new item here would be meta_format, which would accept a number of options out of the box:
1. short_text (text that would be collected by )
2. long_text (text that would be collected by
3. date
4. datetime
5. color
6. image (this would be a field where an image is uploaded to the media library, and its ID stored in the meta_field)
7. number (possibly could be either a string: ‘number’ or an array: array( 'type' => 'number', 'decimal' => 2 ) )
8. select (would always be an array: array( 'type' => 'select', 'values' => array( 'English', 'French', 'Spanish', ... ) ) )

Additional Meta formats could be added programmatically via a filter.

In addition, we would determine default sanitizations for data UNLESS EXPLICITLY OVERRIDDEN. So, for example, short_text could be checked against wp_kses, color would get checked to only allow 3 or 6 hex characters, select would only allow strings defined in its declaration, dates would be re-formatted into YYYY-MM-DD, etc.

2) We announce that any interactions with undefined meta will be deprecated as of WordPress 4.5

Setting a fairly distant time horizon to allow developers plenty of time to update their themes and plugins.

3) Appropriate endpoints are added to the JSON REST API

Allowing application developers to obtain a list of meta definitions for every user/post/term, so that they can easily be modified through any future interface.

What do people think? I feel strongly that WordPress is in need of more powerful meta. We have the initial groundwork laid with register_meta, but it lacks the concept of meta formats, which would propel us forward into the API age.


One thought on “Meta handling in WordPress 4.1

  1. matthewhainesyoung says:

    I’m a fan of this approach. Here’s some of my thoughts.

    A ‘meta_format’ would be very useful – both externally through the API and for the various post meta form builder tools.

    Extra arguments could potentially be passed for use by plugins. eg. enable revisions for a single meta key.

    A nicely formatted label/title and description both spring to mind as useful info

    Any attempt to get a post meta form buider into core suffers from the problem its way too big and complex. This seems a nice first step towards having some sort of implementation in core.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s