[wp-trac] [WordPress Trac] #43392: Support associative array type in register_meta()

[WordPress Trac]

#43392: Support associative array type in register_meta()
--------------------------------+------------------------------
 Reporter:  diegoliv            |       Owner:  (none)
     Type:  enhancement         |      Status:  new
 Priority:  normal              |   Milestone:  Awaiting Review
Component:  Options, Meta APIs  |     Version:  4.9.4
 Severity:  normal              |  Resolution:
 Keywords:  close               |     Focuses:  rest-api
--------------------------------+------------------------------

Comment (by mnelson4):

 First off, sorry I think I got a little side-tracked focusing solely on
 how this applies to the REST API.

 > Why would you convert one way of storing an object into a string (JSON)
 to another way of storing the same object into a string (serialization)?

 That's not a requirement, I was just suggesting continuing old patterns-
 when storing a PHP array to a meta column, we usually serialize it with
 `serialize()`, not `json_encode()`.

 > As mentioned before (and in many other places) the ideal solution would
 be to add another field to the meta table(s) where we can store the data
 format. It can be a TINYINT (0 to 255) that only takes 1 byte of space. I
 know, large sites with huge tables will still hate this, but...?

 I'm sorry I actually haven't been paying enough attention elsewhere to
 have heard that before, but I like where it's heading. Is there a separate
 ticket for that? Also, a question about it: couldn't we use the data from
 `register_meta()` to decide whether a value should be unserialized or not?
 (ie, no need for another column). If the meta's type is an `array`, we
 know it needs to be unserialized; if it's type is `int` or `string`, then
 it shouldn't need to be unserialized, and if the meta hasn't been
 registered, then I'm afraid we don't know, we'll need to
 `maybe_unserialize()`. That would be backwards compatible (assuming nobody
 expects fields registered as `string` will be unserialized). But it's also
 another incentive for developers to register their meta.

 ...But anyways, maybe that discussion should happen on another ticket
 focusing on improving how we store arrays of data in meta tables.

 This ticket, I think, is mostly about using `register_meta()` to indicate
 which fields can accept an array of data (and which fields already do).

 Is it worth me making a patch as a proof of concept and make the
 discussion more concrete?

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