Draft Mode does not work in Middleware #67075
Labels
Comments
|
@JKarlavige next.js/packages/next/src/server/async-storage/draft-mode-provider.ts Lines 40 to 45 in c839d58 May be you can use |
|
Quick question on Draft Mode - does it require integration of a Headless CMS or can we use it without one? |
|
This closed issue has been automatically locked because it had no new activity for 2 weeks. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you. |
lubieowoce
pushed a commit
that referenced
this issue
Aug 22, 2024
Chnage the way of preview props injection to edge runtime, directly read from env vars of preview props instead of writing to and reading from prerender manifest.js Previously we're trying to make these preview props values become deterministic that we can replace in edge deployment pipeline in #64521 But the way of serializing process env vars in edge runtime is not correct. They'll remain as string "process.env.xxx" in the manifest and also after consumed. This PR fixes that behavior, instead of writing it into manifest, alwyas consuming from process.env.var directly. I created a shared util to access the preview props of edge runtime across all the templates. On draft provider side, we still need to handle dev mode case when preview id is `development-id`, but we already have the cookie, it cannot be aligned with the preview id. So we do a fallback check for dev mode if the cookie is present and preview id is `development-id` then we still treat it as draft mode is enabled. Fixes #52080 Fixes #67075 Closes NEXT-3541
lubieowoce
pushed a commit
that referenced
this issue
Sep 2, 2024
Chnage the way of preview props injection to edge runtime, directly read from env vars of preview props instead of writing to and reading from prerender manifest.js Previously we're trying to make these preview props values become deterministic that we can replace in edge deployment pipeline in #64521 But the way of serializing process env vars in edge runtime is not correct. They'll remain as string "process.env.xxx" in the manifest and also after consumed. This PR fixes that behavior, instead of writing it into manifest, alwyas consuming from process.env.var directly. I created a shared util to access the preview props of edge runtime across all the templates. On draft provider side, we still need to handle dev mode case when preview id is `development-id`, but we already have the cookie, it cannot be aligned with the preview id. So we do a fallback check for dev mode if the cookie is present and preview id is `development-id` then we still treat it as draft mode is enabled. Fixes #52080 Fixes #67075 Closes NEXT-3541
lubieowoce
pushed a commit
that referenced
this issue
Sep 2, 2024
Chnage the way of preview props injection to edge runtime, directly read from env vars of preview props instead of writing to and reading from prerender manifest.js Previously we're trying to make these preview props values become deterministic that we can replace in edge deployment pipeline in #64521 But the way of serializing process env vars in edge runtime is not correct. They'll remain as string "process.env.xxx" in the manifest and also after consumed. This PR fixes that behavior, instead of writing it into manifest, alwyas consuming from process.env.var directly. I created a shared util to access the preview props of edge runtime across all the templates. On draft provider side, we still need to handle dev mode case when preview id is `development-id`, but we already have the cookie, it cannot be aligned with the preview id. So we do a fallback check for dev mode if the cookie is present and preview id is `development-id` then we still treat it as draft mode is enabled. Fixes #52080 Fixes #67075 Closes NEXT-3541
lubieowoce
pushed a commit
that referenced
this issue
Sep 2, 2024
Chnage the way of preview props injection to edge runtime, directly read from env vars of preview props instead of writing to and reading from prerender manifest.js Previously we're trying to make these preview props values become deterministic that we can replace in edge deployment pipeline in #64521 But the way of serializing process env vars in edge runtime is not correct. They'll remain as string "process.env.xxx" in the manifest and also after consumed. This PR fixes that behavior, instead of writing it into manifest, alwyas consuming from process.env.var directly. I created a shared util to access the preview props of edge runtime across all the templates. On draft provider side, we still need to handle dev mode case when preview id is `development-id`, but we already have the cookie, it cannot be aligned with the preview id. So we do a fallback check for dev mode if the cookie is present and preview id is `development-id` then we still treat it as draft mode is enabled. Fixes #52080 Fixes #67075 Closes NEXT-3541
lubieowoce
pushed a commit
that referenced
this issue
Sep 2, 2024
Chnage the way of preview props injection to edge runtime, directly read from env vars of preview props instead of writing to and reading from prerender manifest.js Previously we're trying to make these preview props values become deterministic that we can replace in edge deployment pipeline in #64521 But the way of serializing process env vars in edge runtime is not correct. They'll remain as string "process.env.xxx" in the manifest and also after consumed. This PR fixes that behavior, instead of writing it into manifest, alwyas consuming from process.env.var directly. I created a shared util to access the preview props of edge runtime across all the templates. On draft provider side, we still need to handle dev mode case when preview id is `development-id`, but we already have the cookie, it cannot be aligned with the preview id. So we do a fallback check for dev mode if the cookie is present and preview id is `development-id` then we still treat it as draft mode is enabled. Fixes #52080 Fixes #67075 Closes NEXT-3541
lubieowoce
pushed a commit
that referenced
this issue
Sep 2, 2024
Chnage the way of preview props injection to edge runtime, directly read from env vars of preview props instead of writing to and reading from prerender manifest.js Previously we're trying to make these preview props values become deterministic that we can replace in edge deployment pipeline in #64521 But the way of serializing process env vars in edge runtime is not correct. They'll remain as string "process.env.xxx" in the manifest and also after consumed. This PR fixes that behavior, instead of writing it into manifest, alwyas consuming from process.env.var directly. I created a shared util to access the preview props of edge runtime across all the templates. On draft provider side, we still need to handle dev mode case when preview id is `development-id`, but we already have the cookie, it cannot be aligned with the preview id. So we do a fallback check for dev mode if the cookie is present and preview id is `development-id` then we still treat it as draft mode is enabled. Fixes #52080 Fixes #67075 Closes NEXT-3541
lubieowoce
pushed a commit
that referenced
this issue
Sep 2, 2024
Chnage the way of preview props injection to edge runtime, directly read from env vars of preview props instead of writing to and reading from prerender manifest.js Previously we're trying to make these preview props values become deterministic that we can replace in edge deployment pipeline in #64521 But the way of serializing process env vars in edge runtime is not correct. They'll remain as string "process.env.xxx" in the manifest and also after consumed. This PR fixes that behavior, instead of writing it into manifest, alwyas consuming from process.env.var directly. I created a shared util to access the preview props of edge runtime across all the templates. On draft provider side, we still need to handle dev mode case when preview id is `development-id`, but we already have the cookie, it cannot be aligned with the preview id. So we do a fallback check for dev mode if the cookie is present and preview id is `development-id` then we still treat it as draft mode is enabled. Fixes #52080 Fixes #67075 Closes NEXT-3541
lubieowoce
pushed a commit
that referenced
this issue
Sep 2, 2024
Chnage the way of preview props injection to edge runtime, directly read from env vars of preview props instead of writing to and reading from prerender manifest.js Previously we're trying to make these preview props values become deterministic that we can replace in edge deployment pipeline in #64521 But the way of serializing process env vars in edge runtime is not correct. They'll remain as string "process.env.xxx" in the manifest and also after consumed. This PR fixes that behavior, instead of writing it into manifest, alwyas consuming from process.env.var directly. I created a shared util to access the preview props of edge runtime across all the templates. On draft provider side, we still need to handle dev mode case when preview id is `development-id`, but we already have the cookie, it cannot be aligned with the preview id. So we do a fallback check for dev mode if the cookie is present and preview id is `development-id` then we still treat it as draft mode is enabled. Fixes #52080 Fixes #67075 Closes NEXT-3541
lubieowoce
pushed a commit
that referenced
this issue
Sep 2, 2024
Chnage the way of preview props injection to edge runtime, directly read from env vars of preview props instead of writing to and reading from prerender manifest.js Previously we're trying to make these preview props values become deterministic that we can replace in edge deployment pipeline in #64521 But the way of serializing process env vars in edge runtime is not correct. They'll remain as string "process.env.xxx" in the manifest and also after consumed. This PR fixes that behavior, instead of writing it into manifest, alwyas consuming from process.env.var directly. I created a shared util to access the preview props of edge runtime across all the templates. On draft provider side, we still need to handle dev mode case when preview id is `development-id`, but we already have the cookie, it cannot be aligned with the preview id. So we do a fallback check for dev mode if the cookie is present and preview id is `development-id` then we still treat it as draft mode is enabled. Fixes #52080 Fixes #67075 Closes NEXT-3541
lubieowoce
pushed a commit
that referenced
this issue
Sep 3, 2024
Chnage the way of preview props injection to edge runtime, directly read from env vars of preview props instead of writing to and reading from prerender manifest.js Previously we're trying to make these preview props values become deterministic that we can replace in edge deployment pipeline in #64521 But the way of serializing process env vars in edge runtime is not correct. They'll remain as string "process.env.xxx" in the manifest and also after consumed. This PR fixes that behavior, instead of writing it into manifest, alwyas consuming from process.env.var directly. I created a shared util to access the preview props of edge runtime across all the templates. On draft provider side, we still need to handle dev mode case when preview id is `development-id`, but we already have the cookie, it cannot be aligned with the preview id. So we do a fallback check for dev mode if the cookie is present and preview id is `development-id` then we still treat it as draft mode is enabled. Fixes #52080 Fixes #67075 Closes NEXT-3541
lubieowoce
pushed a commit
that referenced
this issue
Sep 3, 2024
Chnage the way of preview props injection to edge runtime, directly read from env vars of preview props instead of writing to and reading from prerender manifest.js Previously we're trying to make these preview props values become deterministic that we can replace in edge deployment pipeline in #64521 But the way of serializing process env vars in edge runtime is not correct. They'll remain as string "process.env.xxx" in the manifest and also after consumed. This PR fixes that behavior, instead of writing it into manifest, alwyas consuming from process.env.var directly. I created a shared util to access the preview props of edge runtime across all the templates. On draft provider side, we still need to handle dev mode case when preview id is `development-id`, but we already have the cookie, it cannot be aligned with the preview id. So we do a fallback check for dev mode if the cookie is present and preview id is `development-id` then we still treat it as draft mode is enabled. Fixes #52080 Fixes #67075 Closes NEXT-3541
lubieowoce
pushed a commit
that referenced
this issue
Sep 3, 2024
Chnage the way of preview props injection to edge runtime, directly read from env vars of preview props instead of writing to and reading from prerender manifest.js Previously we're trying to make these preview props values become deterministic that we can replace in edge deployment pipeline in #64521 But the way of serializing process env vars in edge runtime is not correct. They'll remain as string "process.env.xxx" in the manifest and also after consumed. This PR fixes that behavior, instead of writing it into manifest, alwyas consuming from process.env.var directly. I created a shared util to access the preview props of edge runtime across all the templates. On draft provider side, we still need to handle dev mode case when preview id is `development-id`, but we already have the cookie, it cannot be aligned with the preview id. So we do a fallback check for dev mode if the cookie is present and preview id is `development-id` then we still treat it as draft mode is enabled. Fixes #52080 Fixes #67075 Closes NEXT-3541
lubieowoce
pushed a commit
that referenced
this issue
Sep 3, 2024
Chnage the way of preview props injection to edge runtime, directly read from env vars of preview props instead of writing to and reading from prerender manifest.js Previously we're trying to make these preview props values become deterministic that we can replace in edge deployment pipeline in #64521 But the way of serializing process env vars in edge runtime is not correct. They'll remain as string "process.env.xxx" in the manifest and also after consumed. This PR fixes that behavior, instead of writing it into manifest, alwyas consuming from process.env.var directly. I created a shared util to access the preview props of edge runtime across all the templates. On draft provider side, we still need to handle dev mode case when preview id is `development-id`, but we already have the cookie, it cannot be aligned with the preview id. So we do a fallback check for dev mode if the cookie is present and preview id is `development-id` then we still treat it as draft mode is enabled. Fixes #52080 Fixes #67075 Closes NEXT-3541
lubieowoce
pushed a commit
that referenced
this issue
Sep 3, 2024
Chnage the way of preview props injection to edge runtime, directly read from env vars of preview props instead of writing to and reading from prerender manifest.js Previously we're trying to make these preview props values become deterministic that we can replace in edge deployment pipeline in #64521 But the way of serializing process env vars in edge runtime is not correct. They'll remain as string "process.env.xxx" in the manifest and also after consumed. This PR fixes that behavior, instead of writing it into manifest, alwyas consuming from process.env.var directly. I created a shared util to access the preview props of edge runtime across all the templates. On draft provider side, we still need to handle dev mode case when preview id is `development-id`, but we already have the cookie, it cannot be aligned with the preview id. So we do a fallback check for dev mode if the cookie is present and preview id is `development-id` then we still treat it as draft mode is enabled. Fixes #52080 Fixes #67075 Closes NEXT-3541
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Link to the code that reproduces this issue
https://github.com/JKarlavige/nextjs-draftmode-reproduction
To Reproduce
npm inpm run devlocalhost:3000/api/draft?secret=secret-token&slug=preview-pageCurrent vs. Expected behavior
Note - Draft mode on the page itself works correctly.
draftMode().isEnabledreturns true.Current behavior:
In middleware,
draftMode().isEnabledreturnsfalseafter hitting the draft endpoint in step 4 above.Expected behavior:
draftMode().isEnabledshould returntrueafter the draft endpoint has been hit.Provide environment information
Operating System: Platform: darwin Arch: arm64 Version: Darwin Kernel Version 23.5.0: Wed May 1 20:12:58 PDT 2024; root:xnu-10063.121.3~5/RELEASE_ARM64_T6000 Available memory (MB): 16384 Available CPU cores: 10 Binaries: Node: 20.11.1 npm: 10.2.4 Relevant Packages: next: 14.2.4 // Latest available version is detected (14.2.4). react: 18.3.1 react-dom: 18.3.1Which area(s) are affected? (Select all that apply)
Middleware
Which stage(s) are affected? (Select all that apply)
next dev (local), Vercel (Deployed)
Additional context
On
nextversion 14.1.4 (which we currently use in production), we experience inconsistencies where draft mode in middleware sometimes returnstrue, and on the following middleware run it returnsfalse.On version 14.2.4, it appears that draft mode always returns
false.The text was updated successfully, but these errors were encountered: