Path prefix does not work when page URL starts with path prefix

[panupetteri]

Description

Path prefix (https://www.gatsbyjs.com/docs/path-prefix/) does not work when page URL starts with path prefix. For example, if path prefix is /blog and page's URL is blog, navigating to /blog/blog does not work.

This can be demonstrated in:

https://gatsby-path-prefix-bug.netlify.app/blog/blog/

(page works with Javascript disabled, but not with Javascript enabled)

Working example of path prefix can be found in:

https://gatsby-path-prefix-bug.netlify.app/blog/

Steps to reproduce

1. npx gatsby new gatsby-path-prefix-bug https://github.com/gatsbyjs/gatsby-starter-hello-world
2. cd gatsby-path-prefix-bug
3. cp src/pages/index.js src/pages/blog.js
4. Edit gatsby-config.js to contain module.exports = { pathPrefix: "/blog" }
5. npx gatsby build --prefix-paths && npx gatsby serve --prefix-paths
6. Open http://localhost:9000/blog/blog

Expected result

"Hello world!" text should be seen

Actual result

"Hello world!" text is seen for a while and then a blank page is seen

Environment

System:
OS: Windows 10 10.0.19041
CPU: (12) x64 Intel(R) Core(TM) i9-8950HK CPU @ 2.90GHz
Binaries:
Node: 12.16.3 - C:\Program Files\nodejs\node.EXE
npm: 6.14.5 - C:\Program Files\nodejs\npm.CMD
Languages:
Python: 3.8.3 - C:\Python38\python.EXE
Browsers:
Chrome: 86.0.4240.75
Edge: Spartan (44.19041.423.0), Chromium (86.0.622.48)
npmPackages:
gatsby: ^2.24.79 => 2.24.79

[im-adithya]

I am interested. Can anyone help me regarding this?

[ascorbic]

Thanks for the detailed report. This seems to be because we're calling trimPathname more than once on a path. Looking at the network tab, it's requesting page data from index instead of /blog/. @im-adithya if you feel up to it, the relevant code is in packages/gatsby/cache-dir/find-path.js. You'd need to work out where it's being called and why it's being called more than once. You'll find details here on how to get set up. https://www.gatsbyjs.com/contributing/code-contributions/

[im-adithya]

@ascorbic Thank you so much!! I'll try my best to fix this!

[im-adithya]

@ascorbic seems like I've found the bug can you please review it 😃

[github-actions]

Hiya!

This issue has gone quiet. Spooky quiet. 👻

We get a lot of issues, so we currently close issues after 60 days of inactivity. It’s been at least 20 days since the last update here.
If we missed this issue or if you want to keep it open, please reply here.
As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contribute for more information about opening PRs, triaging issues, and contributing!

Thanks for being a part of the Gatsby community! 💪💜

[panupetteri]

Hi,

thanks a lot of updates @ascorbic, @im-adithya and @Kumail786, we appreciate it! We are still having this issue on our end and it stops us from progressing. So the issue is not stale.

Any updates on when this could be fixed? So far, I see one commit (Kumail786@4c05192) and one pull request (#27621) addressing this, but the pull request has broken tests.

[github-actions]

Hiya!

This issue has gone quiet. Spooky quiet. 👻

We get a lot of issues, so we currently close issues after 60 days of inactivity. It’s been at least 20 days since the last update here.
If we missed this issue or if you want to keep it open, please reply here.
As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contribute for more information about opening PRs, triaging issues, and contributing!

Thanks for being a part of the Gatsby community! 💪💜

[github-actions]

Hey again!

It’s been 60 days since anything happened on this issue, so our friendly neighborhood robot (that’s me!) is going to close it.
Please keep in mind that I’m only a robot, so if I’ve closed this issue in error, I’m HUMAN_EMOTION_SORRY. Please feel free to comment on this issue or create a new one if you need anything else.
As a friendly reminder: the best way to see this issue, or any other, fixed is to open a Pull Request. Check out gatsby.dev/contribute for more information about opening PRs, triaging issues, and contributing!

Thanks again for being part of the Gatsby community! 💪💜

[koxu1996]

I stumbled upon this and spend few hours investigating problem. Let's analyze this bug for my case:

1. Here findPath('/blog/blog/here-be-dragons') is called, which calls trimPathname underneath:
   

   gatsby/packages/gatsby/cache-dir/loader.js

   Line 402 in 54d4721

   const realPath = findPath(pagePath)

   
   Return value: /blog/here-be-dragons

2. Then doPrefetch('/blog/here-be-dragons') is called:
   

   gatsby/packages/gatsby/cache-dir/loader.js

   Line 405 in 54d4721

   this.doPrefetch(realPath).then(() => {

3. Then loadPageDataJson('/blog/here-be-dragons') is called, which calls findPath (and trimPath underneath) again:
   

   gatsby/packages/gatsby/cache-dir/loader.js

   Line 191 in 54d4721

   const pagePath = findPath(rawPath)

As a result /blog is trimmed twice and we get /here-be-dragons URL, therefore 404 errors.

[danielmiksavmlyr]

Hi there... It has been 3 years since this BUG was recently commented and it is still not fixed. I have exactly the same problem... I think I know what is the root cause... In loadPage method

gatsby/packages/gatsby/cache-dir/loader.js

Line 211 in 54d4721

loadPage(rawPath) {

you call findPath which internally strip the path prefix once. Lower in the same method you call loadPageDataJson passing already trimmed path (pagePath) and as internally loadPageDataJson call findPath again, then path prefix gets double stripped.

Unfortunately it looks like that this issue is even more complex. Similar duplication still exists in doPrefetch logic as @koxu1996 mentioned above.

[danielmiksavmlyr]

@sidharthachatterjee, @wardpeet I see that you were involved in loader.js (eg. #17412, #25723) module contribution so I assume you have a lot of knowledge on how it works or suppose to work... Unfortunately as I mentioned in my previous comment I see that this very use case has never been considered during implementation... The best idea I have as for now is making sure that findPath is always called on rawPath... So far I discovered that in many use cases findPath is called twice or even more in the way that the outcome from previous call is passed as argument in the next call.