So this is a post that I have been meaning to write for a long time. I think that the fields API and how core handles meta is without doubt the most important problem that is facing the WordPress project. But looking the work done to date on the fields api, it can get a little confusing, the project has changed owners and scope a number of times. In this post, I hope to clear up a little of the history and explain my ideas for the fields API going forward.
So what is the fields api anyway and not having it is such a problem?
The fields API is a bit of a different name for what it really is. It is in short, a library to build custom meta boxes and UI to interact with meta data. The first reference to field api goes all the way back to 2011, in ticket 18179 – WP_Meta_Box. Basically the original idea what to make the need for plugins like advanced custom fields, fields manager and CMB 2 mute by making it easy for developers to register meta boxes and UI for post meta data in core. This would make the job of plugin / theme developers much easier, as it would make adding new fields the post screen extremely easy and would mean that testing on WordPress core updates, much simpler. Plugin / theme developers have long wanted this, as building out custom meta, is a key part of the developing anything custom for WordPress. I believe it true to say, that it is the first thing that most WordPress developers do when building a project, is to set up either ACF or CMB 2. This setup is normally a manual process, as currently there is no way to require interdependencies with plugins (if this plugin /theme is installed, then install this library / plugin). This gives developers two choices. Either hard code the meta boxes / fields that you want and build out their own libraries or bundle a meta box library in with their plugin. Either solution is not great. First, building your own meta boxes, takes time and testing. It means that whenever WordPress core updates itself, that plugins require retesting. Option 2, means having a whole library in the plugin, that adds overhead. If any other plugin is including the same library, it may mean that having both plugins activate at once will break your site.
So having the a fields api in core seems to make sense, from both a user and developer level. It makes developers lives easier and makes WordPress a more usable piece of software for users. But the fields api should not just be limited to post meta, users, terms and comments all to have meta in core. Also multisite too, will have some meta tables, with some work that I am currently working on, by adding site (blog) and network ( site ) meta. So my previous blog post on the subject on site (bl0g) meta and check on the tickets for site and network meta. It is possible to make the fields api the interface for all meta data in core. However, I have also seen people discussing the idea of using the fields api, as a general api for drawing UI for any data stored in the database. That would mean it could also be used in on the core objects like Posts, Users and Options. Where on the face of it, this may seem like a good idea, I am a strongly against this. For me, this muddies the water of the fields api and makes the scope of the project limitless. It makes the project a silver bullet for the project and nearly impossible to ship. The fields api project has been going since 2013 and has had a number different versions and teams working on it. For some reason, this project hasn’t taken hold or got the support it should have. What is worse, is with Matt’s three focuses of customiser, editor and API that this and many other projects are being sidelined.
An API driven future
The REST api was merged in WordPress 4.7 and is started to be used widely by the WordPress community, even by the new editor Gutenberg. It is fair to say with the raise of frameworks like Vue and react, that the world is going towards a more javascript central front end. Matt himself said, “learn javascript deeply” in his state of the Word. For the core data types like Posts, this is fine, as these endpoints are already in core. However, you may we shocked to find that there is little support for meta data in the core API. This means react based Calypso can only handle editing core data types and limited meta keys. It means that if you have a plugin / theme registers a meta boxes, this simply doesn’t appear in the Calyso interface. This is of course a horrible user interface, as settings once important part of workflows on desktop (wp admin interface), just disappear in Calyso or on the iOS or Andriod apps.
The reason for limited meta support in the core endpoints is explained in Ryan Mccue’s post The (Complex) State of Meta in the WordPress REST API. In short, meta data isn’t added core endpoints for two reasons.
- Protected data
Core developers have no idea of knowing what data is private / sensitive and should not be displayed publicly.
- Serialised data
WordPress can store serialised objects in meta data and these can be a security problem. There is no way of knowing data type
There is much more to Ryan’s post, do check it out. But it comes down to one problem, meta is not registered anywhere, so there is no way to know, if it should be in the api or not, it’s data type, what are valid values and permissions to read / edit / delete are not defined.
A new hope
In WordPress 4.6 Jeremy Felt made some changes to a little known function called register meta. These changes were designed to allow developers to register some details about the meta data. It allows for some important information to be registered, such as.
- Authorization callback
Adds a permissions call to each meta key. Allow for secure meta data
- Sanitize callback
Allows for meta data to formatted on save, meaning data meta can be trusted to be the correct format / data type.
- Type
Does type hinting, so gives core an idea of what data type of data stored.
- show_in_rest
Allows developers to flag weather or not this meta data in the api at all.
As you might understand, this is a big step forward for meta data. For the first time, meta data is much more control on it’s processing, handling and saving.
This register meta function, is basically the fields api. It would require little work to core, we could add some new params to this function to define the kind of input that is displayed to user (select, textarea, date, text etc), a save callback, location of input and default value(s). Once these params are in, this could be returned API. Once in the API, these fields could be read by something like Calypso and metabox / meta data could automatically register this interface. This would make plugins automatically supported by javascript interfaces. It would just require the javascript interface to implement the fields.
It also makes improvement to multisite a lot easier. Multisite has been missing a settings api for a long time. As under the hood, network settings are just (site) meta data, the fields api could replace the need for a network settings api.
This doesn’t even mean that plugins like ACF would die as a plugin. I would still have a place, support fields that core didn’t like repeaters and google maps. But under the hood ACF could be converted to use the fields api, converting many sites already using this plugin, a more structured data set in the database.
Conclusion
With the fields api in core, we can work on having the user experience an enjoyable and consistent user interface across all platforms. With form fields being generated from one place, we can make the process of translation and accessibility much easier, making aWordPress and much more user friendly piece of software. It would allow those using the WordPress via apps or third party connected software, have a much consent experience and hopefully mean less breakable in the future.
But this gets down to the core issue, I have with the WordPress project. The user comes first. All the work that is currently being done on core, is about making end user experience better. I understand this desire, but it forgets one simple thing, that developers are users too. That a part like having a fields api, is a problem for both developers and users, and WordPress would be better if we solved this problem ahead of other things. The fields api, makes things cleaner, faster and more reliable for custom development. It means that developers, can save time and add value to the projects they are working on in other ways.
Thanks
I would like to thank some people for their tireless work to date.
Thanks go out to Jeremy Felt, Ryan McCue and Eric Andrew Lewis
