404 page preview mode false on Netlify Nextjs

Support
, , , , ,
#1

Netlify site: https://phenomenal-puffpuff-190e7c.netlify.app/

  • Can enter preview by going to /api/edit

GitHub Link

Hi there,

I am having an issue where Netlify seems to be stripping the preview context from Nextjs’s 404 page. In my 404.jsx file I have a getStaticProps that will pass down the preview context boolean as a prop for the pages props:

export const getStaticProps = async ({ preview, previewData, params }) => {
    console.log('===== 404 GSProps', preview);
    return (
      {
        props: {
          isPreview: !!preview,
        },
      }
    );
};

Then in my 404.jsx component itself, I log the props and isPreview is always false when I navigate to the 404 page. It works fine on the home page. I can open the __handlers function and see that the GSProps are being called for the homepage, but the GSProps never get called for the 404 page.

Homepage :white_check_mark:
image

404 :x:
image

Thank you,
Andrew

#3

Hey @andrew.nguyen,

We’ve filed an escalation for the engineers to look at this as soon as possible and we’d let you know once we hear back.

#4

Hey @andrew.nguyen,

We talked with the engineers and it appears that, we treat the 404 page a little differently which is why it doesn’t show the preview mode. But, the engineers wondered why exactly is this needed? Is there a specific use-case you’re trying to target? Could you talk more about it?

#5

Hey,

Thank you for getting back. This is needed for me because in the preview mode of pages (including the 404) a user would have an extra form appear needed to be able to change the content on the 404 page.

So when a user is in preview mode on other pages, they can make an edit with that form to edit content. But when navigating to the 404 page to make message or image updates, that form disappears.

#8

Hey there, @andrew.nguyen :wave:

Thanks for sharing those extra details with us! We have sent it over to one of our developer teams and we will follow up here once we have more information.

#9

Hey @andrew.nguyen,

Sorry for the delay. The developers took a look at this today and their initial hunch is that, the problem comes from this line:

The revalidate should probably be a Number (>= 60) and not a Boolean. Could you give that a try and see how it goes?