get_queried_object en WooCommerce 11: qué cambió

En pocas palabras: Desde WooCommerce 11.0, publicada el 13 de julio de 2026, get_queried_object() devuelve un objeto WP_Post en la página de tienda, igual que en el resto de WordPress. Antes retornaba WP_Post_Type: la shop era la única excepción del sistema.

WooCommerce cambió cómo se comporta get_queried_object WooCommerce 11 en la página de tienda. Desde la versión 11.0, publicada el 13 de julio de 2026, esa función devuelve un objeto WP_Post en la shop, igual que en el resto de las páginas. Antes devolvía WP_Post_Type. Era la única excepción del sistema.

get_queried_object() es una función nativa de WordPress que devuelve el objeto de la consulta principal en curso: un post, un término de taxonomía o un tipo de contenido, según la página. En la tienda de WooCommerce, hasta la versión 10.x, retornaba un WP_Post_Type. Desde WooCommerce 11.0 retorna un WP_Post, alineándose con el estándar de WordPress.

WooCommerce es un plugin de comercio electrónico de código abierto para WordPress, desarrollado por Automattic, que permite crear y gestionar tiendas en línea. Proporciona funcionalidades para la venta de productos, gestión de inventario, procesamiento de pagos y cumplimiento de pedidos.

¿Por qué WooCommerce cambió el comportamiento de get_queried_object()?

Porque la página de tienda era la única excepción rara del sistema. Según el anuncio oficial de WooCommerce, en todas las demás páginas get_queried_object() devolvía un WP_Post, pero en la shop devolvía un WP_Post_Type. Esa desalineación con WordPress venía generando confusión hace años.

Pensalo así. En WordPress, cuando configurás una página estática como «Página de entradas» en Ajustes de Lectura, esa página tiene detrás un WP_Post real. La shop de WooCommerce funciona parecido: es una página que vos elegís y que lista productos. Sin embargo, hasta la 10.x, cuando preguntabas por su objeto, te devolvía el tipo de contenido «product» en vez de la página en sí. Medio contraintuitivo.

El cambio no es una «revolución» del core, es prolijidad. Ahora la shop devuelve el WP_Post de la página que le asignaste, incluso cuando está seteada como portada del sitio. Relacionado: mostrar datos de productos en WooCommerce.

¿Qué devuelve get_queried_object() ahora en la página de tienda?

Devuelve un WP_Post, el objeto de la página que asignaste como tienda. Antes devolvía un WP_Post_Type (el tipo de contenido «product»). Ojo con un detalle que confunde a muchos: get_post_type_object('product') sigue devolviendo WP_Post_Type como siempre. Ese no se tocó.

// Antes (WooCommerce 10.x) - la shop era la excepción
get_queried_object(); // -> WP_Post_Type
get_post_type_object( 'product' ); // -> WP_Post_Type

// Desde WooCommerce 11.0 - todas las páginas unificadas
get_queried_object(); // -> WP_Post
get_post_type_object( 'product' ); // -> WP_Post_Type

La diferencia práctica es grande. Un WP_Post tiene ID, post_title, post_content, post_status y demás propiedades de una entrada. Un WP_Post_Type tiene name, label, public, rewrite y propiedades de configuración del tipo. Si tu código esperaba una y ahora recibe la otra, algo va a fallar (o a devolver null sin avisar).

Contexto	Antes (WooCommerce 10.x)	Desde WooCommerce 11.0
Página de tienda (shop)	WP_Post_Type	WP_Post
get_post_type_object(‘product’)	WP_Post_Type	WP_Post_Type (sin cambios)
Producto individual	WP_Post	WP_Post (sin cambios)
Categoría, etiqueta, marca o atributo	WP_Term	WP_Term (sin cambios)
is_post_type_archive(‘product’)	true	true (sin cambios)

¿Cómo sé si mi código o extensión está afectada?

Buscá en tu código, temas y plugins las llamadas que leen el objeto de la consulta dentro del contexto de la tienda. Si aparecen, revisá qué esperás que devuelvan. Según WooCommerce, tu extensión o código a medida puede verse afectado si usa alguna de estas:

