I saw that a while ago, but I never was fully clear why we need this.
- There is a full “fields” API and also metabox API in WP already
- There is no way a plugin could be using the same UI that another plugin uses (and that also does not seem to be the project’s proposal anyway)
So we will remain with lots of different ways how metaboxes and fields will be implemented, all using the native WP fields (user_, post_ and term_meta, add metabox and such)
Toolset for example adds “mataboxes” to create complex M2M relationships. There are probably one million ways how to implement this, and Core would never match a way that satisfies all the plugin/users (compare Toolset with MetaBox and then ACF to see why we can’t match all those "dream plugin implementations)
What do I miss on the project that makes this necessary in core?
Reading the project “why we need it” I do not really agree. There is no way any plugin that is even a little more advanced than basic could be profiting from a “unified” thing, because we could never guess what a plugin is actually going to add.
It could be a simple text input of a postmeta, or a complex select2 that creates custom database table entries. For all these things there are already guidelines and apis (settings, fields, user fields, term fields, post data, user data, term data, and so on)
There are over a hundred (I had to stop counting) plugins in the plugin repository that add meta boxes and fields to post types, settings, users, and even more if you include all of the themes and plugins that hook into the customizer. Many plugins build their own abstraction level for doing this, and custom field plugins are the biggest culprit of not following any standards for which to there is a significant need to unite these APIs to make them more consistent. At the same time, being able to provide a detailed structure for a site will take the capabilities of apps that extend WordPress (or interact with it) to the next level.
Each of the APIs that this aims to unite all have the same essential needs. Based on the Customizer, we can enable developers to do more because they won’t have to jump between different interfaces.
Perhaps if someone can show me an example how this would for example help ACF or Toolset or MetaBox, then yes I would be interested on this - however I do not see what we need more than we have
I see major needs in actual problems how all that data is stored and dealt with, but that is another issue (like, the mess in the User Object)