get_queried_object() restituisce null nell'archivio per data dei post
get_queried_object()
restituisce null
negli archivi per data dei post (tipo di pagina is_date()
) e nella pagina principale del blog (tipo di pagina is_home()
). È un comportamento intenzionale o solo una svista?
Stavo scrivendo un wrapper attorno a get_queried_object() per ottenere il titolo della pagina corrente, indipendentemente dal tipo di pagina, da utilizzare in un tema. Mi sono reso conto rapidamente che invece di usare get_query_object()
avrei dovuto semplicemente duplicare le parti importanti da wp_title()
, ma prima di questo mi sono imbattuto in un problema interessante.
Sembra che get_queried_object()
e la sua funzione radice WP_Query->get_queried_object()
restituiscano null
per alcuni tipi di elenchi, incluso l'elenco principale dei post generato da index.php (tipo di pagina is_home()
) e gli archivi dei post per data (tipo di pagina is_date()
).
Ho testato questo inserendo il seguente snippet in diversi file template in varie posizioni, sempre dopo get_header()
e prima di the_post()
:
<pre><code><?php
$queried_object = get_queried_object();
var_dump( $queried_object );
?></code></pre>
Questo funziona perfettamente negli archivi delle categorie, nei tag, negli archivi delle tassonomie personalizzate e negli archivi dei tipi di post personalizzati. get_queried_object()
restituisce l'oggetto query, che può essere utilizzato per estrarre il titolo della pagina e altre informazioni utili.
Tuttavia, fallisce in archive.php per gli archivi standard delle date dei post e in index.php per la visualizzazione dell'elenco normale della home page del blog.
Esaminando il codice sorgente di WP_Query->get_queried_object()
si rivela qualcosa di non sorprendente: non c'è alcun controllo per il tipo di pagina is_home()
o il tipo di pagina is_date()
, quindi su quei tipi di pagina $this->queried_object = null;
non viene aggiornato e la funzione restituisce null
.
Quindi la mia domanda è: questa è una funzionalità intenzionale (ad esempio, non si dovrebbe usare get_queried_object() su quelle pagine), una limitazione tecnica (non c'è un oggetto significativo da restituire su quelle pagine), o semplicemente una svista nell'implementazione?
Esiste anche un equivalente dell'oggetto tipo di post personalizzato per il tipo di post "blog post" integrato da visualizzare?

quindi la mia domanda è, questa è una funzionalità intenzionale (ad esempio, non si dovrebbe usare get_queried_object() su quelle pagine), una limitazione tecnica (non c'è un oggetto significativo da restituire su quelle pagine), o semplicemente una svista nell'implementazione?
get_queried_object() serve per ottenere il termine, l'autore, il singolo post, il singolo custom post type, o l'oggetto pagina che viene interrogato. Sì, questo è intenzionale ed è esattamente ciò per cui questa funzione è stata progettata.
Se sei su un archivio per data, sulla home page, o su una pagina di ricerca non c'è un singolo oggetto che viene interrogato.
Modifica:
Sulla base del primo commento sotto l'OP ha bisogno di ottenere l'oggetto post_type. L'oggetto post_type è diverso dall'oggetto queried_object. Se hai bisogno di ottenere l'oggetto post_type su una pagina archivio puoi ottenerlo dalle query_vars.
global $wp_query;
$post_type_object = get_post_type_object( $wp_query->query_vars['post_type'] );

Questo è fastidioso; se c'è qualcosa di significativo da restituire per le pagine di archivio dei custom post type (l'oggetto del custom post type), perché non dovrebbe essere restituito qualcosa di simile per le pagine di archivio del post type standard? Suppongo che questo possa essere spiegato dalla storia di WP come motore di blogging più focalizzato, ma c'è una buona ragione per cui i post type integrati dovrebbero ricevere questo tipo di trattamento speciale, e non dovrebbero avere la funzionalità per essere gestiti come i tipi personalizzati? Penso che sarebbe più utile se i tipi personalizzati potessero essere più facilmente mescolati con quelli integrati.

Ci sono altri modi per ottenere ciò che vuoi. get_queried_object è applicabile SOLO se la richiesta è una categoria, autore, permalink o Pagina. Contiene informazioni sulla categoria, autore, post o Pagina richiesta. I query_vars contengono tutto il resto.

Allora la mia confusione riguarda la funzionalità di get_queried_object()
sulle pagine di archivio dei custom post type ma non su quelle dei post standard. Se get_queried_object()
restituisce l'oggetto del post type sugli archivi e sulle pagine indice dei custom post type, allora penserei che sia solo logico restituire l'oggetto del post type anche sugli archivi e sulle pagine indice dei post standard. Accetterò la situazione se è semplicemente così per motivi storici e il trattamento speciale dei post type integrati è per la retrocompatibilità, ma vorrei una spiegazione.

credo ci siano informazioni significative che sarebbe utile avere:
l'anno/mese/giorno interrogato, il conteggio dei post/max_num_pages

inoltre nota che nelle pagine di archivio dell'autore get_queried_object()
restituisce un oggetto WP_User
mentre negli archivi basati su termini restituisce un oggetto WP_Term
- quindi è necessario prima sanificare i risultati di get_queried_object()
per usarli in un template di archivio generico - e manca un oggetto WP_Date
.
poiché nel file archive.php dei temi predefiniti il titolo della data utilizza get_the_date()
e questo usa get_post()
rappresenta solo la data del primo post mostrato e logicamente funziona ma non rappresenta esattamente la query e su questo tutto il resto funziona come previsto.

Penso sia una svista, e probabilmente dovrebbe avere un ticket trac con una patch, se qualcuno è interessato a crearne una.