• get_queried_object(): la más común. Si asumías WP_Post_Type en la shop, ahora recibís WP_Post.
• get_queried_object_id(): el ID que devuelve ahora es el de la página de tienda, no el del tipo de contenido.
• $query->queried_object: mismo cambio, accediendo directo al objeto WP_Query.
• $query->queried_object_id: ídem con el ID.

Un grep rápido por tu carpeta de plugins te resuelve buena parte del diagnóstico. ¿Encontraste un ->name o un ->public colgando de un get_queried_object() en la shop? Ahí tenés un candidato a romperse, porque esas propiedades viven en WP_Post_Type, no en WP_Post. Complementá con mantener una tienda con plugins optimizados.

¿Qué páginas y elementos NO cambiaron?

La mayoría. El cambio se limita a la página de tienda. Todo lo demás sigue devolviendo exactamente lo mismo que antes. Esto es importante para no salir a «arreglar» cosas que nunca estuvieron rotas.

• Productos individuales: el objeto de la consulta sigue siendo el WP_Post del producto. Cero cambios.
• Taxonomías de producto: categorías, etiquetas, marca y atributos siguen devolviendo el WP_Term del término. Igual que siempre.
• Otros archivos y páginas singulares: cualquier otro archivo de tipo de contenido o página individual no se toca.
• Funciones condicionales: is_post_type_archive('product'), is_shop() y compañía funcionan idéntico. No dependen del objeto devuelto.

¿Cómo actualizo el código para WooCommerce 11.0?

Tenés dos estrategias, y la primera es la que yo elegiría casi siempre. En vez de inspeccionar el objeto para saber «en qué página estoy», usá funciones condicionales. Son estables, no cambiaron y expresan tu intención mucho mejor.

Estrategia 1: usar funciones condicionales

// Frágil: dependía del tipo de objeto devuelto en la shop
$obj = get_queried_object();
if ( isset( $obj->name ) && $obj->name === 'product' ) {
 // lógica de la tienda
}

// Robusto: pregunta directa, sin adivinar el objeto
if ( is_shop() ) {
 // lógica de la tienda
}

Estrategia 2: adaptar la lógica a WP_Post

Si de verdad necesitás el objeto (por ejemplo, para leer el título o el ID de la página de tienda), adaptá el acceso a las propiedades de WP_Post. Ahora tenés a mano cosas que antes no, como el título editable de la página.

// En 11.0, get_queried_object() en la shop es un WP_Post
if ( is_shop() ) {
 $page = get_queried_object(); // WP_Post de la página de tienda
 $page_id = $page->ID; // ID de la página
 $page_title = $page->post_title; // Título editable
}

Ejemplos de código real que hay que actualizar

Tres casos que aparecen seguido en plugins y temas a medida. Ponele que tenés alguno de estos: en 10.x andaban, en 11.0 se rompen. Tema relacionado: potenciar tu tienda con IA.

1. Plugin de filtros que lee ->name. Un filtro de productos que hacía get_queried_object()->name === 'product' para activarse en la tienda. En 11.0 el objeto es un WP_Post, no tiene name, y la comparación da falso. El filtro deja de aparecer. La corrección es reemplazar esa comparación por is_shop().

2. Extensión que usa get_queried_object_id() como ID de tipo. Algún código guardaba ese ID esperando que fuera cero o algo neutro (los WP_Post_Type no tienen ID de post). Ahora recibe el ID real de la página de tienda y lo trata como si fuera un producto. Revisá esa suposición.

3. Middleware de caché que arma su clave con el objeto. Este es el clásico silencioso: subís la extensión, la probás en local, funciona, la mandás a producción y de repente el caché de la home mezcla la portada con la tienda porque la clave se generaba a partir del tipo de objeto y ahora ese objeto cambió de forma sin que nadie lo notara. Regenerá la lógica de la clave usando is_shop() o el ID de página.

¿Cómo mantengo compatibilidad con WooCommerce 10.x y 11.0 a la vez?

Si distribuís una extensión para muchos sitios, no podés asumir que todos actualizaron. La forma más limpia es no depender del tipo de objeto para nada: usá funciones condicionales, que devuelven lo mismo en ambas versiones. Con eso, tu código anda igual en 10.x y 11.x sin bifurcaciones. Lo explicamos a fondo en actualizar tus versiones de WooCommerce.

