[wp-trac] [WordPress Trac] #35658: Provide additional data for registered meta through register_meta()

[WordPress Trac]

#35658: Provide additional data for registered meta through register_meta()
-------------------------------------------------+-------------------------
 Reporter:  jeremyfelt                           |       Owner:  helen
     Type:  task (blessed)                       |      Status:  accepted
 Priority:  high                                 |   Milestone:  4.6
Component:  Options, Meta APIs                   |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  needs-unit-tests needs-testing has-  |     Focuses:
  patch rest-api needs-dev-note                  |
-------------------------------------------------+-------------------------

Comment (by jeremyfelt):

 Replying to [comment:90 sc0ttkclark]:
 > I've added tests for register_meta(), registered_meta_key_exists(),
 unregister_meta_key(), get_registered_meta_keys(), and
 get_registered_metadata().
 >
 > See patch here:
 https://core.trac.wordpress.org/attachment/ticket/35658/37924-tests.diff

 In [attachment:35658.29.diff], I've made several of the tests more
 explicit about what to expect from `$wp_meta_kesy` once meta has been
 registered. There is still some work to do, but each test should also back
 out any of the changes that it makes so that results don't bleed over into
 other tests.

 A couple things that bugged me:

 * `unregister_meta_key()` needs to remove the filters that
 `register_meta()` has added. Need tests for that as well.
 * We should consider removing `object_subtype` key from the meta key
 array. It doesn't really serve a purpose as its used to build the array
 containing the meta key instead.
 * We should split the `test_post_meta_caps()` test into more explicit
 methods. The current tests are failing there, possibly because of some
 bleed-over with register_meta and the auth filter.

 Replying to [comment:93 helen]:
 > To help figure out the best path, what is it that people are doing with
 non-core object types and what could go wrong if it wasn't restricted?

 I don't know if we can consider it something gone wrong, but we'll be
 opening things up to more possibilities while we're still trying to figure
 this out. That's probably not a bad thing as long as we're aware of it and
 communicate intent well. Adding a filter here may help in the meantime.

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