Where I begin investigating WordPress routing possibilities.
Inspiration
I’ve just finished looking the Hardcore WordPress Routing video and that could not bring up memories of an experiment I’ve made to replicate what Laravel does in terms of routing in WordPress extending the WP-Router plugin by Jonathan Brinley, an amazing human being and developer I’ve had the pleasure to meet.
That experiment of mine, though, did fail in its purpose of giving me something I could reliably use in some scenarios and, in the end, I’ve moved on from that.
Trying again?
A point Mike Schinkel illustrated in the his presentation is the introduction of the do_parse_request filter to allow people to “do anything”.
I want the answers to some questions:
- What can I do using the
do_parse_requestfilter? - At which point is the filter called in the WordPress flow?
- Could this be the way to a “WordPress as an admin-only tool” approach to WordPress development?
In terms of code I require writing some to understand how things work so I’ve fired up my development WordPress installation and wrote a small plugin to gather the information:
/**
* Plugin Name: theAverageDev Routes
* Plugin URI: http://theAverageDev.com
* Description: Routing for WordPress
* Version: 1.0
* Author: theAverageDev
* Author URI: http://theAverageDev.com
* License: GPL 2.0
*/
global $_filters;
add_action( 'all', '_log_filter' );
add_filter( 'all', '_log_filter' );
$_filters = array();
function _log_filter() {
global $_filters;
$current_filter = current_filter();
if ( $current_filter == end( $_filters ) ) {
return;
$pattern = '/((pre_)*option_|get_user_|twentyfifteen_|(template|stylesheet)_directory_|sanitize_|wp_(audio|video)|post_type_|load_textdomain_|gettext|.*kses|theme_locale|salt).*$/';
if (preg_match( $pattern,$current_filter)) {
return;
}
if (in_array($current_filter,$_filters)) {
return;
}
$_filters[] = $current_filter;
}
/**
* `do_parse_request` filter description
*
* Filter whether to parse the request.
*
* @since 3.5.0
*
* @param bool $bool Whether or not to parse the request. Default true.
* @param WP $this Current WordPress environment instance.
* @param array|string $extra_query_vars Extra passed query variables.
*/
add_filter( 'do_parse_request', 'tad_routes_do_parse_request', 1, 3 );
function tad_routes_do_parse_request( $continue, WP $wp, $extra_query_vars ) {
if ( preg_match( '~\\/my-route\\/?$~', $_SERVER['REQUEST_URI'] ) ) {
global $_filters;
array_pop($_filters);
echo sprintf( "Filters/actions executed before do_parse_request:\n\n%s", "" . implode( '', $_filters ) . "" );
die();
}
return $continue;
}
In the first part I set up some code to log any call to the do_action and apply_filters functions and the action or filter tag excluding some I’m not interested in; in the second part I hook into the do_parse_request filter to try to match the /my-route route and, should that be the case, I will output the list of called actions and filters to this point, will block WordPress routing and die().
The output, when I visit the /my-route path, is as follows: 
The end result shows me something:
- If I make sure my function/handler/controller should kick then I can stop WordPress flow and return something of my own.
- The log shows me I will have a fully loaded WordPress session when the
do_parse_requestfilter is called - WordPress has, of course, not yet parsed the request setting up any query var
While the first two points are very good news the last one puts me in charge of handling the request and returning something relevant.
The premises are good enough to investigate further.