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

WordPress Trac noreply at wordpress.org
Wed May 4 07:26:35 UTC 2016


#35658: Provide additional data for registered meta through register_meta()
-------------------------------------------------+-------------------------
 Reporter:  jeremyfelt                           |       Owner:
     Type:  enhancement                          |      Status:  new
 Priority:  normal                               |   Milestone:  Awaiting
Component:  Options, Meta APIs                   |  Review
 Severity:  normal                               |     Version:
 Keywords:  needs-unit-tests needs-testing has-  |  Resolution:
  patch rest-api                                 |     Focuses:
-------------------------------------------------+-------------------------

Comment (by MikeSchinkel):

 I came here before of @ericlewis' post on Meta.
 [https://make.wordpress.org/core/2016/05/03/a-data-schema-for-
 meta/#comment-30153 Here is my comment] from over there.

 But as it seems this is the place for discussion, are we seriously
 considering storing complex data in a single meta field as not just an
 edge case where you are storing a JOSN blog for convenience?

 IMO this is a really bad idea because it means you cannot use SQL to query
 the data.  Let me beg the team to consider storing complex data like this.
 It is a format that really stood the test of time and many different
 websites, and it can handle any level of complexity. It can also support a
 generic mention of converting too and from a JSON blob:

 https://bitbucket.org/newclarity/sunrise-1#markdown-header-post-meta-
 storage-format

 ALSO, I would strongly urge against using nested arrays.  It make for
 brittle code that can easily be mistyped and it makes it impossible to do
 a generic wp_parse_args() in order to merge in default attributes.  If you
 MUST use nested attributes please consider using nested keys instead with
 colons to separate, like so; it is easily to extract the subarrays from
 these nested keys when you need it but this supports wp_parse_args() much
 better, and in my experience you really need that.

 Here is Eric's example from the Make post reworked using nested keys:

 {{{
 register_post_meta(  'album', array(
         'object_subtype' => 'artist',
         'schema:type' => 'object',
         'schema:properties:name:type' => 'string',
         'schema:properties:genre:type' => 'string',
         'schema:properties:genre:options' => array( 'Rock', 'R&B',
 'Shoegaze' ),
         'schema:properties:release-date:type' => 'date',
         'schema:repeatable' => true
 ) );
 }}}

 But even that seems over-architected but I am really struggling to
 understand the example -- the semantics of the example are not clear to me
 -- so I can't give a simplified example.

 But I do feel this area is critical to get right because getting it wrong
 dooms many people to writing too-complex and rather error prone code.

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


More information about the wp-trac mailing list