get_queried_object() returnează null în arhiva de date a articolelor
get_queried_object()
returnează null
în arhivele de dată ale articolelor (tip pagină is_date()
) și pe pagina principală de blog (tip pagină is_home()
). Este acest comportament intenționat sau doar o scăpare?
Scriam un wrapper în jurul funcției get_queried_object() pentru a obține titlul paginii curente, indiferent de tipul paginii, pentru utilizare într-o temă. Mi-am dat seama rapid că în loc să folosesc get_query_object()
ar trebui doar să duplic părțile importante din wp_title()
, dar înainte de asta am descoperit o problemă interesantă.
Se pare că get_queried_object()
și funcția sa de bază WP_Query->get_queried_object()
returnează null
pentru câteva tipuri de listări, inclusiv lista principală de articole afișată de index.php (tip pagină is_home()
) și arhivele de articole după dată (tip pagină is_date()
).
Am testat acest lucru prin inserarea următorului fragment de cod în mai multe fișiere template în diverse locații, întotdeauna după get_header()
și înainte de the_post()
:
<pre><code><?php
$queried_object = get_queried_object();
var_dump( $queried_object );
?></code></pre>
Acest lucru funcționează perfect pe arhivele de categorii, arhivele de etichete, arhivele taxonomiilor personalizate și arhivele tipurilor de postări personalizate. get_queried_object()
returnează obiectul interogat, care poate fi folosit pentru a extrage un titlu de pagină și alte informații utile.
Cu toate acestea, eșuează în archive.php pentru arhivele standard de dată ale articolelor și în index.php pentru vizualizarea listei normale de articole de blog de pe pagina principală.
Analizând sursa funcției WP_Query->get_queried_object()
dezvăluie ceva destul de nesurprinzător: nu există o verificare pentru tipul de pagină is_home()
sau tipul de pagină is_date()
, așa că pe acele tipuri de pagini $this->queried_object = null;
nu este actualizat și funcția returnează null
.
Așadar întrebarea mea este, este aceasta o funcționalitate intenționată (de exemplu, nu ar trebui să folosești get_queried_object() pe acele pagini), o limitare tehnică (nu există un obiect semnificativ de returnat pe acele pagini) sau pur și simplu o scăpare în implementare?
Există măcar un echivalent al obiectului pentru tipul de postare personalizat pentru tipul de postare încorporat "blog post" care să fie afișat?

deci întrebarea mea este, este aceasta funcționalitate intenționată (de ex. nu ar trebui să folosești get_queried_object() pe aceste pagini), o limitare tehnică (nu există un obiect semnificativ de returnat pe aceste pagini), sau pur și simplu o omisiune de implementare?
get_queried_object() este folosit pentru a obține termenul, autorul, postarea individuală, tipul custom de postare sau obiectul de pagină care este interogat. Da, acest lucru este intenționat și reprezintă scopul pentru care a fost creată această funcție.
Dacă vă aflați pe o arhivă datată, pagină de start sau pagină de căutare, nu există un singur obiect care să fie interogat.
Editare:
Pe baza primului comentariu de mai jos, OP are nevoie să obțină obiectul post_type. Obiectul post_type este diferit de queried_object. Dacă aveți nevoie să obțineți obiectul post_type pe o pagină de arhivă, îl puteți obține din query_vars.
global $wp_query;
$post_type_object = get_post_type_object( $wp_query->query_vars['post_type'] );

Acest lucru este enervant; dacă există ceva semnificativ de returnat pentru paginile de arhivă ale tipurilor personalizate de postări (obiectul tipului personalizat de postare), de ce nu ar trebui să se întâmple ceva similar pentru paginile de arhivă ale tipurilor standard de postări? Presupun că acest lucru poate fi explicat probabil prin istoria WP ca motor de blogging mai focalizat, dar există vreun motiv întemeiat pentru care tipurile de postări încorporate ar trebui să beneficieze de acest tratament special și să nu aibă funcționalități gestionate la fel ca tipurile personalizate? Cred că ar fi mai util dacă tipurile personalizate ar putea fi mai ușor amestecate cu cele încorporate.

Există alte modalități de a obține ceea ce doriți. get_queried_object este aplicabil DOAR dacă solicitarea este pentru o categorie, autor, legătură permanentă sau Pagină. Conține informații despre categoria, autorul, postarea sau Pagina solicitată. query_vars deține tot restul.

Atunci confuzia mea este funcționalitatea lui get_queried_object()
pe paginile de arhivă ale tipurilor personalizate de postări, dar nu și pe cele standard. Dacă get_queried_object()
returnează obiectul tipului de postare pe paginile de arhivă și index ale tipurilor personalizate, atunci mi s-ar părea logic să returneze obiectul tipului de postare și pe paginile de arhivă și index standard. Voi accepta situația dacă este pur și simplu așa din motive istorice și tratamentul special al tipurilor de postări încorporate este pentru compatibilitatea inversă, dar aș dori o explicație.

cred că ar fi util să avem informații semnificative precum:
anul/luna/ziua care este interogată, numărul de postări/max_num_pages

de asemenea, rețineți că pe paginile de arhivă ale autorului get_queried_object()
returnează un obiect WP_User
în timp ce pe arhivele bazate pe termeni returnează un obiect WP_Term
- așadar, este necesară mai întâi validarea rezultatelor get_queried_object()
pentru a le folosi într-un șablon generic de arhivă - și un obiect WP_Date
lipsește.
deoarece în archive.php din temele implicite, titlul datei folosește get_the_date()
și acesta folosește get_post()
, reprezintă doar data primului post afișat și funcționează logic, dar nu reprezintă exact interogarea și pe baza acestui lucru totul funcționează conform așteptărilor.

Cred că este o omisiune și ar trebui probabil să existe un ticket trac cu un patch, dacă cineva este interesat să realizeze unul.
