ClassicPress PetitionsClassicPress Petitions
This is a read-only archive. Post or comment on the live version of this page on our forums.

Finish the Custom Fields API

October 3, 2018 · 04:26 · James Nylen
Description

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

https://github.com/sc0ttkclark/wordpress-fields-api

In particular, see: https://github.com/sc0ttkclark/wordpress-fields-api#why-a-fields-api

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.

Voters
+60 more
Tags
Difficulty: Hard
Request: Add feature
Discussion
Pieter Bos

Excellent idea!

Anonymous

It has always been my opinion that WordPress should have been going in the direction of focusing on lean and API development. I believe that something with, fast approaching, 60,000 plugins should be more a well coded, lean foundation for enhancements not piling on more unnecessary core functionality that some 'developer' sect decides everyone should have.

I hope that CL will take to heart the power of API rather than adding things many people really don't need or want.

Custom Fields API is something that should be well developed.

Thoriq Firdaus

Excellent! I really wish this could be finished and merged.

Rui Guerreiro

This should be a must have for V2

David Shanske

The Fields API would be a boost for anyone wanting to build complex data structures into WordPress without having to custom code all interfaces

Daniele Scasciafratte

It is not an easy task but will be amazing an API for that, I am for integrate it but to extend it not only for printing the field like WooCommerce do with their APIs but like how CMB2 works.
https://github.com/CMB2/CMB2
An array with the settings of every field with callbacks and hooks that automatically save them and standardize the environment completelly.
Or like the Customizer works too, you have various sections with ids and fields that automatically do that.

Mike Schinkel

I was involved in the original custom fields process and Scott and I were excited about our direction, then Helen unilaterally decided it should be dumbed down and Scott, not wanting to be in conflict went along with that approach.

So, I would love to pick this effort back up again...

Glenn Dixon

Just one quick read and it occurred to me how much this feature would have made Gutenberg much easier. As it is, from what I read it appears that people are using ACF to make Gutenberg developing easier. I'm sure ACF would have opposed baking custom fields into WP, as it would have killed their business. But WP could have simply bought them. Lots of crazy choices there. But yes - I'm all for adding this to ClassicPress - seems like a no-brainer.

rkoller

Finishing the Fields API is an excellent suggestion but may i recommend to extend the endeavor and incorporate an updated database schema in the scope of the FIelds API? Not to rely onto the post_meta table where the data is stored in a longtext column encoded as text. But instead to create bespoke tables in the right data format for each field type or field. Jeff Eaton summed up the problems with the current storage system well in here https://responsivewebdesign.com/toast/backend/ .

Greg Schoppe

@rkoller the issues described in the toast article are based in "relationships". We have another proposal running to add relationships as a separate object type in ClassicPress (https://petitions.classicpress.net/posts/103/add-an-object-relationship-table). If that is completed, I believe the remaining issues could be solved by implementing a dedicated search table, for better search/filter queries. That way we could preserve existing functionality of the meta tables and retain back compatibility for all the existing plugins.

James Nylen

The meta tables are sort of a nightmare, but trying to maintain a correct table structure as various fields and plugins are registered and unregistered doesn't sound like too much fun either.

I think a custom fields API could use the meta tables by default, but allowing a plugin to use a custom storage mechanism should also be possible. In this case, the plugin would be responsible for creating and destroying its own database table, as they are today.

Note also there is already https://codex.wordpress.org/Function_Reference/get_post_custom and friends, which is just a very thin wrapper around post meta.

Viktor Szépe

I think this (and the "Drupal Views" feature) would make ClassicPress a CMS.

James Auble

What about pairing up with CMB2? It's been one of my favorites for how developer friendly and extensible it is.