3

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]+))?/?$.

enter image description here

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:

  1. What might have added this redirection in WordPress 5.5?
  2. Is it configurable?
  3. Is this change in the URL behaviour intended in WordPress 5.5, or should I report a bug?
6
  • Have you tested the rewrite rules using monkeyman rewrite rules analyser to see if the URL is picked up by an existing rewrite rule in core? I'm curious why you used PHP_URL_PATH and parse_url instead of adding a rewrite rule to WP?
    – Tom J Nowell
    Commented Aug 12, 2020 at 12:14
  • That's because the plugin needs to work regardless of configuring any rewrite rules in WordPress, on any post/article where it's used. While it might be possible for a plugin to add rewrite rules, it's also likely to cause more problems than it solves, given the module is used in many pages. Commented Aug 12, 2020 at 12:21
  • That sounds highly suboptimal. I take it 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?
    – Tom J Nowell
    Commented Aug 12, 2020 at 14:07
  • It's not a post id, but for getting some custom content from an external source not directly related to the WP installation. It also has dependencies on an intermediate framework which has some limitations, making this approach pretty suitable, but explaining that would make this question out of tracks... It's just that before WP 5.5 it was possible to add a suffix to the path and now it isn't. I was also able to reproduce this on a test environment, showing it breaks on the upgrade. I'll take a look with the Monkeyman analyzer. Thanks for the hint! Commented Aug 12, 2020 at 14:18
  • II take it then /path/ is a page with a page template then? And you use id to set which thing to fetch, and that function in your question to figure out what the ID is?
    – Tom J Nowell
    Commented Aug 12, 2020 at 23:11

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Browse other questions tagged or ask your own question.