[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