get_queried_object() devuelve null en el archivo de fecha de entradas
get_queried_object()
devuelve null
en los archivos de fecha de entradas (tipo de página is_date()
) y en la página principal del blog (tipo de página is_home()
). ¿Es esto intencional o simplemente un descuido?
Estaba escribiendo un wrapper alrededor de get_queried_object() para obtener el título de la página actual, sin importar qué tipo de página fuera, para usar en un tema. Rápidamente me di cuenta de que en lugar de usar get_query_object()
debería simplemente duplicar las partes importantes de wp_title()
, pero antes de eso me encontré con un problema interesante.
Parece que get_queried_object()
y su función raíz WP_Query->get_queried_object()
devuelven null
para un par de tipos de listados, incluyendo la lista principal de entradas mostrada por index.php (tipo de página is_home()
) y los archivos de entradas por fecha (tipo de página is_date()
).
Probé esto colocando el siguiente fragmento en varios archivos de plantilla en diferentes ubicaciones, siempre después de get_header()
y antes de the_post()
:
<pre><code><?php
// Obtener el objeto consultado
$queried_object = get_queried_object();
var_dump( $queried_object );
?></code></pre>
Esto funciona perfectamente en archivos de categorías, etiquetas, taxonomías personalizadas y tipos de entrada personalizados. get_queried_object()
devuelve el objeto de consulta, que puede usarse para extraer un título de página y otra información útil.
Sin embargo, falla en archive.php para los archivos de fecha de entradas estándar y en index.php para la vista de lista de la página principal del blog.
Investigando en el código fuente de WP_Query->get_queried_object()
revela algo no muy sorprendente: no hay una comprobación para el tipo de página is_home()
o tipo de página is_date()
, por lo que en esos tipos de página $this->queried_object = null;
no se actualiza y la función devuelve null
.
Entonces mi pregunta es, ¿es esta una funcionalidad intencionada (por ejemplo, no se supone que uses get_queried_object() en esas páginas), una limitación técnica (no hay un objeto significativo para devolver en esas páginas), o simplemente un descuido en la implementación?
¿Existe incluso un equivalente del objeto de tipo de entrada personalizada para el tipo de entrada "entrada de blog" incorporado para mostrar?

Entonces, mi pregunta es, ¿es esta una funcionalidad intencionada (por ejemplo, no se supone que debas usar get_queried_object() en esas páginas), una limitación técnica (¿no hay un objeto significativo que devolver en esas páginas?), o simplemente un descuido en la implementación?
get_queried_object() sirve para obtener el término, autor, publicación individual, tipo de publicación personalizada individual o el objeto de página que se está consultando. Sí, esto es intencional y para eso fue diseñada esta función.
Si estás en un archivo de fecha, página de inicio o búsqueda, no hay un único objeto que se esté consultando.
Edición:
Basado en el primer comentario abajo, el OP necesita obtener el objeto post_type. El objeto post_type es diferente del queried_object. Si necesitas obtener el objeto post_type en una página de archivo, puedes obtenerlo de los query_vars.
global $wp_query;
$post_type_object = get_post_type_object( $wp_query->query_vars['post_type'] );

Esto es irritante; si hay algo significativo que devolver para las páginas de archivo de tipos de contenido personalizados (el objeto del tipo de contenido personalizado), ¿por qué no debería devolverse algo similar para las páginas de archivo del tipo de contenido estándar de entradas? Supongo que esto probablemente se puede explicar por la historia de WP como un motor de blogs más enfocado, pero ¿hay alguna buena razón por la que los tipos de contenido integrados deban recibir este tipo de trato especial, y no deberían tener la funcionalidad para manejarse igual que los tipos personalizados? Creo que sería más útil si los tipos personalizados pudieran mezclarse más fácilmente con los tipos integrados.

Hay otras formas de obtener lo que quieres. get_queried_object es aplicable SOLAMENTE si la solicitud es una categoría, autor, enlace permanente o Página. Contiene información sobre la categoría, autor, entrada o Página solicitada. Los query_vars contienen todo lo demás.

Entonces mi confusión es la funcionalidad de get_queried_object()
en las páginas de archivo de tipos de contenido personalizados pero no en las páginas de archivo de entradas estándar. Si get_queried_object()
devuelve el objeto del tipo de contenido en las páginas de archivo e índice de tipos de contenido personalizados, entonces pensaría que es lógico que devuelva el objeto del tipo de contenido en las páginas de archivo e índice de entradas estándar. Aceptaré la situación si simplemente es así por razones históricas y el manejo especial de los tipos de contenido integrados es por compatibilidad con versiones anteriores, pero me gustaría una explicación.

creo que hay información significativa que sería genial tener:
qué año/mes/día se consulta, recuento de publicaciones/max_num_pages

también ten en cuenta que en las páginas de archivo de autor get_queried_object()
devuelve un objeto WP_User
mientras que en los archivos basados en términos devuelve un objeto WP_Term
- por lo que primero hay que sanitizar los retornos de get_queried_object()
para usar en una plantilla de archivo genérica - y falta un objeto WP_Date
.
dado que en el archive.php de los temas predeterminados el título de fecha usa get_the_date()
y eso usa get_post()
solo representa la fecha de la primera publicación mostrada y lógicamente funciona pero no representa exactamente la consulta y basándose en eso todo lo demás funciona como se espera.

Creo que es un descuido, y probablemente debería tener un ticket en trac con un parche, si alguien está interesado en hacer uno.
