[wp-trac] [WordPress Trac] #34405: Retrieval of meta value that is an array.

[WordPress Trac]

#34405: Retrieval of meta value that is an array.
----------------------------------------+------------------------------
 Reporter:  alexwbaumann                |       Owner:
     Type:  defect (bug)                |      Status:  new
 Priority:  normal                      |   Milestone:  Awaiting Review
Component:  Options, Meta APIs          |     Version:  4.3.1
 Severity:  normal                      |  Resolution:
 Keywords:  has-patch needs-unit-tests  |     Focuses:
----------------------------------------+------------------------------

Comment (by boonebgorges):

 Thanks for the detailed ticket, alexwbaumann, and welcome to Trac.

 I've always thought that `$post->foo` to get arbitrary 'foo' metadata from
 the database is a pretty weird syntax, but that's the way it works, so oh
 well :)

 Sanitizing a non-scalar value for the 'edit' context feels odd to me. WP
 uses the 'edit' context when pulling up a post to display on `wp-
 admin/post.php`, in which case the values are being sanitized for entry
 into textareas and input fields. But this is clearly not the case for
 objects and arrays, so `esc_attr()` doesn't seem like the right kind of
 sanitization. In the case of 'edit', it's not clear to me that we should
 be doing any sanitization at all - who knows how this data is intended to
 be used?

 That said, I don't think `esc_attr()` will be harmful here - anyone using
 post data in this way ought to know what they're doing. Since postmeta can
 be in any non-scalar format, including objects and multi-dimensional
 arrays, I recommend a more general solution:

 {{{
 if ( is_scalar( $value ) ) {
     $value = esc_attr( $value );
 } else {
     $value = map_deep( $value, 'esc_attr' );
 }
 }}}

 As SergeyBiryukov notes, this needs unit tests.

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