ISR does not work in in presentation mode

[LKosters]

Version

module: 1.10.1
nuxt: 3.9.3

Nuxt configuration

routeRules: { "/**": { isr: 3600, cors: true, }, "/preview/**": { isr: false, cors: true, }, },

Additional information

An alternative idea would be to turn off the ISR feature, however this would lead to a degraded page performance.

Checklist

• I have tested with the latest Nuxt version and the issue still occurs
• I have tested with the latest module version and the issue still occurs
• I have searched the issue tracker and this issue hasn't been reported yet

Steps to reproduce

Clone nuxt sanity repo with the movie example, set ISR to 3600 (other values will also work), build it to a live environment (I use Vercel to host my live envoirment) and use that url in presentation mode from studio.

What is expected?

I can edit my file in presentation mode while ISR is turned on.

What is actually happening?

I get the following error in presentation mode:
"Unable to connect, check the browser console for more information."

Error in browser console:
"Unable to connect to visual editing. Make sure you've setup '@sanity/visual-editing' correctly"

[lwaldner]

@LKosters have you figured out a way to get presentation mode working? I have my site hosted on Vercel and I have not been able to get Sanity to connect. I get the same error messages.

I tried setting routeRules: { "/**": { isr: false, cors: true, }, "/preview/**": { isr: false, cors: true, }, }, in my nuxt config but it doesn't work on Vercel

[LKosters]

@LKosters have you figured out a way to get presentation mode working? I have my site hosted on Vercel and I have not been able to get Sanity to connect. I get the same error messages.

I tried setting routeRules: { "/**": { isr: false, cors: true, }, "/preview/**": { isr: false, cors: true, }, }, in my nuxt config but it doesn't work on Vercel

@lwaldner I cannot get it to work either, for now I just turn of ISR but I would rather have it on for performance.

[marco-land]

I can confirm this issue. The presentation mode seems to break as soon as you add any, even just a single, routeRule, not only when it is set for all routes with "/**" and not only for ISR.

As a temporary solution I deploy a preview branch without any rules and am using that URL for the presentation mode. Maybe that is a temporary fix for you, too.

[notflip]

@LKosters @marco-land I'm getting this error without any route rules, would you guys mind sharing how you set this up?

[marco-land]

@LKosters @marco-land I'm getting this error without any route rules, would you guys mind sharing how you set this up?

My preview branch looks like this

export default defineNuxtConfig({
  // ...
  ssr: true,
  sanity: {
    projectId: process.env.NUXT_SANITY_PROJECT_ID,
    dataset: process.env.NUXT_SANITY_DATASET,
    useCdn: false,
    apiVersion: process.env.NUXT_SANITY_API_VERSION || "2024-03-15",
    visualEditing: {
      studioUrl: process.env.NUXT_SANITY_STUDIO_URL || "http://localhost:3333",
      token: process.env.NUXT_SANITY_TOKEN,
      stega: true,
    },
  },
})

my main branch is like this

export default defineNuxtConfig({
  // ...
  ssr: true,
  sanity: {
    projectId: process.env.NUXT_SANITY_PROJECT_ID,
    dataset: process.env.NUXT_SANITY_DATASET,
    useCdn: false,
    apiVersion: process.env.NUXT_SANITY_API_VERSION || "2024-03-15",
  },
  nitro: {
    prerender: {
      crawlLinks: true,
    },
  },
  routeRules: {
    "/**": { prerender: true },
  },
})

my sanity.config.js

export default defineConfig({
  // ...
  plugins: [
    // ...
    presentationTool({
      previewUrl: {
        // make sure that the origin is the the `preview` branch URL
        origin: process.env.SANITY_STUDIO_PREVIEW_URL || 'http://localhost:3000',
        previewMode: {
          enable: '/preview/enable',
          disable: '/preview/disable',
        },
      },
    }),
  ]
});

I hope this helps, in this case I was using "@nuxtjs/sanity": "1.11.0"

[rdunk]

I've done some testing of this today. I'm unable to replicate any "Unable to connect to visual editing" issues when ISR is enabled, everything does work as expected for me with one major caveat:

Currently there is no cache separation for routes dependent on if they are rendered in preview or non-preview mode. As far as I'm aware this means that preview pages do get cached when using ISR, and those cached pages are potentially served/leaked to users who do not have preview mode enabled.

I'm not aware of a method to set cache keys to differentiate preview rendered pages, so for now I'd recommend @marco-land's approach until we can work this one out. Thanks for raising and for your patience.

[MBerkhout]

I tested this out. Unfortunately @marco-land's approach does not work in all cases. For instance, Vercel (one of the bigger platforms) automatically adds a password protection on the non-production branches.

I also noticed that end users have trouble understanding the different URL's and that keeping two branches with the same code base (but different configuration) is possible, but far from ideal (it requires more complex pipelines to ensure that code pushed to a main branch is also visible on the preview branch).

