Steven Zahm@ SnailsFromJupiter
re: It’s not that $wp_query->post is unset during a 404…but rather that it’s never set at all. In fact, $wp_query->post is unset for all new instances of WP_Query, when it is initialized.
Yep, that’s what I said in this reply; “I find this whole thing odd because the global $post object should not be set on a 404 anyway (I think)“.
I came to that conclusion based on the same code was pointed out in SO.
This is why I wanted to see the var_dumps I asked for in this reply. It should be NULL on 404’s and therefore not pass the comparison and simply return the title without further processing. But since it is passing the comparison, they must not be NULL… I’m still very interested in seeing the results of the var_dump if you’re willing to share.
I definitely agree API/s should be used at all times and leave the globals alone.
I have to deal with other devs directly modding the globals directly all too frequently which breaks things unexpectedly. This is why my immediate thought was that the theme or plugins was the cause.
I ended up with the solution I did after several revisions because of it not working in x-scenario for different users. So far reading the globals directly has been the most reliable.
I see no harm in adding the is_404() check, I probably add it. This is the change I went with 2 days ago.
Since I can not replicate the issue, can you give it a test?
I’m not sure I want to use get_queried_object_id() because the ID returned is contextual. For a post or page it comes from the $wp_query->post->ID anyway, see this.