Shows page not found when url has special characters.

Thanks for reporting the bug. Just tagging this with needs tests since it would be important to have some test coverage for this.

Patch works for me, thanks.

Patch works and applies cleanly,marking as RTBC.

Thank you for the bug fix. Since this is a bug, we should add some test coverage before committing this.

Patch #3 working as expected... thank you

#3 worked for me as well. maybe this can go into he module soon, given that we waited 2 years for tests so far.

#3 worked for me too. Hope it gets committed :)

It seems the code changes introduced some other test failures. The newly created test is failing when the page is not accessible.

I believe the tests are in fact failing due to this change. It wasn't that long ago that I ensured everything was passing on both 8.9 and 9.0.

Let's try that again.

ha, it seems the testbot couldn't differentiate the "/kittens" and "/kitténs" url. I updated the URL in the test case and now it should work.

I have stumbled across this issue, although perhaps it isn't the same but similar. In situations where the path alias has a special character, Drupal\Core\PathProcessor\PathProcessorDecode::processInbound() alters the path before it hits the subpathauto inbound path processor, meaning that subpathauto returns early and doesn't process the path. For example, the path /§-test becomes /%C2%A7-test, which fails the comparison check. This then causes a 404. In this situation, I believe a check should be made against an encoded path just to be sure.

I have attached a patch to this comment with an appropriate solution; it contains no tests currently.

If the issue isn't the same, I would suggest creating a separate issue. The patch provided in #3 fixed the problem for a lot of users and test coverage was added in #14 so I guess the patch in #14 is ready to go.

I'm not getting these patches to cleanly apply. I ran across an issue that has a slightly different approach that applies cleanly—but lacks a test. If a maintainer sees this issue, it might be worth taking the approach that URL encodes all the path parts rather than running things through a regex.

From #3130139:

+  /**
+   * Encodes all parts of a path
+   * @param  string $path 
+   *   The path of the request.
+   * 
+   * @return string      
+   *   The encoded path of the request.
+   */
+  public function encodeParts($path) {
+    $path_parts = [];
+    foreach (explode('/', $path) as $key => $value) {
+      $path_parts[] = urlencode($value);
+    }
+    return implode('/', $path_parts);
+  }
+

Using the original patch in #3, I've written a new test that will apply cleanly. The previous contributed test in #14 adds new node creation to the setup() method of SubPathautoFunctionalTest, which causes the new node to be created for each test in SubPathautoFunctionalTest. In this new patch I've taken a different approach that only creates the new test node once, and better isolates the test case.

This is a re-roll of the patch in #22, removing additional unintended spaces from PathProcessor.php.

One more re-roll of this patch from #22. Reviewing the patch again I notice that the block module is not needed for this test, so this new patch removes 'block' from the array of modules in the test.

#24 works for me :)

/my-group/content/create/group_node:page => works
/my-group/content/create/group_node%3Apage => doesn't work

But with the patch, it works. RTBC, since there's also tests.

Thank you for adding the test coverage! Committed!