Query Monitor not working on routed pages

[bantunesm]

Hi guys

I’ve noticed that Query Monitor isn’t being included in pages defined in the web.php routes file. Has anyone encountered this issue or knows how to resolve it?

Image below does not help that much, just in case

Thanks

[bantunesm]

I made a hack in a very dirty way but I won’t go further on this. At this point we need to choose WordPress or Laravel for handling requests. It’s unfortunate but I will go with rewrite API, even it will be more tricky to handles ids passed trough urls.

But for testing purposes, here is how I managed to get Query Monitor working on routed pages (web.php file)

Context

I’m using WordPress with Radicle (Sage/Acorn) to use Blade templates and set up routes in routes/web.php. My goal was to load a “welcome” page using a Laravel route while keeping all the WordPress features like Query Monitor and WP conditionals.

What I tried

1. Using a Laravel Route to Show a Blade View:

• I added wp_head() and wp_footer() in the Blade template, but Query Monitor didn’t work.
• WordPress conditionals like is_page() and is_singular() were all false.
• Using get_query_var() didn’t give me the full WordPress context.

2. Forcing WordPress to Initialize in the Route:

• I called WordPress functions like wp(), $wp->register_globals(), and do_action('template_redirect') to try to set up the WP context.
• Checked $wp and $wp_query : $wp was there, but it didn’t recognize the /welcome URL.
• $wp_query showed a 404 error because WordPress saw /welcome as a link to a non-existing post.

Conclusion so far

Even when trying to force WordPress to start, if the URL doesn’t match a real page or post, WordPress doesn’t set up the full context.

3. Creating a “Welcome” Page in WordPress:

• I made a real “Welcome” page in WordPress.
• Now, visiting http://website.com**/welcome** is recognized by WordPress.
• This lets WordPress set up the query correctly, and tools like Query Monitor work.

4. Temporary or Hacky Fixes:

• I could manually change $wp_query by adding fake posts or tweaking is_page flags to trick WordPress.

Main Problem
WordPress uses its own system for loading pages, handling URLs, and templates to set everything up properly. When I add Laravel routes that skip WordPress’s URL handling, things don’t work well:

• If WordPress doesn’t recognize the URL as a page, post, or custom type, it gives a 404 error, and tools like Query Monitor don’t work.
• Even forcing WordPress to load doesn’t fully recreate the context because the custom URLs don’t go through WordPress’s normal process.

Last but not least
I pushed forward to get stuff done without necessary page creation in wordpress back office.

• I deleted Wordpress page
• I deleted the route in web.php
• Applied the following filter to handle the request and make Wordpress believe

add_filter('template_include', function ($template) {
    global $wp, $wp_query;

    // Verifies if request is '/welcome'
    // Not tested with permalinks off, it might be not functional
    if (isset($wp->request) && $wp->request === 'welcome') {

        // Force query WP
        wp();
        $wp->register_globals();

        // Makes a fake post
        $fake_post_data = (object) [
            'ID'             => 999999,
            'post_author'    => 1,
            'post_type'      => 'page',
            'post_title'     => 'Welcome',
            'post_name'      => 'welcome',
            'post_status'    => 'publish',
            'comment_status' => 'closed',
            'ping_status'    => 'closed',
            'guid'           => home_url('/welcome'),
            'post_content'   => '',
            'post_excerpt'   => '',
            'post_date'       => current_time('mysql'),
            'post_date_gmt'   => current_time('mysql', 1),
        ];

        $fake_post = new WP_Post($fake_post_data);

        // Makes query believe
        $wp_query->posts = [$fake_post];
        $wp_query->post_count = 1;
        $wp_query->is_page = true;
        $wp_query->is_singular = true;
        $wp_query->is_404 = false;
        $wp_query->queried_object = $fake_post;
        $wp_query->queried_object_id = $fake_post->ID;
        $GLOBALS['post'] = $fake_post;
        setup_postdata($fake_post);

        // No WordPress believes he founds a page
        // Renders blade view
        echo view('welcome')->render();
        exit;
    }

    // If it's not '/welcome' continues normal processing
    return $template;
});

Final Thoughts
The issue is that Laravel routes (Acorn/Blade) and WordPress don’t work well together. WordPress needs to recognize the route as part of its system (like an existing page or through a rewrite rule) to set everything up correctly. Without that, things like Query Monitor and WP conditionals won’t work. For a stable setup, either create real WordPress pages and let WordPress handle the URLs, or use WordPress’s Rewrite API. That’s a shame, laravel routes were giving fresh new perspectives!

[ben]

@bantunesm

The issue is that Laravel routes (Acorn/Blade) and WordPress don’t work well together.

I disagree with this sentiment overall, but agree that Acorn could improve the compatibility between the two.

Others have already shared examples of how this could be improved. See:

How to register a middleware?

I’ve created a middleware class for displaying the admin-bar on custom routes: <?php declare(strict_types=1); namespace App\Middleware; use Closure; use Illuminate\Http\Request; class WordPress { /** * Makes sure the 'template_redirect' action is executed when using custom routes. * The 'template_redirect' action is required for displaying the WP_Admin_Bar. */ public function handle(Request $request, Closure $next) { do_action('template_redirect'); return $next($request); } }…

[bantunesm]

Nice catch, but unfortunately, it won’t solve the issue. Before opening this thread, I did several tests, particularly with the template_redirect hook, but it doesn’t work as intended. At best, we can get Query Monitor in the admin bar, but its output doesn’t actually load into the DOM.

Manually triggering template_redirect through a Laravel/Acorn middleware is another attempt to replicate WordPress’s normal flow. However, it’s not a “clean” or reliable solution. While it might prompt WordPress to perform additional actions (as I mentioned earlier), it doesn’t guarantee that the necessary context for Query Monitor (or similar tools) will be fully available.

Of course, this perspective is WP-centric and somewhat biased, but that’s not a big concern, there is always others ways.

[ben]

I didn’t suggest that that post would solve your issue. The point I was trying to make is that it’s possible to bridge this gap if you’re willing to put in the work.

We do something similar on the roots.io docs for defining SEO data like titles, descriptions, and social images. We use The SEO Framework on roots.io. All of the docs pages are Acorn routes, and all of the SEO data is populated by the TSF WP plugin even though they aren’t normal WP pages.