Una de las novedades más interesantes para desarrolladores que trae WordPress 3.5 es que a partir de esta versión los objetos tipo “post” ya no son objetos estándares de PHP (stdClass) sino instancias de WP_Post.

Por supuesto, este cambio está asociado a algunas ventajas inmediatas, relacionadas con una mejor performance y una optimización en que estos objetos se pueden almacenar en la caché de objetos (sobre todo si estás usando una caché externa, como APC, XCache o memcached). Esto es en parte debido a la utilización de métodos mágicos, tales como __isset( $key ), y el que resulta mucho más interesante, __get( $key ), que por ejemplo, permite cargar los “ancestros” de una entrada sobre demanda (con “lazy loading”), pero además tiene la posiblidad de cargar cualquier campo personalizado con la misma técnica.

En la práctica, esto significa que la utilización de datos de postmeta es muchísimo más sencilla. Por ejemplo:

<?php

// WordPress pre-3.5
// Deseo mostrar el campo personalizado "_ubicacion"
$ubicacion = get_post_meta( $post->ID, '_ubicacion', true );
echo $ubicacion;

// WordPres 3.5+
echo $post->_ubicacion;

Es decir, puedes acceder cualquier postmeta simplemente indicando el correspondiente meta_key como propiedad del objeto $post… ¡más conveniente, imposible!

Y si como yo tienes una “sana preocupación” por la performance de esta funcionalidad, puedes estar tranquilo: desde hace varias versiones WordPress carga en caché toda la información de postmeta al acceder a cualquier campo personalizado, lo que significa que no estará realizando una consulta a la base de datos cada vez que debas acceder a una propiedad de postmeta.

El único “pero” de la implementación de la clase WP_Post es que está marcada en el core como una clase final, por lo que si deseas utilizarla en un contexto mayor, no podrás extender la clase mediante herencia (como en MiClase extends WP_Post), sino que deberás hacerlo mediante composición, un patrón de diseño que quizás es un poco menos obvio… pero eso es motivo para otro post.