Gatsby preview URL / path not correct using gatsby-source-prismic-graphql

I am having problems with the preview functionality - the preview token does not resolve to the correct preview path on certain content types.

Expected Result
Clicking preview will pass the preview token and redirect to the preview path as specified in gatsby-config.js for gatsby-source-prismic-graphql in options.pages

eg. Previewing a Contact_page content type with uid=contact with will result in the preview URL http://localhost:8000/preview/contact_page/?uid=contact

Actual Result
The preview URL is http://localhost:8000/preview/content_page/?uid=contact and as such displays a blank screen (with the Prismic preview widget visible)

When I manually change the URL to the expected result ie. contact_page then my preview is visible.

Intersetingly, another page configuration with content type post is previewing correctly with the correct preview path http://localhost:8000/preview/post/?uid=my-first-post

So it seems that there is something going wrong with the preview mapping to the specified preview URLs being passed from the token.

My gatsby-source-prismic-graphql config is below:

{
  resolve: 'gatsby-source-prismic-graphql',
  options: {
    repositoryName: 'xxxxx',
    defaultLang: 'en-au',
    path: '/preview',
    previews: true,
    pages: [
      {
        type: 'Content_page',
        match: '/:uid',
        previewPath: '/preview/content_page',
        component: require.resolve('./src/templates/page.tsx')
      },
      {
        type: 'Post',
        match: '/blog/:uid',
        previewPath: '/preview/post',
        component: require.resolve('./src/templates/post.tsx')
      },
      {
        type: 'Blog_page',
        match: '/:uid',
        previewPath: '/preview/blog_page',
        component: require.resolve('./src/templates/blog.tsx')
      },
      {
        type: 'Contact_page',
        match: '/:uid',
        previewPath: '/preview/contact_page',
        component: require.resolve('./src/templates/contact.tsx')
      }
    ]
  }
}

Note that I have tried both path and previewPath from different reference documentation in the above config with no difference in results.

This is extremely frustrating as the preview functionality is a key requirement for my client, and at this stage they can not use it.

Any ideas or assistance from the community or the Prismic team would be much appreciated.

Hi Adrian,

Thank you for posting in Prismic community, I will try to debug this with you.
Are you using the link resolver? if so can you please share with us a code snippet of it.

Looking forward to your reply,
Fares

Hi Fares,

Yes I am using the linkResolver - pls see it pasted below:

export const linkResolver = (doc: Doc) => {
  switch (doc.type) {
    case 'post':
      return `/blog/${doc.uid}/`

    case 'content_page':
    case 'contact_page':
    case 'blog_page':
      return `/${doc.uid}/`

    default:
      return '/'
  }
  // Homepage route fallback
  return '/'
}

I have this registered in my gatsby-browser.js as well:

// Register link resolver
registerLinkResolver(linkResolver)

It seems the preview urls work fine for multiple custom types, but do not resolve correctly for singleton content types.

So Post and Content_page previews are working, however Blog_page and Contact_page are not working.

Any assistance is much appreciated.

Hi Adrian,

For me it seems that the issue come from the fact that you need to add the path of the contact page in the linkResolver the same as the blog page type such as:

case 'content_page':
    return `/content_page/${doc.uid}/`

Fares

Thanks Fares,

The link resolver works correctly as is - the links resolve to their relevant paths.

eg. for contact_page the correct url should be domain.com/contact

If I add the entry as you suggested, then navigating to the contact page will not resolve correctly. http://localhost:8000/contact_page/contact/ which returns a blank page.

So the problem is only when previewing, not actually when browsing. And it occurs only for singleton custom content types as already mentioned.

Any ideas?

Hi @Fares , Just bumping this thread to see if you have any possible solutions to this issue?
Thanks,
Adrian