To make the WordPress Path back path to the front-end (does not work in the wp-admin context), you need to use 3 WordPress features:
- add_query_arg () - to create a URL with a new query variable ('c' in your example)
- query_vars filter - change the list of public request variables that WordPress knows about (this only works on the interface because WP Query is not used on the back panel -
wp-admin - so it will also not be available in admin-ajax ) - get_query_var () - to get the value of the user query variable passed in your url.
Note: there is no need to even touch superglobals ( $_GET ) if you do so.
Example
On the page where you need to create the link / set the request variable:
if it links to this page simply by adding a query variable
<a href="<?php echo esc_url( add_query_arg( 'c', $my_value_for_c ) )?>">
if this is a link to another page
<a href="<?php echo esc_url( add_query_arg( 'c', $my_value_for_c, site_url( '/some_other_page/' ) ) )?>">
In your functions.php file or in some plugin file or in a special class (only for interfaces):
function add_custom_query_var( $vars ){ $vars[] = "c"; return $vars; } add_filter( 'query_vars', 'add_custom_query_var' );
On the page / function where you want to receive and work with the var request specified in the url:
$my_c = get_query_var( 'c' );
At the back end ( wp-admin )
On the back, we never run wp() , so the main WP request does not start. As a result, there are no query vars , and query_vars does not start.
In this case, you will need to return to more standard approaches to checking your $_GET super $_GET . The best way to do this is probably:
$my_c = filter_input( INPUT_GET, "c", FILTER_SANITIZE_STRING );
although in a pinch you could perform a tried and true
$my_c = isset( $_GET['c'] ? $_GET['c'] : "";
or its variant.