Support default values for non-existant query vars in get_query_var() et al

[hakre]

When using get_query_var($var) or $GLOBALS['wp']->get($var) and $var is the name of an unexistant query variable, those functions will return an empty string.

Next to that there is no function that provides information about whether or not a specific query variable has been set.

I therefore suggest to make both functions able to optionally return a chooseable default fallback value then the empty string we have.

[hakre]

The attached patch now allows easier checking if certain values have been set (not being null in PHP):

$var_test = get_query_var('test', null);
if (!isset($var_test)) {
    throw new BadMethodCallException ('Invalid request. Test parameter not set.');
}

or making use of a predefined, default value more easily:

$days = get_query_var('days', 7);

[scribu]

+1. Similar to get_option().

[helen]

This just bit me. Can has?

[nacin]

Interesting. We've discussed this before, in #15178, then in #19243. I never saw this ticket, but it turns out it is probably the best immediate solution. I'd prefer to change the return value to false from '' (as stated in #15178) but I feel like that could break things. exists() would be nice too but this would be an immediate thing.

Part of the issue found in #19243 is that fill_query_vars() sets a bunch of query variables to ''. This is in part due to the ability to call parse_query() and get_posts() more than once in a single WP_Query instance (which is weird, nonetheless), so there needs to be some reset. The issue here would be that a $default of something other than '' would never be hit for a default "filled" query variable. Which is why this isn't a straight commit. But I'd love to resolve it.

[helen]

Go figure, my brief search didn't turn up the others. I would also prefer false for the return, but I guess people could be using a strict comparison right now and then that would get all broken. This seemed like a reasonable solution to me given that, but will have to think on the fill_query_vars() thing.

[nacin]

#19243 was marked as a duplicate.

[nacin]

Still need to figure out filled vars.

[wonderboymusic]

Can someone add a concrete example of why this matters? I don't see the benefit.

get_query_var( 'post_type', 9 ) <--- what does that accomplish?

[nacin]

Replying to wonderboymusic:

Can someone add a concrete example of why this matters? I don't see the benefit.

get_query_var( 'post_type', 9 ) <--- what does that accomplish?

It can be helpful in some situations where a query variable is an "add on" — it has a default value that is otherwise assumed. "post_type" is probably not a great example. Ordering is, as are a number of other QVs.

It is absolutely helpful when working with endpoints. #15178, #19243, both quoted above.

[helen]

Replying to wonderboymusic:

Can someone add a concrete example of why this matters? I don't see the benefit.

Endpoints. get_query_var( 'something' ) gives you the same result with or without add_rewrite_endpoint( 'something', EP_PAGES ), which is just sad/horrible/etc.

[helen]

#27209 was marked as a duplicate.

[nacin]

In 27304:

Add a $default argument to get_query_var() and WP_Query::get(). fixes #16471.