// Funciona igual en 10.x y 11.x: no mira el objeto
if ( is_shop() ) {
 $page_id = wc_get_page_id( 'shop' ); // ID de la página de tienda, estable
 // tu lógica acá
}

Si por algún motivo necesitás ramificar por versión, tenés version_compare() contra WC()->version. Eso sí: úsalo como último recurso, porque agrega deuda que después hay que limpiar cuando 10.x quede fuera de soporte. La detección de feature con is_shop() envejece mejor.

Un apunte de infraestructura: si vas a probar la actualización antes de tocar producción, levantá una copia en un entorno de staging. Un buen hosting WordPress como el de Donweb te deja clonar el sitio y correr WooCommerce 11 en paralelo sin arriesgar la tienda que factura.

Errores comunes al adaptar el código

• Creer que también cambió get_post_type_object('product'): no cambió. Sigue devolviendo WP_Post_Type. Si tu código lo usa, dejalo como está.
• «Arreglar» las páginas de producto o las taxonomías: productos individuales y términos (categorías, etiquetas, marca, atributos) no se tocaron. Meter mano ahí introduce bugs nuevos.
• Reemplazar condicionales que ya funcionaban: is_post_type_archive('product') e is_shop() siguen intactas. Si las estabas usando, ya estás del lado seguro.
• Confiar en ->name para detectar la tienda: esa propiedad vive en WP_Post_Type. Con un WP_Post devuelve null y tu condición falla en silencio, sin error de PHP.

Preguntas Frecuentes

¿Qué cambió en get_queried_object() en WooCommerce 11.0?

En la página de tienda pasó de devolver un objeto WP_Post_Type a devolver un WP_Post. El cambio, disponible desde el 13 de julio de 2026, alinea la shop con el resto de las páginas de WordPress. Ninguna otra página de WooCommerce se vio afectada.

¿Este cambio rompe mi tienda WooCommerce?

Solo si tenés código o extensiones que leen get_queried_object() en la shop esperando un WP_Post_Type. Una tienda estándar con temas y plugins actualizados no se ve afectada. El riesgo está en desarrollos a medida que inspeccionan el objeto de la consulta.

¿Cuál es la diferencia entre WP_Post y WP_Post_Type?

WP_Post representa una entrada concreta y tiene ID, post_title y post_content. WP_Post_Type representa la definición de un tipo de contenido y tiene name, label y public. Son estructuras distintas: leer una propiedad de la otra devuelve null.

¿Cómo detecto la página de tienda sin usar get_queried_object()?

Usá is_shop(), la función condicional oficial de WooCommerce. Devuelve true en la página de tienda y funciona igual en WooCommerce 10.x y 11.0. Es más estable y más legible que inspeccionar el tipo del objeto de la consulta.

¿Cambió el comportamiento en las páginas de producto o categorías?

No. Los productos individuales siguen devolviendo el WP_Post del producto y las taxonomías (categorías, etiquetas, marca y atributos) siguen devolviendo el WP_Term del término. El cambio se limita a la página de tienda.

Conclusión

WooCommerce 11.0 corrigió una vieja rareza: la página de tienda ya no es la excepción y get_queried_object() ahí devuelve un WP_Post, como en cualquier otra página de WordPress. Para la mayoría de las tiendas, esto pasa desapercibido. El foco está en desarrolladores y extensiones que inspeccionan el objeto de la consulta en la shop.

Qué hacer, en concreto: hacé un grep de get_queried_object en tus plugins y temas, y donde uses el resultado para detectar la tienda, reemplazalo por is_shop(). Si necesitás el objeto, adaptalo a las propiedades de WP_Post. Probá en staging antes de subir. Es un cambio chico, pero de esos que fallan en silencio, así que mejor revisarlo ahora y no cuando un cliente te avise que «algo dejó de aparecer».

Fuentes

• WooCommerce Developer Blog – Updating get_queried_object() in the shop (13/07/2026)
• WordPress Developer Reference – get_queried_object()
• WordPress Developer Reference – Clase WP_Post
• WordPress Developer Reference – get_post_type_object()