Bug: `EE_Front_Controller::get_request()` cause actions on `parse_request` to be skipped

[jakejackson1]

Describe the bug
EE_Front_Controller::get_request() runs on parse_request priority 1 and for whatever reason removes itself during its execution. If another plugin adds an action on the parse_request hook with a priority 0, when EE_Front_Controller::get_request() removes itself it causes WordPress to skip the actions registered on priority 10.

To Reproduce
On a vanilla WordPress installation with no plugins activated:

1. Set WP_DEBUG to true and WP_DEBUG_LOG to true
2. Add the following code snippet to an MU Plugin (or similar):

add_action( 'parse_request', function($wp) {
	error_log( 'This will be logged...' );
}, 0 );

add_action( 'parse_request', function($wp) {
	error_log( 'This will be skipped when Event Espresso is activated...' );
}, 10 );

3. Load the homepage and then review /wp-content/debug.log to verify both messages are logged
4. Activated Event Espresso
5. Load the homepage and check the log again. Only the first message is logged; the second has been skipped

A real-world example of this bug can be seen if you install the LifterLMS plugin alongside Event Espresso. It registers on priority 0 of parse_request and triggers the bug.

Expected behavior
All registered hooks on parse_request should execute. Could the remove_action() line be removed? If it's important to unhook this code, perhaps it could be delayed until after parse_request completes, or on a very late priority 9999?

Environment:

• Version of Event Espresso: 5.0.37.decaf and 5.0.45
• Version of WordPress: 6.8.2
• Browser: any
• PHP Version 8.1, 8.4

[tn3rb]

re:

EE_Front_Controller::get_request() runs on parse_request priority 1 and for whatever reason removes itself during its execution.

That's to prevent that hook callback from being called again. Some theme's and plugins will manually trigger the parse_request action before or after WordPress does, and we don't want that logic running more than once. It was literally added as a defence against rogue third party code causing problems.

Load the homepage and check the log again. Only the first message is logged; the second has been skipped

I'm sorry but I am unable to recreate this issue.

A real-world example of this bug can be seen if you install the LifterLMS plugin alongside Event Espresso. It registers on priority 0 of parse_request and triggers the bug.

done, but still could not recreate the issue. Could this be an issue with THAT plugin?

Are you 100% positive that there isn't something else happening on your site that is ending the request early or redirecting before those other callbacks can run?

This is what I did:

Add the following code snippet to a plugin mainfile, or your theme's functions.php before any other code, or anywhere that is guaranteed to run before the WP init hook:

add_action(
    'init',
    function () {
        // generate a random string to use as an ID for each request
        $REQ_ID = bin2hex(random_bytes(4));
        $URI    = $_SERVER['REQUEST_URI'] ?? '???';
        error_log("***********************************************************");
        error_log("[REQ_ID: $REQ_ID] URI: $URI");

        // hook into the action at the top of EE_Front_Controller::get_request()
        // this should run during parse_request at priority 1
        add_action(
            'AHEE__EE_Front_Controller__get_request__start',
            function () use ($REQ_ID) {
                error_log("[REQ_ID: $REQ_ID] EE_Front_Controller::get_request() P1");
            }
        );
        // now hook into parse_request directly at priorities 0, 5, & 10
        add_action(
            'parse_request',
            function () use ($REQ_ID) {
                error_log("[REQ_ID: $REQ_ID] WP HOOK parse_request P0");
            },
            0
        );
        add_action(
            'parse_request',
            function () use ($REQ_ID) {
                error_log("[REQ_ID: $REQ_ID] WP HOOK parse_request P5");
            },
            5
        );
        add_action(
            'parse_request',
            function () use ($REQ_ID) {
                error_log("[REQ_ID: $REQ_ID] WP HOOK parse_request P10");
            }
        );
    }
);

The reason I added all of those hooks within another callback was so that I could use that same REQ ID for each log entry. This will help to differentiate between requests. I suspect that something in your set up is killing one of your requests, or redirecting, or performing an internal redirect, or you're just getting so many entries in your debug.log that you aren't seeing the other entries. I don't know of course, i'm just totally speculating. You can search for a REQ ID though to see if there are any missed entries elsewhere.

Here's the output that i see after refreshing my homepage:

[24-Sep-2025 02:43:12 UTC] ***********************************************************
[24-Sep-2025 02:43:12 UTC] [REQ_ID: 63cb9888] URI: /
[24-Sep-2025 02:43:12 UTC] ***********************************************************
[24-Sep-2025 02:43:12 UTC] [REQ_ID: 83cd2846] URI: /wp-cron.php?doing_wp_cron=1758681792.5950539112091064453125
[24-Sep-2025 02:43:13 UTC] [REQ_ID: 63cb9888] WP HOOK parse_request P0
[24-Sep-2025 02:43:13 UTC] [REQ_ID: 63cb9888] EE_Front_Controller::get_request() P1
[24-Sep-2025 02:43:13 UTC] [REQ_ID: 63cb9888] WP HOOK parse_request P5
[24-Sep-2025 02:43:13 UTC] [REQ_ID: 63cb9888] WP HOOK parse_request P10
[24-Sep-2025 02:43:13 UTC] ***********************************************************
[24-Sep-2025 02:43:13 UTC] [REQ_ID: eddde54b] URI: /favicon.ico
[24-Sep-2025 02:43:13 UTC] [REQ_ID: eddde54b] WP HOOK parse_request P0
[24-Sep-2025 02:43:13 UTC] [REQ_ID: eddde54b] WP HOOK parse_request P5
[24-Sep-2025 02:43:13 UTC] [REQ_ID: eddde54b] WP HOOK parse_request P10

