Fatal Error with WP Query

I’m also seeing this error since updating to 4.6.9

I’d like to echo @nickfmc’s reply. My site has been working for more than three years now and nulls $wp_query temporarily in order to run (many) custom queries on custom post types. I also have used this technique many times and never had an issue with any plugin.

Hey folks,

There are a lot of great points here — let me try to address some of them and add some additional context.

And this is a major issue because this is pretty serious because this is actually a RECOMMENDED practice. Example here by a highly reputable Stack Exchange user.

I’m all for functional solutions and your collective experiences show this particular approach does work in a lot of situations (many bad practices do) … but let’s also keep in mind that this is not an official recommendation, regardless of how high the poster’s reputation currently is (remember also, he originally shared that tip something like 5 years ago).

If someone is using the code that @nickfmc posted, it is good practice because it is NOT modifying the $wp_query global data. If you check it closely, the code is assigning $wp_query to a temp var, doing a separate query using $wp_query, then re-assigning the original $wp_query right back to the way it was.

That side-steps a lot of important detail. Let’s break this down a little more and focus on this section of the code that @nickfmc shared:

$wp_query = null;

$wp_query = new WP_Query(
	array(
		'posts_per_page' => 4,
		'paged' => $paged
	)
);

So, we’re dealing with the global $wp_query variable here and we’re setting it to null. We then create a brand new WP_Query object and assign it back to that same global variable. It’s important to understand – and perhaps it isn’t obvious – that the second assignment doesn’t happen instantly. The chain of events is actually more like this:

• The global $wp_query variable is set to null
• A new query object is created

• Lots of events take place during the creation process…
• …the global $wp_query remains null through all this

• Once the new object is finally created, only then do we update the global $wp_query object so that it is no longer null

Our plugin (but I would hazard to say it is not alone) hooks into a number of the many events that take place during creation of the new query. It quite reasonably expects the global $wp_query object to contain a valid query object – not necessarily the main query object but certainly a valid query and instead it finds null.

That’s why this is a bad practice and it’s telling that you will not observe the same thing in any default themes (Twenty Fifteen … Seventeen etc) that ship with WordPress.

I’m a bit worried about this answer, this is a VERY common technique that is used to assign the WP query to a temp value

I agree both that the prevalence of this technique is common and that it is worrying. In general, we try not to code around bad practices from other themes/plugins but we’re practical people and absolutely strive for a smooth experience for as many users as possible.

That to say, we’re not closed to making some changes to accommodate this sort of thing but I can’t guarantee it and we’ll need to discuss internally. I’ll do my best to drop by with an update once we’ve done so 🙂

Do let me know if you have questions on any of the above.

Hi @nickfmc,

I’m sorry you feel our support is bullish, that’s not our intention by any means. We do our best to be clear and thoughtful and in case it was lost in the detail, I’ll emphasize that we are not opposed to working around this pattern, but it’s also something that merits some discussion internally first of all.

I would argue that your plugin running checks etc when the WP_Query is running even when there is no TEC data anywhere on that page is a waste of resources

There are probably areas where we can tighten things up and we’re continually working to identify and address them, but let’s remember that:

• Typically, in any single request, there isn’t just one WP_Query-powered query – there are lots of them
• We don’t know if event data is being queried for unless we look at those queries – to do that, we need to hook in to them
• We also have solid reasons for looking at queries besides the main WP_Query … for example, widgets or custom event queries may be used outside of event archives

The performance impact of these checks is minimal: if it’s unrelated to event data we bow out as quickly as possible without further interference.

But if you do need to do more than just have a plain blog home page, say, query for the first 3 posts, then query for 3 posts in X category, my understanding is it is actually BEST (even if hacky) to work with the $wp_query object.

That’s a good note, @onetrev.

Agreed – there’s nothing intrinsically wrong or bad about working with the global $wp_query object to learn about its properties or creating new WP_Query objects to obtain the posts you need. No argument there.

I think it’s fair to say however that overriding the global $wp_query object unnecessarily is frowned upon at best and that setting it to null (which is the core problem here) is absolutely a bad practice.