Next.js: Preview Mode does not work with fallback false with PrismicCMS

[tafelito]

Bug report

Describe the bug

When using SSG with fallback false, If I create a new document in PrismicCMS and try to preview it, it won't find the document and throw a 404

I'm not sure if this is by design or not. In the docs it says that having the preview cookie it will make the getStaticProps run on runtime instead of build time, but the problem is that the page doesn't actual exists when a document is in draft mode.

To Reproduce

Run the cms-prismic example, create a new document and try to preview it in production mode (dev mode always works)

Expected behavior

Maybe run the getStaticPath like it would when you have fallback true but only when the preview cookie is present?

[zeekrey]

I would really like to help as this is marked as good first issue.

I followed the steps documented here: Next.js Prismic example. Everything workes as described.

I could observe the following behaviour (started in production mode):

_/newPost is in Prismic 'Draft' state_

fallback = true

• Accessing the preview API with valid preview token shows the post.
• Accessing /posts/newPost shows "Loading", because it tries to run getStaticProps again. After a few seconds next shows a 404 page. Not sure why, in the logs I can see that the Prismic API returns nothing for the uid in draft state.

falback = false

• Accessing the preview API with valid preview token shows the post.
• Accessing /posts/newPost results immediately in a 404 page.

Maybe you could point out where your expectations differ from the status quo? I think it is totally understandable that content in draft mode is only available through a api wrapper with a valid preview token. But maybe I'm just not getting the issue. :)

[tafelito]

When you create a new Post, and as you said is in draft state, it makes sense that you get a 404 when you visit the live site. But if you want to preview that new Post, even if it has never been published before, you should be able to do it, even having fallback = false

So this is how I believe this should work

fallback = true nothing really changes

1. Create a new Post in Prismic. State is draft
2. Preview the post.
3. Page does not exists, but because fallback is true, getStaticProps is executed. Query Prismic API with preview token.
4. Show page in preview mode
5. Publish the post.
6. Site is rebuilt through a WH. Next time you access page is already generated

fallback = false should work pretty much the same

Right now, step 2 will always get a 404 because page does not exist and getStaticProps doesn't get executed in runtime because fallback is false.
So what I said before is that ideally, if you have a preview token in a cookie, it should treat it as if you have fallback = true

Let me know if I wasn't clear enough and I might try to explain it better

Side note: The way Prismic WH work, there is no really much of a use case of having fallback = true TBH because there is no way to identify when a new Post is created or updated at the moment so if you trigger a WH to rebuild the site after publishing, your new page or updated change will be already generated.

[zeekrey]

Ok, got it. If fallback = false, the preview cookie should still be evaluated and if this is successfull the post in draft state should be shown.

As mentioned in the official docs if fallback is false, any paths not returned by getStaticPaths will result in a 404 page. So I would say that this is not a bug and more a feature request.

But I understand your needs. Maybe this is something the next.js team should think about. To resolve the issue on your side you could run next in dev mode (or prod mode with fallback true) on a staging or dev environment and point the prismic preview mode to this domain.

[tafelito]

As mentioned in the official docs if fallback is false, any paths not returned by getStaticPaths will result in a 404 page. So I would say that this is not a bug and more a feature request.

@zeekrey I think the fallback behavior as stated in the docs does work as expected. What it doesn't work is the preview mode. And that's what I think the the bug is. Preview mode should not be tight to the fallback behavior, they should work independently of each other.

[fn-gabriel]

Is there a workaround or update on this? Running into this issue as well but with Contentful instead of Prismic on unpublished posts.

[jdtzmn]

So I looked into this a bit and I believe that the issue comes from this line in the setPreviewData function. It seems that the preview cookie is not even being set because of the sameSite flag.

I tested this locally by setting NODE_ENV to production and changing the lines in the setPreviewData function to:

serialize(COOKIE_NAME_PRERENDER_BYPASS, options.previewModeId, {
      httpOnly: true,
      sameSite: 'lax', // was process.env.NODE_ENV !== 'development' ? 'none' : 'lax'
      secure: false, // was process.env.NODE_ENV !== 'development'
      path: '/',
      ...(options.maxAge !== undefined
        ? ({ maxAge: options.maxAge } as CookieSerializeOptions)
        : undefined),
    }),

When I changed those settings above, everything seemed to work as intended.

What's interesting is that it requires both the sameSite set to "lax" and secure to false.

~I can also confirm that this is the issue when deployed– the preview cookies are just not being set correctly.~
EDIT: Preview cookies are being set correctly when deployed.

UPDATE: When I build and start it locally with the environment set to production, it works as expected with no changes. I found I was unable to reproduce the issue locally.