Right now, our Settings API implementation in the Fields API works nicely as an integration that utilizes the Settings API itself. That means it stores settings in two places (when registered through the Fields API).
If the Settings API itself relied on communicating with the Fields API instead, that would maintain backwards compatibility at the same time as having one datastore for those configurations.
Further, any plugins and themes utilizing the Settings API would automatically be accessible through any REST API endpoints that utilize the Fields API.
[x] add_settings_section() to add section to settings-$page form, callback is the 'description'
[x] add_settings_field() to add control to section, callback is control output
[x] do_settings_sections() to get form for settings-$page and maybe_render()
[ ] do_settings_fields() is tricky because of the section maybe_render() outputs a
but this function outputs only
rows, the methods are protected which output the
rows, more work needs to be done for compatibility there
Have you considered separate database tables for fields?
I'm sure you are aware of the several options available for custom fields implementation for WordPress, each with their own ideas on how to solve the problem. The most popular, of course, being Advanced Custom Fields. ACF for example, tries to solve the problem by storing field formatting and values in the postmeta table. Although this doesn't create any problems for small websites, the problem arises when this data needs to be used to create complex solutions where several types of posts and taxonomies are related to each other.
Perhaps there is another solution which could make it easy to query the database and create complex applications, search algorithms and many other solutions which require a relational type of architecture for data?
WooCommerce, in my opinion, could also benefit from this as it grows into a more serious eCommerce solution.
Custom fields by default are stored in postmeta, this is not unique to ACF or other plugins like it.
It's out of scope of what we're doing within the Fields API itself to setup new database schemas for field storage, but I should make a very important note -- that plugins like Pods Framework which allow you to create content types that do have their own tables for their content and custom fields, can definitely make use of the Fields API in a way that won't limit it's ability to continue doing what it needs.
Full disclosure: I'm also the lead developer of the Pods Framework
Right now, our Settings API implementation in the Fields API works nicely as an integration that utilizes the Settings API itself. That means it stores settings in two places (when registered through the Fields API).
If the Settings API itself relied on communicating with the Fields API instead, that would maintain backwards compatibility at the same time as having one datastore for those configurations.
Further, any plugins and themes utilizing the Settings API would automatically be accessible through any REST API endpoints that utilize the Fields API.
settings-$pageform, callback is the 'description'settings-$pageand maybe_render()Have you considered separate database tables for fields?
I'm sure you are aware of the several options available for custom fields implementation for WordPress, each with their own ideas on how to solve the problem. The most popular, of course, being Advanced Custom Fields. ACF for example, tries to solve the problem by storing field formatting and values in the postmeta table. Although this doesn't create any problems for small websites, the problem arises when this data needs to be used to create complex solutions where several types of posts and taxonomies are related to each other.
Perhaps there is another solution which could make it easy to query the database and create complex applications, search algorithms and many other solutions which require a relational type of architecture for data?
WooCommerce, in my opinion, could also benefit from this as it grows into a more serious eCommerce solution.
Custom fields by default are stored in postmeta, this is not unique to ACF or other plugins like it.
It's out of scope of what we're doing within the Fields API itself to setup new database schemas for field storage, but I should make a very important note -- that plugins like Pods Framework which allow you to create content types that do have their own tables for their content and custom fields, can definitely make use of the Fields API in a way that won't limit it's ability to continue doing what it needs.
Full disclosure: I'm also the lead developer of the Pods Framework
I think the Settings API should be powered by the Fields API.
+1 on that it ultimately should be powered by Fields API (in addition to other things like Network Settings, etc)