WordPress.org

Make WordPress Core

Opened 7 years ago

Closed 4 years ago

#16471 closed enhancement (fixed)

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

Reported by: hakre Owned by: nacin
Milestone: 3.9 Priority: normal
Severity: normal Version: 3.0
Component: Query Keywords: has-patch
Focuses: Cc:

Description

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.

Attachments (1)

16471.patch (979 bytes) - added by hakre 7 years ago.

Download all attachments as: .zip

Change History (14)

@hakre
7 years ago

#1 @hakre
7 years ago

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);

#2 @scribu
7 years ago

+1. Similar to get_option().

#3 @mikeschinkel
7 years ago

  • Cc mikeschinkel@… added

#4 @helen
5 years ago

This just bit me. Can has?

#5 @nacin
5 years ago

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.

#6 @helen
5 years ago

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.

#7 @nacin
4 years ago

#19243 was marked as a duplicate.

#8 @nacin
4 years ago

  • Component changed from General to Query
  • Milestone changed from Awaiting Review to 3.9

Still need to figure out filled vars.

#9 follow-ups: @wonderboymusic
4 years ago

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?

#10 in reply to: ↑ 9 @nacin
4 years ago

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.

#11 in reply to: ↑ 9 @helen
4 years ago

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.

#12 @helen
4 years ago

#27209 was marked as a duplicate.

#13 @nacin
4 years ago

  • Owner set to nacin
  • Resolution set to fixed
  • Status changed from new to closed

In 27304:

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

Note: See TracTickets for help on using tickets.