nextjs - ✅(Solved) Fix SWR Cache-Control disabled after Next.js 15.5 when using a rewrite middleware [1 pull requests, 6 comments, 6 participants]

stephenliang · 2025-09-16T21:00:32Z

[nextjs] PR 610: Introduce cacheComponents to Cache CMS Calls - Repository: cevi/conveniat-webpage - Author: wp99cp - State: closed | merged: True - Link: http… # PR #610: Introduce cacheComponents to Cache CMS Calls - Repository: cevi/conveniat-webpage - Author: wp99cp - State: closed | merged: True - Link: https://github.com/cevi/conveniat-webpage/pull/610 ## Description (problem / solution / changelog) Currently, all pages are rendered dynamically, i.e. NextJS re-renders them on every request, resulting in one or multiple requests to PayloadCMS (database lookups) for every page visit. This is unnecessary, as the content of our pages is mostly static. This per enables the NextJS 16 cacheComponents feature, which can be used to cache expensive CMS calls between requests. To maximise static pre-rendered content, one must avoid accessing user-specific data while rendering a request, i.e. we can no longer access the `cookies` and/or `queryParameters` of the request. Thus, this PR introduces a significant change to how we render our pages in app/web mode as well as to the draft mode. ## Web Mode versus App Mode Before we checked on every request if the page should be rendered in app mode or in web mode using the cookie. Now we introduce a NextJS middleware (proxy as of NextJS 16), which rewrites the URL internally. For example: `/some-page-slug` gets mapped internally to `/[locale]/[design-mode]/some-page-slug` where `[locale]` is a placeholder for one of our locales (`de`, `en`, `fr`). `[design-mode]` is a placeholder for one of our two design modes (`design-mode-web` or `design-mode-app`). This rewrite can be verified by checking the `x-middleware-rewrite` header of the response. This allows us to generate six versions per page and cache them statically. Namlly, all combinations between locales and design modes. ## Preview Mode Before we checked if the page should be rendered in preview mode by accessing the `queryParameters` and cookies of the request, these variables are user-specific and automatically cause NextJS to opt out of static rendering. Thus, we can no longer rely on those checks to determine if a page should be rendered in preview mode or not. However, NextJS offer a feature called `draftMode` which can be used instead. `draftMode` bypasses the static rendering, forcing the page to be rendered dynamically if enabled. This PR introduces the necessary changes to use `draftMode` instead of checking the cookies directly. Preview mode can be enabled using a call to `/api/draft`. This happens in one of two cases: 1) If you view the PayloadCMS's admin panel, we enable preview mode globally until it is exited manually (for the current session). This happens via a call to `/api/draft?auth=session&slug=*`. 2) If you create and share a preview link. This link works as a redirect which first activates draft mode, then redirects the user to the requested slug. In that case, a call to `/api/draft?auth=secret&preview-token= &preview=true&slug=/the/slug/you/want/to/visit`. In either case, we do a double permission check, once while enabling the draft mode during the execution of the `/api/draft` route (this is done to prevent a malicious user from bypassing static rendering) and once while rendering the actual page (i.e. before fetching the document in draft / published state, we re-check if the user is allowed to visit the **current** page in preview mode. ## Invalidate Cache on Changes When changes are made in the admin panel, we flush the page cache to ensure that saved and published changes are eventually reflected in the publicly visible page. ## Open Todos: - [x] update Readme about dynamic rendering, it's outdated / uses the terminology wrong - [x] invalidate caches on changes (multi-instances) - [x] cache is not shared between instances - [x] search is broken - [x] preview mode URL check is broken (sharing of preview link for a non-landingpage, probably due to internal rewrites) - [x] preview mode banner is not rendered correctly - [x] Language switching results in unwanted URL patterns (e.g., /de//some-slug should be /some-slug, not /de/some-slug and not /de//some-slug) - [x] Page Preview does not work as expected ## Things we Should Test before Merging this PR (@wp99cp) - [x] check if generic pages get rendered correctly - [ ] check if blog pages get rendered correctly - [ ] verify that generic pages get rendered statically - [ ] verify that blog pages get rendered statically - [x] verify preview of generic pages works in PayloadCMS's admin panel - [ ] verify preview of blog pages works in PayloadCMS's admin panel - [ ] verify preview of timeline entries works in PayloadCMS's admin panel - [ ] verify that a preview link can be shared, which only gives preview access to that particular generic page - [ ] verify that a preview link can be shared, which only gives preview access to that particular blog post - [ ] verify that the preview banner is correctly rendered once we have visit

nextjs2025-09-16 21:00:32

ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

GitHub issue URL

Helpful · Quick feedback

GitHub stats

vercel/next.js#83862•Fetched 2026-04-08 02:21:20

View on GitHub

Comments

Participants

Timeline

Reactions

Author

