[wp-hackers] Escaping post meta values

[Dan Phiffer]

Thanks Otto, I appreciate your thoughtful responses here. This stuff is tricky, and I understand that WordPress doesn't attempt to cover each and every possible edge case.

I hadn't considered passing in non-string values directly, but that seems like an elegant solution on the face of it. But I'm running into a new problem that when I pass objects straight into update_post_meta() it seems that whenever the data structure includes Emoji characters it results in a postmeta string that comes out empty from get_post_meta(). Is there a known workaround for this?

I've found another solution -- go back to JSON, but double-up on my escaping. It seems to be working for me so far.
Like this: http://wordpress.stackexchange.com/a/60441

Thanks again,
Dan


On May 22, 2013, at 1:51 PM, Otto <otto at ottodestruct.com> wrote:

> On Wed, May 22, 2013 at 12:06 PM, Justas Butkus <jbutkus at time.ly> wrote:
>> How do you feel about performance issue of this question?
>> I am not questioning the fundamental feature of WordPress (namely -
>> backwards compatibility), just asking, whereas this could be considered,
>> when talking about such functions?
> 
> 
> To tackle the performance question, you have to examine the more
> common behavior being used.
> 
> For the basic case, I'm storing information gained from some simple
> process in the PHP. My data is generated or gathered from the user
> input, and is plain text say. In that case, the storage of the meta is
> simple, and has no issues.
> 
> For a more complex case, I'm storing information gained from some
> complex PHP process. Say, an array, or an object. In this case, the
> data is serialized on saving to the DB, and unserialized when
> retrieving it. Again, no issues.
> 
> The only question of performance comes from when the data is gathered
> from an external source. To pick an example, let's say I get data from
> the Flickr API.
> 
> The data comes back from Flickr in a JSON format. Now, what am I doing
> with that data? This is the key question that makes the answer
> possible. There's two possibilities for usage of this Flickr JSON
> structure:
> 
> 1) I'm decoding it and using pieces of it to display something in the post.
> 2) I'm passing some or all of the data on to a Javascript process, or
> making it otherwise available via an external API call.
> 
> For the first case, then I can either json_decode it when I receive
> the data from Flickr, or every time I display the data in some manner.
> Obviously, decoding takes time and though that time is small, it makes
> more sense to decode it one time, get the data I actually need, and
> save that in the meta storage. Saving the whole blob means I'm a)
> saving data I may not use and b) having to decode it every time I need
> it. Performance is better if I convert to PHP variables first and
> discard the unnecessary pieces.
> 
> For the second case, then it would indeed make more sense to store the
> raw data, if all that raw data is needed by the resulting final
> process using it. API calls often tend to return more than we actually
> need though, so in terms of space savings in the DB, it makes more
> sense to decode the data and pare it down to what I need to use, then
> pass that and only that data along later. We still have to json_encode
> the data later, but it's probably substantially less data. This
> tradeoff is difficult to measure in the general sense, and you'd need
> to profile your exact case to know the faster approach.
> 
> Realistically, the first case is probably more common. The reason to
> get data from an external service is to use that data, generally
> speaking. It's rare that you pass that data on to some third system.
> And even if you are passing it to a browser via JS, it's better to
> pass small amounts of data instead of relaying large API responses.
> 
> Storing whole API responses from external calls, unaltered, rarely
> makes sense from a performance viewpoint. Sometimes, yes. But not
> often. Better to decode the moment you receive the data, then
> manipulate it there, then store just the pieces you need. Smaller.
> Faster.
> 
> -Otto
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers