Finish the Custom Fields API

This is a petition to finish the Fields API and integrate it into ClassicPress core.

In particular, see: GitHub - sc0ttkclark/wordpress-fields-api: Fields API proposal for WordPress Core (2015-2017), starting up again in 2022/2023

This was a feature plugin that never made it into WordPress core. It would have been a great foundation to further build out CMS capabilities and probably many other things that we haven’t even imagined yet.

But, the core developers don’t need to imagine everything that people will do with our CMS, we just need to provide a solid base for people to build on.

I see this API as mainly an un-opinionated way for plugins like ACF, Toolset, etc to do their job, but much more easily, without having to re-invent almost every piece of the functionality they provide.

For developers, this would also allow us to easily register all custom post types, fields, etc in the theme or plugin code for a site. We would change the field definitions in our dev environment, test and deploy, and everything in production is already updated. We could build a simple UI to manage only the settings that really need to be changed, but this UI wouldn’t let users break the custom content types like what happens on sites today.

For users, it’s hard to tell how this would look. I think this would mostly be a back-end improvement, perhaps with some light UI controls, but most user-facing implementation would be up to plugins until clean standards emerge.


Read-only archive: Issues · ClassicPress/ClassicPress · GitHub

Author: James Nylen

Vote count: 66

Status: open

Tags:

  • cp-research-plugin
  • difficulty-hard
  • request-add-feature

Comments

3 Likes

:+1: I totally support this. The work was mostly compatible at the time of WP 4.9 and would be a pretty cool reason to use ClassicPress for certain people.

If you need any help here, I’m sure I’d be able to help make this happen using what it ended up as.

7 Likes

I think everyone at ClassicPress would love to see this happen. @james is the person who can best explain the CP core workflow.

4 Likes

This is still one of the things I would most like to see in ClassicPress.

Since the original repository for the WP plugin was archived, I’ve forked it to GitHub - ClassicPress-research/custom-fields-api: Fields API proposal for WordPress Core (2015-2017).

1 Like

I remember @anon66243189 mentioned he used Toolset and needed something similar since they dropped support for 4.9. Maybe this will interest him.

1 Like

I saw that a while ago, but I never was fully clear why we need this.

  1. There is a full “fields” API and also metabox API in WP already
  2. 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)

1 Like

Check out post @sc0ttkclark wrote for WordPress when he was working on this project. That’s pretty detailed. And also check out comments on that post. He answered a lot of them.

1 Like

Thanks for that, also found the spec in it’s links

Now more than before I’m sure we don’t Need This

There’s no way we can create an api (with or without ui ) that’ll let advanced things be registered/done

The statements on which the idea seems to be justified (that there’s no way for developers to display an UI to add or edit secondary data (fields) and that WP core doesn’t provide said UI) is simply not true

Core should not provide said UI because there’s an infinite number of possible implementations of any setting or field or data.
If we unified that we can as well implement React which uses “native” controls

And we have plenty of possibilities to add secondary data edit UI in posts, users and terms.
That’s what metaboxes and other hook and actions are there for

So… no I don’t think I could profit from that.
It’d make it a huge work to model the data exactly as core expects it to be, restricting me as a developer to make only things that core thinks are ok.
I wouldn’t save time unless I don’t need any “special” data handling in which case I can also just go with wp current UI for secondary meta data (post fields have that at least, it’s true The user and terms do not have it…)

But I don’t see the huge win in this enormous work trying to match all possible things a plugin might be doing with meta data.

Just as An example, how will core handle a multi dimensional array stored in a meta field?
It can’t, because it can’t know it’s structure and intentions
Only the developer knows what it represents and how it should populate an eventual UI.

Restricting that so that it matches an api just means taking away power from current possible things.

Perhaps I still misunderstand but from what I gather in said post and specs this is exactly the idea behind it, and I don’t like it :stuck_out_tongue_closed_eyes:

Speaking of relationships.

1 Like

Current thoughts on this?

I think that more than an API, having an Admin Area solution like ACF or CMB2 is more useful at the moment. WordPress doesn’t have a real API but it has all the necessary functions and once you get how they work… it’s all cool. An API will be nothing else but a wrapper for that.