I think this issue has a big impact on possible integrations of Sanity with Nuxt: all possible work-arounds are not working in a real case scenario. One must make a decision between:

1. Big pagespeed decrease (no ISR)
2. Developer friendliness (two branches) / platform incompatability (no possibilities on Vercel)
3. User friendliness (No visual editing)

All in all, there is no optimal, developer friendly way to use Sanity with preview mode with Nuxt.

Would be great to get some guidance here from @rdunk (sanity) or @danielroe (nuxt), on how to get this in. I am more than OK with spending time to also help to get this working, but would be great to see/discuss what the integration method/starting point of this should be. @danielroe any suggestions?

[Janus-thg]

I tested this out. Unfortunately @marco-land's approach does not work in all cases. For instance, Vercel (one of the bigger platforms) automatically adds a password protection on the non-production branches.
2. Developer friendliness (two branches) / platform incompatability (no possibilities on Vercel)

Sanity has now added a way to circumvent the Vercel's Deployment Protection using the deployment protection bypass for automation.

How to use this new tool by Sanity, is explained here and here.

With this, I now have the Presentation Tool working on a subdomain on Vercel, that is protected by their Deployment Protection. I have also separated our ISR rules, and created a custom environment for it (although this is a Vercel Pro/Enterprise only feature), that activates Visual Editing.

Our custom environment tracks our main branch, and is therefore also always up to date

export default defineNuxtConfig({
  ...,
  $env: {
    livepreview: {
      routeRules: {
        '/': { isr: false },
        '/**': { isr: false },
        '/other-routes': { isr: false },
      },
      sanity: {
        visualEditing: {
          studioUrl: process.env.NUXT_SANITY_STUDIO_URL,
          token: process.env.NUXT_SANITY_VISUAL_EDITING_TOKEN,
          stega: true,
        },
      },
    },
  },
  routeRules: {
    '/': { isr: 60 },
    '/**': { isr: 1800 },
    '/other-routes': { isr: 3600 },
  },
  sanity: {
    projectId: process.env.NUXT_SANITY_PROJECT_ID,
    dataset: process.env.NUXT_SANITY_DATASET,
    apiVersion: process.env.NUXT_SANITY_API_VERSION || '2024-12-02',
    useCdn: true,
  },
}

To build with Visual editing disabled in production, preview and development, I used Vercel's Custom Environments to make an environment named livepreview, I then added an environment variable to Vercel named NUXT_BUILD_ENV, and set it to livepreview for the livepreview branch, and to production on the production, development and preview branches.

I updated our package.json's build command to the following, per @danielroe's suggestion below:

"build": "nuxt build --envName $NUXT_BUILD_ENV"

Now, whenever the main branch is updated, both production and livepreview builds. Livepreview includes visual editing.

Unfortunately, this does not solve it for most users, as Custom Environments on Vercel, are only available for Pro and Enterprise plans.

Let me know if you need any clarifications, as this is definitely a complex way of making it work, and should be made much simpler.

[danielroe]

This is worth documenting for Vercel users, I think.

I think the buildCommand + vercel.sh setup could be simplified by checking VERCEL_ENV in your build command, or even using a local module (~/modules/livepreview.ts) which is responsible for making the settings adjustments.

[Janus-thg]

This is worth documenting for Vercel users, I think.

I think the buildCommand + vercel.sh setup could be simplified by checking VERCEL_ENV in your build command, or even using a local module (~/modules/livepreview.ts) which is responsible for making the settings adjustments.

That makes sense, and simplifying it would definitely be optimal. I've contacted Vercel about overwriting the VERCEL_ENV variable, as their documentation doesn't include any information about it, but it didn't seem to have a negative effect. Unfortunately, it's still only for Pro/Enterprise users.

Unfortunately, I've run into another issue, after getting a co-worker to test it, and it seems like Vercel is still blocking his access through the Presentation Tool. I'm trying to figure out if it requires the user to be logged in on the domain that has the build with the presentation tool, which would kinda defeat the purpose.
I'll test it a bit more, and maybe contact Sanity about it again. It's the good old "it works fine on my machine".

[Janus-thg]

This is worth documenting for Vercel users, I think.

I think the buildCommand + vercel.sh setup could be simplified by checking VERCEL_ENV in your build command, or even using a local module (~/modules/livepreview.ts) which is responsible for making the settings adjustments.

@danielroe I have since my last comment simplified the build process with your suggestion, and it works without issues. Vercel also suggested not overwriting their VERCEL_ENV to prevent potential issues.

In regards to my previous comment, I tested it some more, and figured out that it was an internal firewall blocking the custom domain internally, causing the implementation to not work, when on our local network. The domain was whitelisted, and it now works out of the box.

Unfortunately, Custom environments are still locked behind the Pro and Enterprise plans. The only alternative to paying for Vercel, as far as I can see, is living with Visual editing being included on the development or preview environments.