[wp-trac] [WordPress Trac] #37885: Build out register_setting like register_meta
WordPress Trac
noreply at wordpress.org
Wed Aug 31 13:03:05 UTC 2016
#37885: Build out register_setting like register_meta
------------------------------------+--------------------
Reporter: joehoyle | Owner:
Type: enhancement | Status: new
Priority: normal | Milestone: 4.7
Component: Options, Meta APIs | Version: trunk
Severity: normal | Resolution:
Keywords: has-patch dev-feedback | Focuses:
------------------------------------+--------------------
Comment (by joehoyle):
Replying to [comment:2 danielbachhuber]:
> Should we introduce the concept of a `site` object, such that settings
are simply attributes on a site?
I don't think this is the right place to do that - however this is only a
still a single object type, `register_meta` takes `object_type` because
it's used for posts, comments, users etc - we don't have that concept with
settings.
> I wonder if options aren't just meta for a site, and why we don't use
register_meta() here all the way and maybe just add register_setting()
just wraps register_meta() and provides a quick way to register settings?
I may have oversimplified with "settings is just meta", because it's _not_
in WordPress land - the Meta API is a totally different implementation to
Options - conceptually they are the same, in practice with the WP codebase
being what it is, they are different so I don't think it makes sense to
actually use `register_meta`, I just think there's a lot of overlap so we
can look to `register_meta` for pointers here.
Replying to [comment:3 sc0ttkclark]:
> Where register_meta() is going, where things like the Fields API is
going, should all be to enable a solid API that all of WP can benefit
from. I'd really like to see us make use of that foundation to improve
things like Settings for the better, versus create new functions with
their own logic and globally stored configurations.
I'm not sure if this is against this patch or not - the only new function
here is `get_registered_settings` which is a helper for the global var.
All this patch aims to do is add an `args` option to the function
signature so it _can_ be used more extensively down the road. Also,
virtually all configuration in WordPress is stored globally!
There's a lot to be done on solving the Meta / Settings APIs, how the
Fields API fits into that, and how we can have a solid foundation for the
Fields API to leverage - this is one small step towards that I think :)
--
Ticket URL: <https://core.trac.wordpress.org/ticket/37885#comment:7>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list