WordPress Development Stack Exchange is a question and answer site for WordPress developers and administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

get_queried_object() returns null on post date archives (page type is_date()) and the main blog index page (page type is_home()). Is this intentional, or just an oversight?

I was writing a wrapper around get_queried_object() to get the title of the current page, no matter what type of page it is, for use in a theme. I quickly realized that instead of using get_query_object() I should just duplicate the important bits from wp_title(), but before that I came across an interesting issue.

It appears that get_queried_object() and its root function WP_Query->get_queried_object() return null for a couple of listing types, including the primary posts list output by index.php (page type is_home()) and post archives by date (page type is_date()).

I tested this by throwing the following snippet into a number of template files in a number of locations, always after get_header() and before the_post():

    $queried_object = get_queried_object();
    var_dump( $queried_object );

This works perfectly on category archives, tag archives, custom taxonomy archives, and custom post type archives. get_queried_object() returns the query object, which can be used to extract a page title and other useful information.

However, it fails in archive.php for standard post date archives and index.php for the normal blog posts home page list view.

Digging into the source of WP_Query->get_queried_object() reveals something rather unsurprising: there is no check for page type is_home() or page type is_date(), so on those page types $this->queried_object = null; is not updated and the function returns null.

So my question is, is this intended functionality (e.g. are you not supposed to use get_queried_object() on those pages), a technical limitation (is there not a meaningful object to return on those pages), or simply an implementation oversight?

Is there even an equivalent of the custom post type object for the built-in "blog post" post type to display?

share|improve this question
Great point +. WordPress could do something to create an object for those date archive and front page italic_(note: it do return an object if blog page is set to a wordpress page, not the front page)_italic . But at the end, there's no meaningful use of get_queried_object. – Shazzad Jan 5 '14 at 22:49
I don't know how to answer this question,r eally, but yes, get_queried_object is very inconsistent and returns several different objects as well as sometimes returning null. While it is useful, it can be frustrating to use. – s_ha_dum Jan 5 '14 at 23:02
up vote 1 down vote accepted

so my question is, is this intended functionality (e.g. are you not supposed to use get_queried_object() on those pages), a technical limitation (is there not a meaningful object to return on those pages), or simply an implementation oversight?

get_queried_object() is to get the term, author, single post, single custom post type, or page object being queried. Yes this is intentional and what this function was designed to do.

If you are on a date archive, home page, or search there is no single object being queried.


Based on the first comment below the OP needs to get the post_type object. The post_type object is different from the queried_object. If you need to get the post_type object on an archive page you can get it from the query_vars.

global $wp_query;

$post_type_object = get_post_type_object( $wp_query->query_vars['post_type'] );
share|improve this answer
This is irritating; if there is something meaningful to return for custom post type archive pages (the custom post type object), why shouldn't something similar return for the standard post post type archive pages? I suppose this can probably be explained by WP's history as a more focused blogging engine, but is there any good reason that build-in post types should get this kind of special treatment, and should not be given the functionality to handle just like custom types? I think it'd be more useful if custom types could be more easily mixed with builtin types. – Dakota Jan 6 '14 at 21:20
There are other ways to get what you want. get_queried_object is applicable ONLY if the request is a category, author, permalink or Page. Holds information on the requested category, author, post or Page. The query_vars hold everything else. – Chris_O Jan 6 '14 at 21:38
Then my confusion is the functionality of get_queried_object() on custom post type archive pages but not on standard post archive pages. If get_queried_object() returns the post type object on custom post type archive and index pages, then I would think it only logical to return the post type object on standard post archive and index pages. I will accept the situation if it's simply like that for historical reasons and the special handling of the built-in post types is for backwards-compatibility, but I would like an explanation. – Dakota Jan 7 '14 at 4:33

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.