Instead, having a good plugin like ACF or CMB2 is going to provide much more value. The problem is that those plugins are now adapting to the blocks world… and we want a non-blocks world plugin.

Which of those do you consider more complete and useful? Which of them should become “The fields plugin” for CP?

Or, finish the API as a wrapper and create a UI on top of that…

A CMS just needs this. Nothing is a real CMS until this exists.

1 Like

I’ve used ACF, so that’s what I know and like. There’s also Pods Framework, whose lead developer Scott Clark, is the developer behind fields API. Worth a look.

1 Like

Choosing either one as the “official” one would be a mistake. There will always be those who prefer an alternative. Leave them as plugins and allow devs to choose.

The fields API should be more than a thin wrapper around either and would need its own database table.

A current project of mine might benefit from something like this. I wanted to make one custom taxonomy’s terms the potential parent of another taxonomy’s terms. The code seems to work fine, but the list of child terms completely disappears from the admin UI, making it unusable. But maybe if there were a way to overwrite the admin page, that would actually be better.

1 Like

I think we are getting closer to one of the reasons why the WordPress community has always been an elite community and it would be nice if this does not happen here and that we can find a way to welcome everyone. What I am referring to is the division between dev and user. Devs don’t need interfaces, (command line is enough), users need interfaces to be able to do some things that a command line dev would do. I believe WordPress has almost everything, just to grab and create user interfaces. Returning to the subject of the post, I believe that the bees for devs are already there, but the user interface is not. Last note, creating an interface like toolset or even acf seems foolish to me, metabox.io much easier and more extensible. Another final note, which wp does not even have, is the support of calculation fields, with conditions and relations, (such a thing would give ClassicPress the possibility to do it without writing a single line of code, an erp, etc … ). Last Thing, currently classic press and lacking a good form plugin, merging custom fields with computation, relatables and conditions, custom taxonomies, custom posts, submissions and frontend editing, could make ClassicPress almost anything, from directories to ads. , etc … even ecommerce could be based on this, with a few simple functions well laid out in the interface. The database talk and the casino user and dev stuff. One user!

2 Likes

It really isn’t about devs vs users. There are some fundamental things lacking, even for devs. Sure, a dev can write code to get around certain problems (as I’m currently doing) but that doesn’t mean there isn’t a deficiency that ideally should not exist.

You’ve come up with another alternative plugin. But that suffers from the same problem as the others. All these plugins are just ways of getting round the deficiencies I’ve mentioned. If that’s all we need, then there’s no reason to add anything new to core here; just use your plugin of choice. What’s being proposed here is something more fundamental.

1 Like

I strongly believe in trying to involve him in this Community

1 Like

I contacted him a month ago, he was not interested about this. Maybe you can try again, it could make him think twice, maybe wake up a flame. I just sent you his e-mail via a private message.

I re-read everything in this topic and actually what Beda says is probably the most reasonable thing.

The API is already there, there isn’t anything that has to be “finished”.

In any case, “improved”.

But when I look into the current state of the API I don’t see what I would actually improve without forcing decisions.

The current setup is so simplistic that it allows doing almost anything.

What would you consider an “improvement” to the current API that is useful for developers, provides value, and does not force decisions?

And I’m saying developers here, not users, because we are talking about the API (which is a developer oriented thing). The frontend as others stated has so many possible options that it should stay plugin territory.

In case there aren’t relevant things to do here, I would vote to close this petition.

(Don’t know if it is a priority to close decisions or how this is supposed to work. But, I think the more decisions get closed, the better, instead of hanging around, open forever).

3 Likes

Having now built an Object Relationships database table (and related metadata table), I have now come around to Beda’s point of view on the Fields API idea. Core already has the fields (and they can be enhanced by the plugins mentioned if desired) and there’s really nothing to be gained except confusion by attempting to add this to core.

What’s actually needed is the object relationships stuff. I’ll be submitting a plugin to the directory fairly shortly, and I hope it can be used as a model for core implementation.

But this petition should probably be closed. Even if I’m wrong, and it could be worthwhile, no-one has any interest in writing the code.

2 Likes

The petition can always be reopened in the future if there is a need and will to do it. For now, we’ll close it.

1 Like