[wp-trac] [WordPress Trac] #37885: Build out register_setting like register_meta

WordPress Trac noreply at wordpress.org
Wed Aug 31 17:19:38 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:8 sc0ttkclark]:
 > There's much more in common between Settings and Meta than different.
 Both use key/value storage, with support for serialization.

 Ok, so I think this is where we are disagreeing (which I think is a good
 thing we've maybe nailed that down!). The reason I don't see the
 implementations being similar enough to literally share the code: options
 have: all-options, autoloading options, don't have object ids and don't
 follow the same schema as the other meta tables.

 That's why I think wrapping `register_meta` is a mistake to appease the
 "don't write a single line of code twice" idea. `register_meta` is still a
 very simple function, I think what we'll gain by trying to fit both the
 options and object-meta implementations into the same function we'll lose
 with a leaky abstraction and multiple exceptions for options handling.
 `get_registered_meta` will now also return registered settings, I don't
 know any developer that would _expect_ that based off the naming.

 To me, it makes no difference, and is no worse if we have:

 {{{#!php
 global $wp_registered_settings = array();
 global $wp_registered_meta = array( 'post' => arrray() );
 }}}

 or

 {{{#!php
 global $wp_registered_meta = array( 'settings => array(), 'post' =>
 array() );
 }}}

 Global state is not a great thing, however one global variable with x and
 y, or two global variables is arbitrary, afterall it's just an array in
 `$GLOBALS` :D

--
Ticket URL: <https://core.trac.wordpress.org/ticket/37885#comment:9>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform


More information about the wp-trac mailing list