New function: `get_query_arg()`

[sebastian.pisula]

For example i have url $url = '​http://example.com/?param=1&param2=2&param3=3' and I want get param2 so I use function: get_query_arg('param2', $url);

Second argument: exists function add_query_arg and remove_query_arg

[juliobox]

Hello Sebastian

Can you provide us 2 real examples of usage that you actually need?
One without the query param and another with the param.
Thanks

[joehoyle]

IMP this is little easier than just using parse_url directly, so doesn't add much. -1

[swissspidy]

Replying to joehoyle:

IMO this is little easier than just using parse_url directly, so doesn't add much. -1

Yeah, using parse_url and then parse_str should do the trick. If there aren't any valid use cases for core I'd say -1 as well.

[bastho]

Hi,

I just have an use case:

• Query strings in static source URLs are not the best for performances
• Version parameter is very useful to prevent from unwanted browser cache

Someone (me) could want to hook into script_loader_src in order to move the version from query string to path.

example:

​http://example.com/wp-includes/js/jquery/jquery.js?ver=4.4.2

would become:

​http://example.com/wp-includes/js/jquery/jquery-4.4.2.js

for this, I would use something like that:

<?php

add_filter( 'style_loader_src', 'remove_wp_ver_par', 9999 );
add_filter( 'script_loader_src', 'remove_wp_ver_par', 9999 );
function remove_wp_ver_par( $src ) {
    if ( null !== $ver = get_query_arg( 'ver', $src) ){
        $src = preg_replace( '/\.(js|css)$/', '-_'.$ver.'.$1', remove_query_arg( 'ver', $src ));
    }
    return $src;
}

With the appropriate htaccess/nginx rules, it does the trick.

Actually, I could do it another way but this is the lighter way.

[swissspidy]

A patch would help show the legitimacy of such a function.

[flixos90]

IMO it makes sense to introduce this function. While it is not that complex to do it manually at this point, a function like that would still allow for cleaner code and it also makes sense to introduce this function for parity. We have add_query_arg() and remove_query_arg(), so one could easily assume there is also get_query_arg().

I provided a new patch with 34699.diff​, where $key is also supported to be an array, so it works in the same way like the other two functions. Open question: If $key is an array and one of its keys is not available as query argument, should the result array include the key with value NULL or should it just be left out? For isset() it wouldn't matter, but for array_key_exists() it would. Leaving it out would make the function code a bit simpler, but it would also mean there could be notices if a user simply tries to access a key that is not set.

This function would still need to unit tests, in case the decision is to introduce it. I'll gladly provide those after we have it figured out.

[swissspidy]

I'm not really sure about supporting an array as $key. It makes it way more complex. Also, the function name is get_query_arg() after all. I understand the historical reasons, but I feel like a separate get_query_args() function or array support being something the developer has to implement themselves makes more sense. I doubt it's used often though.

[nevis2us]

I believe this function could be useful for core & plugin devs for the reasons stated above by flixos90. I think it should match add_query_arg() as close as possible. That is it should accept an array of keys and return FALSE not NULL if a key isn't in the query. If $key is an array and one of its keys is not available as query argument, the result array should include the key with value FALSE. Again to match add_query_arg() calling conventions. My 2p. Thank you.

[andizer]

Unit tests