Opened 13 years ago
Closed 13 years ago
#18702 closed defect (bug) (duplicate)
get_post_custom and get_metadata inconsistent handling of arrays in meta values
Reported by: | anmari | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 3.2.1 |
Component: | Posts, Post Types | Keywords: | |
Focuses: | Cc: |
Description
If get_post_custom is called before a post is fully saved, then it returns serialised values for any meta value that is an array. This appears to be due to it using a cached value and wp_cache_get returning serialised values. See lines 1519 in post.php
However if the meta value is retrieved later from the database the 'maybe unserialize' functions are applied, and the meta value array is returned as expected.
See lines 289 (a fairly recent nightly build) in meta.php, function get_metadata, applies these functions after the cache get.
if ( isset($meta_cache[$meta_key]) ) {
if ( $single )
return maybe_unserialize( $meta_cache[$meta_key][0] );
else
return array_map('maybe_unserialize', $meta_cache[$meta_key]);
}
Presumably get_post_custom should be consistent with get_metadata ?
I thought I saw some discussion elsewhere about arrays as metavalues and whether wp should 'handle' them. I think there are occasionally reasons why an array may make sense, although in principle agree that values should be held simply. (This also makes plugin integration easier on the whole). I picked this problem up where WPML (multlingual plugin) is attempting to copy meta data created by my events plugin. There are already many separate event data fields. The duration is stored as an array of weeks, days, hours, minutes, seconds. THis is fairly close to the way that the ical spec RFC5545 handles duration.
If it is 'policy' that arrays should NOT be held as metavalues, then let us highlight that in the CODEX, and I'lll figure out another way to store the duration.
#19708