Participants

Timeline (top)

subscribed ×7commented ×6cross-referenced ×2labeled ×2

Code Example

Operating System:
  Platform: linux
  Arch: x64
  Version: #1 SMP PREEMPT_DYNAMIC Sat Aug  2 11:37:34 UTC 2025
  Available memory (MB): 92193
  Available CPU cores: 32
Binaries:
  Node: 20.19.4
  npm: 10.8.2
  Yarn: 1.22.22
  pnpm: N/A
Relevant Packages:
  next: 15.5.3 // Latest available version is detected (15.5.3).
  eslint-config-next: N/A
  react: 19.1.0
  react-dom: 19.1.0
  typescript: 5.9.2
Next.js Config:
  output: N/A

RAW_BUFFERClick to expand / collapse

Link to the code that reproduces this issue

https://github.com/stephenliang/missing-revalidate-rewrite

To Reproduce

Run npm run build to build the application.
Run npm run start to start the production server.
Make a request to http://abc.localhost:3000
Observe the Cache-Control response header.

Current vs. Expected behavior

Expected: s-maxage=3600, stale-while-revalidate=31532400 Actual: private, no-cache, no-store, max-age=0, must-revalidate

Provide environment information

Operating System:
  Platform: linux
  Arch: x64
  Version: #1 SMP PREEMPT_DYNAMIC Sat Aug  2 11:37:34 UTC 2025
  Available memory (MB): 92193
  Available CPU cores: 32
Binaries:
  Node: 20.19.4
  npm: 10.8.2
  Yarn: 1.22.22
  pnpm: N/A
Relevant Packages:
  next: 15.5.3 // Latest available version is detected (15.5.3).
  eslint-config-next: N/A
  react: 19.1.0
  react-dom: 19.1.0
  typescript: 5.9.2
Next.js Config:
  output: N/A

Which area(s) are affected? (Select all that apply)

Dynamic Routes, cacheComponents, Route Handlers, Partial Prerendering (PPR)

Which stage(s) are affected? (Select all that apply)

next start (local), Other (Deployed)

Additional context

Note: This is likely reproducible on the Next.js Multi-tenant Platforms example since this uses the middleware rewrite methodology.

The first canary version that fails is 15.4.2-canary.2. Using canary 15.4.2-canary.1 works as expected. Additionally, 15.4.7 works as expected and is possibly related to #81321. While debugging, I found that the prerender manifest matcher will use the dynamic route regex from the routes manifest. However, this regex will fail if the path was rewritten.

For example, if the path was /[subdomain]/[locale]/[[...rest]] and the incoming page path was /en-US, then it would fail the regex since the rewrite drops the page subdomain portion.

extent analysis

TL;DR

The issue can be mitigated by using a version of Next.js where the prerender manifest matcher correctly handles rewritten paths, such as version 15.4.7.

Guidance

Verify that the issue is indeed related to the prerender manifest matcher by checking if the problem persists when using a version of Next.js known to work, such as 15.4.7.
Check the routes manifest to ensure that the dynamic route regex correctly accounts for rewritten paths.
Consider using the 15.4.7 version of Next.js as a temporary workaround until a more permanent fix is available.
Review the Next.js documentation and release notes to see if there are any known issues or fixes related to the prerender manifest matcher and rewritten paths.

Example

No code snippet is provided as the issue is related to a specific version of Next.js and its handling of prerender manifest matching.

Notes

The issue seems to be specific to certain versions of Next.js, with 15.4.2-canary.2 being the first canary version to exhibit the problem.
The fix may involve updating to a version of Next.js where the prerender manifest matcher correctly handles rewritten paths.

Recommendation

Apply workaround: Upgrade to version 15.4.7 of Next.js, as it is known to work correctly with the prerender manifest matcher and rewritten paths.

Vote matrix · Quick signals

Works

Did the solution work? Tap to confirm.

Easy Fix

Was it a quick fix?

Time Saver

Did it save you time?

Blocking

Was it severely blocking?

Common Issue

Are others likely hitting this too?

Flaky / Intermittent

Is it intermittent?

Verified / Reproducible

Can you reproduce it reliably?

#prompt formatting #chain error #conversation history #tool integration #LLM response

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

nextjs - ✅(Solved) Fix SWR Cache-Control disabled after Next.js 15.5 when using a rewrite middleware [1 pull requests, 6 comments, 6 participants]

Recommended Tools

GitHub issue graph ai analysis

Fix Action

Fixed

PR fix notes

PR #610: Introduce cacheComponents to Cache CMS Calls

Description (problem / solution / changelog)

Web Mode versus App Mode

Preview Mode

Invalidate Cache on Changes

Open Todos:

Things we Should Test before Merging this PR (@wp99cp)

Things we Should Test before Merging this PR (@maede97)

Changed files