[wp-testers] Post Meta (Custom Fields) bugfix and optimization

[Mark Jaquith]

Howdy, testers.

I just put in two changes into trunk that affect post meta.  The  
first is a bug fix for AJAX adding of Custom Fields (aka. post meta).

The bug was triggered by adding a custom field value that looked like  
serialized data, e.g. a:10000:{}

That text has to be re-serialized as a string (which looks something  
like this:     s:10:"a:10000:{}";) in the database, but the bug there  
is that the value of the custom field would show the serialized  
string, instead of your original input.  It was in the database  
correctly, but the AJAX code wasn't properly unserializing the string  
for proper display.   So that bug should be fixed.

Tests needed:  Make sure that all values put into the Custom Field  
"value" box appear exactly as they were entered after you add them.   
This should be the same whether you're using the Javascript method  
(no page refresh) or the non-Javascript method (post saves and  
refreshes).

The other change was an optimization one.  Basically, the post meta  
caching wasn't working as it should, and that meant a lot of extra  
queries.  Specifically, calling <?php echo get_post_meta($post->ID,  
'test', true); ?> on one of the posts in the loop would cause an  
extra query, if the "test" Custom Field didn't exist for that post.   
WordPress is supposed to grab all custom fields for all posts in the  
loop... and it was doing that, but it was caching what they DIDN'T  
have.  So because "test" isn't in the cache, a fresh copy is  
requested.  That should be fixed now, as well.  There were other  
problems too, such as second loops erasing the first loop's cached  
post meta.

Tests needed:
- calling get_post_meta() for a post in the loop should never  
generate a MySQL query.  Please verify.
- for views with two loops (whether using $wp_query or instantiating  
a new WP_Query object), calling get_post_meta() for posts that are in  
the original loop (but not in the new loop) should not generate a new  
query.  They should stay in the cache from the first loop.
- calling get_post_meta() for a post that is not in any of the loops  
should cause one MySQL query, but subsequent get_post_meta() calls  
for that post should not generate new calls, even if they are for a  
different key.

For "extra query" testing, you need to put this in wp-config.php:

define('SAVEQUERIES', true);

and put this in your theme's footer.php (after </html> is fine):

<?php if ( current_user_can('manage_options') ) {
echo "<!--\n";
var_dump($wpdb->queries);
echo "\n-->";
} ?>

Then you can just view the HTML source (as a logged in  
"Administrator" level user).

People getting nightly builds might have to wait 24 hours to begin  
testing, but people checking out trunk directly from SVN can start  
testing as soon as they svn up.

You can report back on this list, or reply on this Trac ticket:
http://trac.wordpress.org/ticket/3273

Thanks!

--
Mark Jaquith
http://markjaquith.com/