A custom WordPress module takes certain int
variable directly from the PHP_URL_PATH
roughly like this:
private function myIdVariable() {
$myid = 0;
// Support both URL formats: /path/123 and /path/?myid=123
$lastpartofurl = (int) basename(parse_url($_SERVER['REQUEST_URI'], PHP_URL_PATH));
$myid = (int) isset($_GET['myid']) ? $_GET['myid'] : $lastpartofurl;
return $myid;
}
Here, the /path/
is the SEO optimized path for the post/article where this module is used, and there's no articles in /path/subpath
.
Before the WordPress 5.5 update this worked, but now /path/123
gets automatically redirected to /path/
. It should result as the same page as /path/?myid=123
for prettier URLs giving better SEO.
Results from the Monkeyman Rewrite Analyzer shows this matches (.?.+?)?(:/([0-9]+))?/?$
.
As this code supports two URL formats, there's a workaround by adding a RedirectMatch
, e.g.
RedirectMatch ^/path/([0-9]+)$ "https://example.com/path/?myid=$1"
However, for a real fix I would like to know:
- What might have added this redirection in WordPress 5.5?
- Is it configurable?
- Is this change in the URL behaviour intended in WordPress 5.5, or should I report a bug?
PHP_URL_PATH
andparse_url
instead of adding a rewrite rule to WP?id
is a post ID? I believe ths might be the canonical URL redirection code, but that wasn't introduced in 5.5, it was introduced years ago. Or it could be that sites rewrite rules match those URLs. Eitherway it's dfficult to suggest an appropriate alternative without more context. Essentially the cause of this is how the code is built, not WP, that's not how routing works in WordPress, and it's a very fragile way to do things, it just hasn't had an obvious bug untill now. Also when you say module, do you mean the function? Or a library?/path/
is a page with a page template then? And you useid
to set which thing to fetch, and that function in your question to figure out what the ID is?