Open StephaneBischoff opened 2 years ago
https://..../_next/data/UhEhAsJqgcuNptbGTt7v2/fr/about.json
is not a namespace file but a static props file.
I had this problem too some time ago, but I thought it was fixed...
What version of next-translate-routes do you use? The last, 1.9.0? If not, can you try with it?
Can you post here the code you use to link towards the about page?
I have a similar issue (using 1.9.1), where static props files seem to be translated although they shouldn't:
This HEAD-request is always sent after clicking a link.
Btw, I'm also wondering why the URL of the prefetched static props (the 1st request on the image) has added the categorySlug
query parameter of the catch-all-route. If the requested file exists, the catch-all page shouldn't even be relevant to next, should it?
Mabye these issues are also related to https://github.com/hozana/next-translate-routes/issues/54
Hello, I have the same issue, although from some reason it's only happening in production (Vercel) if I run it localy with next dev it works fine
@starkys-brzezina Same here, I think that is expected. If I understand it correctly, next tries to access the cached files for the static props under _next/..
. On Dev, caching is turned off though.
@cvolant would you be able to help or point me closer where to look for the issue? 🙏
I will try to have a look at it but I am not sure when I will be able to (new born baby + lot of work...). Can you provide a minimal reproduction?
I understand, it's not a blocker, just a little inconvinience... And congratulations by the way 🙂 Back to the point, I have following config
{ "privacy-policy": { "cs": "ochrana-osobnich-udaju", "en": "privacy-policy" }, "terms-of-use": { "cs": "podminky-pouziti", "en": "terms-of-use" }, "career": { "cs": "kariera", "en": "career" } }
when I'm in cs locale (the customized one or the one that differs from file name) and go from index page to for example /podminky-pouziti by clicking a link the resources should still be loaded as an original filename.json but it tries to load it with the translated name also resulting in one extra. 404 request.. It's only happening in production build, works fine in development
it goes like GET 200 https://dev-extreme.com/_next/data/epE7CxH5axXvKykM_WR-p/cs/terms-of-use.json GET 304 https://dev-extreme.com/_next/data/epE7CxH5axXvKykM_WR-p/cs/terms-of-use.json HEAD 404 https://dev-extreme.com/_next/data/epE7CxH5axXvKykM_WR-p/cs/podminky-pouziti.json
I tried to give a look at it but I don't reproduce this issue. Can provide a minimal reproduction or a reproduction using next-translate-routes /example
?
@cvolant I spent half the day trying to create a reproduction repo, unfortunately without success 🫤 I incrementally took piece by piece from the original project (custom link component, preact, i18 libraries, several configs, next auth, ...), but nothing brought back the HEAD 404 behavior. Quite a riddle 🤔
@vbrzezina @StephaneBischoff Could you maybe try to get a reproduction of this issue? Or maybe you spot any overlaps in our dependencies that might be causing the issue?:
"dependencies": {
"@headlessui/react": "^1.7.7",
"@hubspot/api-client": "^8.0.0",
"@microsoft/applicationinsights-web": "^2.8.9",
"@react-hookz/web": "^19.2.0",
"@stripe/react-stripe-js": "^1.16.4",
"@stripe/stripe-js": "^1.46.0",
"@xstate/react": "^3.0.1",
"applicationinsights": "^2.3.6",
"envalid": "^7.2.1",
"focus-trap-react": "^8.8.2",
"form-data": "^4.0.0",
"friendly-challenge": "^0.9.8",
"hoist-non-react-statics": "^3.3.2",
"i18next": "^22.0.6",
"modern-normalize": "^1.0.0",
"next": "^12.3.4",
"next-auth": "^4.16.4",
"next-i18next": "^13.0.0",
"next-plugin-preact": "^3.0.7",
"next-translate-routes": "1.9.1",
"openid-client": "^5.3.0",
"preact": "^10.11.3",
"preact-render-to-string": "^5.2.6",
"react": "npm:@preact/compat@^17.1.2",
"react-cropper": "^2.1.8",
"react-dom": "npm:@preact/compat@^17.1.2",
"react-hook-form": "^7.3.4",
"react-hot-toast": "^2.4.0",
"react-i18next": "^12.0.0",
"react-icons": "^4.1.0",
"react-paginate": "^8.1.4",
"react-slick": "^0.28.1",
"react-ssr-prepass": "npm:preact-ssr-prepass@^1.2.0",
"rehype-sanitize": "^5.0.0",
"rehype-stringify": "^9.0.2",
"remark": "^14.0.1",
"remark-rehype": "^10.1.0",
"remark-slug": "^7.0.0",
"sharp": "^0.31.2",
"slick-carousel": "^1.8.1",
"unified": "^10.1.0",
"url-parse": "^1.4.7",
"xstate": "^4.34.0"
},
Thank you for the attempt. Maybe the other way around? Starting from the code that has the bug, then removing some pieces?
I have the same problem.
I am using a custom created mapping like this.
This means anything that starts with a matching url is redirected. For example,
/en/about-us.json will work. But /en/hakkimizda.json will be redirected. If I disable this plugin /en/hakkimizda.json also returns the correct response. The default behaviour of nextjs is to request it as /en/hakkimizda.json in the background.
I believe most of these problems can be fixed if there is a way to make the plugin ignore ".json" urls. If one of the main goal of this plugin is to improve SEO and user usability. .json files should be irrelevant.
I found another way. if you filter out the redirect if the following header exists, then probably it will sort itself out
It is hard to debug as I don't reproduce the issue...
Can at least someone post here, it the issue persists with the last version:
<Link href={...}>...
,urlToFileUrl(href)
, href
being the value given to Link
href
prop (as for urlToFileUrl
, it can be imported from next-translate-routes
)?But again, the best would be a public Github repo with a (minimal if possible) reproduction.
Hello,
Yes the issue persists with the latest version.
Here is an example of a direct. there is a redirect rule in NTRConfig such as:
{ en: '/about-us', tr: '/hakkimizda' }
so if a user wants to access http://example.com/en/hakkimizda
it would redirect to http://example.com/en/about-us
next js sends some prefetch ajax as in the screenshot, the server redirects /en/hakkimizda.json
to /en/about-us
. However, this should not redirect as it is a json request for background nextjs business. This redirect happens because of the plugin. For normal user requests everything works as it should.
I think I reproduced this bug while trying to reproduce another one. Without using next-translate-routes. I have this redirect:
async redirects() {
return [
{
source: '/fr/about',
destination: '/fr/a-propos',
locale: false,
},
]
},
And my prefetch (/_next/data/weodsfds_someid_dfslfjds/fr/about.json
) is redirected toward /fr/a-propos
.
I seems to be a bug in Next.js. Or could it possibly be a desired behavior?
Anyway, for now I think we can use @ahmettahasakar approach, but using 'x-nextjs-data' instead of 'purpose' because 'purpose' does not appear in dev.
@cvolant I'm still getting the 404 HEAD request even after updating to the lastest version 🫤
Here are the response headers:
HTTP/1.1 404 Not Found
Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
Content-Security-Policy: frame-ancestors 'none'
Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Resource-Policy: same-origin
Feature-Policy: autoplay 'self'; camera 'self'; geolocation 'self'; payment 'self'; picture-in-picture 'self'; web-share 'self'
Permissions-Policy: autoplay=(self), camera=(self), geolocation=(self), payment=(self), picture-in-picture=(self), web-share=(self)
Referrer-Policy: origin-when-cross-origin
X-DNS-Prefetch-Control: on
X-XSS-Protection: 1; mode=block
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
X-Permitted-Cross-Domain-Policies: none
x-nextjs-matched-path: /de/[...categorySlug]
x-nextjs-cache: MISS
Cache-Control: s-maxage=60, stale-while-revalidate
Date: Fri, 09 Jun 2023 11:45:04 GMT
Connection: keep-alive
Keep-Alive: timeout=5
and the request headers:
HEAD /_next/data/lbHZhxGd4ytwM-0WbAzFE/de/impressum.json HTTP/1.1
Accept: */*
Accept-Encoding: gzip, deflate, br
Accept-Language: de-DE,de;q=0.9,en-US;q=0.8,en;q=0.7
Cache-Control: no-cache
Connection: keep-alive
Cookie: ...
Host: localhost:3000
Pragma: no-cache
Referer: http://localhost:3000
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/114.0.0.0 Safari/537.36
sec-ch-ua: "Not.A/Brand";v="8", "Chromium";v="114", "Google Chrome";v="114"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Windows"
x-nextjs-data: 1
Hi @simonhenke, could you try with next-translate-routes@1.11.0-0
?
@cvolant just tried the prerelease. Similar to https://github.com/hozana/next-translate-routes/pull/84#issuecomment-1836522353 I get the following error (next-translate-routes@1.11.0-3
):
Collecting page data ..ReferenceError: ROUTER_CONTEXT_PATH is not defined
at Object.<anonymous> (C:\...\node_modules\next-translate-routes\react\withTranslateRoutes.js:43:29)
On next-translate-routes@1.11.0-0
-next-translate-routes@1.11.0-2
I get:
error - ./node_modules/next-translate-routes/react/withTranslateRoutes.js:38:0
Module not found: Can't resolve 'next-router-context'
Hi,
Looks like the
next-translate-routes
affects the next-i18n translation file logic. The 18n file (namespace) that is requested is translated.Example folder structure:
For some reason, locally everything works fine for both language. The correct
about.json
file is fetched. But once deployed to Vercel, the.json
file that is request is notabout.json
butnotre-histoire.json
?In the browser, I see the file being fetched as
https://..../_next/data/UhEhAsJqgcuNptbGTt7v2/fr/notre-histoire.json
When it should behttps://..../_next/data/UhEhAsJqgcuNptbGTt7v2/fr/about.json
Looks like a redirect made by
next-translate-route
? I would prefer not having to change the file names (i18n namespaces)