Optimize parse_request for the home page (empty request)

[duck_]

When you visit a site's home page the request (WP::$request) is empty. However we still try to match it against every rewrite rule. By default none of the rules will match. This can be particularly bad when verbose page rules are enabled and WordPress is attempting 700+ regex matches (~50 pages) or more for especially large page oriented sites on an empty string.

The only reason against breaking from the loop like we do for wp-app.php in this case I could think of is if a plugin has added an extra rule to match ^$.[1] If we want to allow this then maybe manually check for a rule == $ and still break early.

[1] This can currently be blocked by #17176 as ()(/[0-9]+)?/?$ matches an empty string

Sort of related: #16736

I really like this. I wouldn't mind checking for ^$ just in case though. I can't see anyone doing that, but still.

A lot more code movement this time so please read and test carefully.

Moved the empty and wp-app.php checks out of the loop, no need to continually run them if they don't pass the first time. Not really sure why but I don't really like the $matches = array(''); we could add a preg_match there just because, thoughts?

Tested with and without:

add_action( 'init', function() { add_rewrite_rule( '$', 'index.php?p=1' ); });

Passes all the rewrite/query tests as well as my random testing. Might want to double check some of the lesser used rewrite structures, e.g. with slug prefix, pathinfo, etc.

Looks good to me.

Looks good but we waited too long for 3.2. Marking for early 3.3.

Looking good at a glance.

No need to check isset() before unset().

Lose unnecessary isset() checks.

In [18466]:

Optimize parse_request for the home page. Props duck_. see #17177

In [18467]:

Explain the empty req_uri branch. Props duck_. fixes #17177

Related: #18276

This change breaks when using IIS 6 with IIRF (I know that's a bit odd) as $req_uri is empty for rewritten urls. If you look at the loop, when $req_uri is empty it just uses the existing value of $request_match so there can be a match for empty $req_uri. I'll attach a patch.

Fixes the check for when $req_uri is empty, but a match is still possible.

I think this is a better patch, but it's a bigger change.

Good catch, thanks.

Not sure what happened between my original ticket where I mention WP::$request specifically and the patches which start checking $req_uri. I think we can just replace $req_uri with $request_match in the empty() call in the if-statement. I think this would be clearer than request2.patch​ (which also unnecessarily sets $request_match on every loop iteration) and, unlike request.patch​, use the correct variable name.

In [19280]:

Use correct variable. We preg_match() against $request_match, so that's what should be checked with empty() too. Fixes #17177.