Notice the REQ_ID and how entries for a request are not all sequential.
You can see that a WP Cron was initiated on a separate request immediately after my homepage request started. It's possible that a secondary request, like that wp-cron may somehow be interfering with that parse_request hook point. I'm really baffled by this, and have tried everything to recrete the issue (yes I tried your exact code snippets).

What's important though, is that I'm also seeing ALL of the hooks that were added to parse_request on different priorities.

Now that all said, it is perfectly acceptable to have a hook callback remove itself from the WP filters array. Doing so will NOT remove other callbacks. I tried to find a direct reference to this in the WP documenatation but could not find anything that explicitly states this. I can post the WordPress source code though and walk you through it line by line if you don't believe me.

If you are so inclined, you can also go ask Chat GPT or an AI of your choice something like:

can a WordPress action callback call remove_action() on itself?

and they will tell you it is ok and will not remove other callbacks at other priorities.

Bottom line, I can't just remove that line of code that removes that action, because it was specifically added to prevent other plugins and themes from running that logic more than once.
What I CAN do though, is add a static guard clause at the top of EE_Front_Controller::get_request() that would effectively do the same thing.

You can try this if you like, add the following to the top of EE_Front_Controller::get_request():

static $done = false;
if ($done) {
    return;
}
$done = true;

and then comment out:

remove_action('parse_request', [$this, 'get_request'], 1);

See if that helps. If it does I can try to get that snippet added in our next release, but I still think you have something funny going on with your site, that you should continue to look into.

[jakejackson1]

Hey @tn3rb,

Thanks for all the feedback. I believe this is the bug in WordPress Core being triggered when EE_Front_Controller::get_request() removes it's own action under a specific set of circumstances.

The tests I ran show the order and number of registered actions on a hook is important to reproduce the issue, and could by why you weren't able to in your testing environment. For example, running the sample code you provided on a Vanilla WP installation with only the WP.org version of Event Espresso installed shows WP HOOK parse_request P5 gets skipped. If you remove the hook on priority 5 then the priority 10 hooks are skipped.

You mentioned multiple requests could be mixing up the log file. To completely remove it from the example you can do this instead:

add_action( 'parse_request', function( $wp ) {
	// doesn't matter what it does. The hook just needs to be added
}, 0 );

add_action( 'parse_request', function( $wp ) {
	wp_die( 'Hurray! This has run.' );
}, 10 );

Load the home page on a completely vanilla WP installation after adding the above code and you'll get the wp_die message. Activate Event Espresso plugin and reload the home page and you won't get the wp_die message.

If you're not able to reproduce this locally, I've set you up a temporary test site with the above snippets already added: https://wordpress-761390-5879439.cloudwaysapps.com. Use your GitHub handle for the login (u and p are the same). If you go to the Snippets menu and toggle off priority 0, the home page will correctly show the error. Toggle it on and the home page will incorrectly load. Disable the Event Espresso plugin and the home page will correctly show the error again.

Storing whether your hook has run in a static variable instead of removing the action would solve the problem. It looks like your codebase already makes use of an initialized property in other classes to prevent functionality from running more than once, and that pattern would work too.

I'm with you though. This is a super obscure WP Core bug, isn't mentioned anywhere in the WordPress docs, and took me far too long to diagnose.

[tn3rb]

I believe this is the bug in WordPress Core being triggered

sigh... originally reported 8 years ago 😞

This is bonkers. No matter what I do, I can't get this to happen on my local site.

Here's my debug.log with your original code snippets:

[24-Sep-2025 15:30:53 UTC] This will be logged...
[24-Sep-2025 15:30:53 UTC] This will be skipped when Event Espresso is activated...
[24-Sep-2025 15:30:54 UTC] This will be logged...
[24-Sep-2025 15:30:54 UTC] This will be skipped when Event Espresso is activated...

and here's with your new snippets:

And that's with both Event Espresso AND LifterLMS active:

Same thing happens with LifterLMS active disabled.

The ONLY difference is that I have been testing with Event Espresso version 5.0.45.002 whereas you were on the release version of 5.0.45, so it's possible that something in the two PRs that were merged since 5.0.45 has somehow fixed this issue, but i've looked at that code and don't see how that could be, but who knows 🤷🏻‍♂️

Anyways, there's no point in me testing on your temporary test site (thanks for setting that up though) as that doesn't really help me diagnose what's actually happening in the code. At this point I'm certain it's just that obscure old WP core bug that is causing this. Wish you had posted that link in your original post. I'll just move forwards with using that static guard clause in EE_Front_Controller::get_request() instead of remove_action().

[jakejackson1]

I'll just move forwards with using that static guard clause in EE_Front_Controller::get_request() instead of remove_action().

Sounds good.

Wish you had posted that link in your original post.

After you mentioned you had trouble replicating the issue, that's when I started searching Trac for similar bug reports. Thanks for all the effort you put in trying to resolve this. 👍

[tn3rb]

fixed and released in v5.0.51