Gatsby returned unsuccessful Preview status: NO_PAGE_CREATED_FOR_PREVIEWED_NODE

[ardiewen]

Hey @TylerBarnes , I've tried for a few days to get the Preview functionality working in a minimal reproduction environment and can't seem to get it working. I must be interpreting the documentation wrong, as it appears that others seem to have this functionality working.

When I click preview, I get the following error:

Gatsby returned unsuccessful Preview status:
NO_PAGE_CREATED_FOR_PREVIEWED_NODE

Browser Console shows:

{"data":{"wpGatsby":{"gatsbyPreviewStatus":{"pageNode":{"path":null},"statusType":"NO_PREVIEW_PATH_FOUND","remoteStatus":"NO_PAGE_CREATED_FOR_PREVIEWED_NODE","statusContext":null}}}

I've documented my minimal repro steps below, and can share access to both wp-admin and the modified gatsby-starter-default as required.

Steps to replicate

Clean Wordpress Enviro

• WP 5.5.3
• WP Gatsby 0.6.2
• WP GraphQL 1.0
• No other plugins, no CPTs, no ACF, custom permalinks on is the only other setting.
• Gatsby JS settings pointed to NGROK url and __refresh accordingly (see below)
• Revisions enabled (max 3)

Clean gatsby-starter-default

• ENABLE_GATSBY_REFRESH_ENDPOINT=true gatsby develop
• ngrok http 8000
• "gatsby-source-wordpress-experimental": "^3.1.3"
• gatsby-config.js

    {
      resolve: "gatsby-source-wordpress-experimental",
      options: {
        url: process.env.GATSBY_GRAPHQL_URL,
        verbose: true,
        develop: {
          nodeUpdateInterval: 10000,
          hardCacheMediaFiles: true,
        },
        schema: {
          perPage: 10,
        },
      },
    },

• gatsby-node.js

const pageTemplate = require.resolve("./src/templates/page.js")

exports.createPages = async ({ graphql, actions, reporter }) => {
  const {
    data: {
      allWpPage: { nodes: pages },
    },
  } = await graphql(`
    query GET_ALL_PAGES {
      allWpPage(filter: { status: { eq: "publish" } }) {
        nodes {
          id
          uri
          title
        }
      }
    }
  `)

  pages &&
    pages.map(page => {
      actions.createPage({
        path: page.uri,
        component: pageTemplate,
        context: {
          id: page.id,
        },
      })
      reporter.info(`Page created: ${page.title} at ${page.uri}`)
    })
}

• ./src/template/page.js

import React from "react"
import { graphql } from "gatsby"

export default function Page({ data }) {
  console.log(data)

  return <main>{JSON.stringify(data, null, 2)}</main>
}

export const query = graphql`
  query GET_PAGE($id: String!) {
    wpPage(id: { eq: $id }) {
      __typename
      id
      slug
      uri
      title
      isFrontPage
      content
    }
  }
`

When I hit preview, my dev server's logs report:

info  gatsby-source-wordpress  Watching for WordPress changes
success Generating image thumbnails - 4.344s - 6/6 1.38/s
⠀
You can now view gatsby-starter-default in the browser.
⠀
  http://localhost:8000/
⠀
View GraphiQL, an in-browser IDE, to explore your site's data and schema
⠀
  http://localhost:8000/___graphql
⠀
Note that the development build is not optimized.
To create a production build, use gatsby build
⠀
success Building development bundle - 9.825s
success createSchemaCustomization - 0.029s
⠀
info  gatsby-source-wordpress  Preview for page cG9zdDoy 5 was updated.
⠀
success Checking for changed pages - 0.001s
success source and transform nodes - 0.337s
success building schema - 0.788s
info Total nodes: 52, SitePage nodes: 4 (use --verbose for breakdown)
success createPages - 0.026s
success Checking for changed pages - 0.000s
success update schema - 0.027s
 gatsby-source-wordpress  Successfully sent Preview status back to WordPress post cG9zdDoy during undefined
success onPreExtractQueries - 0.180s
success extract queries from components - 0.107s

warning The GraphQL query in the non-page component "/home/ardiewen/Projects/__Testing/gatsby-starter-default/src/templates/page.js" will not be run.
Exported queries are only executed for Page components. It's possible you're
trying to create pages in your gatsby-node.js and that's failing for some
reason.

If the failing component(s) is a regular component and not intended to be a page
component, you generally want to use a <StaticQuery> (https://gatsbyjs.org/docs/static-query)
instead of exporting a page query.

If you're more experienced with GraphQL, you can also export GraphQL
fragments from components and compose the fragments in the Page component
query and pass data down into the child component — https://graphql.org/learn/queries/#fragments
success write out requires - 0.001s
success Re-building development bundle - 0.106s
success createSchemaCustomization - 0.020s

Any insights would be greatly appreciated. Thanks!

[TylerBarnes]

Hi @ardiewen , thank you for opening this issue! This is likely a bug as the new preview logic is brand new (just released last week). In order for me to debug this I'll need an admin account on your WP instance + access to the git repo of the Gatsby frontend. If I set it up myself there's a good chance I'll do things differently than you do and it might not result in the same bug.

Thanks!

[ardiewen]

Thanks @TylerBarnes, I've sent an wp-admin invite to your email

The public repo for the Gatsby side can be accessed here:
https://github.com/ardiewen/gatsby-wordpress-preview-minimal

[TylerBarnes]

Hi @ardiewen , the reason is that you're only building pages for published posts, so this is the expected behaviour. See this line https://github.com/ardiewen/gatsby-wordpress-preview-minimal/blob/main/gatsby-node.js#L18

You can remove the check for published posts there. In a production site Gatsby will only ever have access to published posts. And in preview mode you want to build pages for unpublished posts.

From checking this issue out though I do see there was a regression in the latest version of preview where it no longer acts on NO_PAGE_CREATED_FOR_PREVIEWED_NODE so I will need to restore this behaviour.

[ardiewen]

Thanks @TylerBarnes , that makes total sense, thanks! Perhaps this should be documented as part of the "migrating from other plugins" section. Happy to add a PR if you're accepting them for docs.

Were you able to get the preview working by just removing the filter for published posts?

I removed it in my minimal repro, ran gatsby clean && gatsby develop and tried again, and I'm still not getting the preview page loaded.

My local dev environment shows this…

info  gatsby-source-wordpress  Preview for page cG9zdDoy 5 was updated.
⠀
success Checking for changed pages - 0.000s
success source and transform nodes - 0.599s
success building schema - 0.728s
info Page created: Sample Page at /sample-page/
 gatsby-source-wordpress  Successfully sent Preview status back to WordPress post cG9zdDoy during onCreatePage Preview callback invocation
info Total nodes: 57, SitePage nodes: 4 (use --verbose for breakdown)
success createPages - 0.442s
success Checking for changed pages - 0.001s
success update schema - 0.039s
success onPreExtractQueries - 0.002s
success extract queries from components - 0.111s
success write out requires - 0.002s
success run page queries - 0.016s - 1/1 61.38/s
⠈ createSchemaCustomization
⠁  gatsby-source-wordpress  ingest WPGraphQL schema
⠈  gatsby-source-wordpress  diff schemas

Where it toggles back and forth between diff schemas, ingestWPGraphQL schema, and createSchemaCustomization endlessly.

On the wp-admin side, this is what it looks like for me:

I've updated the minimal reproduction public repo with the filters removed. Any thoughts?

[TylerBarnes]

@ardiewen I also updated to all the latest versions of Gatsby, WPGatsby, and the source plugin. Are you on latest when you get that result? ☝️

[ardiewen]

@TylerBarnes hooray! It works.

gatsby to 2.28.0
gatsby-source-wordpress-experimental to 3.3.1
wp gatsby to 0.6.7

Thanks so much for following up.

[TylerBarnes]

Woo :D glad to hear it!

[MobyDigg]

@TylerBarnes I have the same problem. Previews show NO_PAGE_CREATED_FOR_PREVIEWED_NODE.

Setup

• WP GraphQL 1.1.2
• WP Gatsby 0.9.2
• gatsby-source-wordpress-experimental ^7.0.3

Id is given through the context and the page appears, without the respective update, on the preview instance. There are no errors in the preview build log…

@TylerBarnes any ideas what that might be? @ardiewen updating solved the problem for you?

[TylerBarnes]

@MobyDigg what's your Gatsby Cloud dashboard url?

[MobyDigg]

@TylerBarnes thanks for the reply. The url is https://www.gatsbyjs.com/dashboard/organization/a7ef83e5-83c4-4eb7-acc4-f9dc3087b70a/ and I am talking about the page 720-protections.

[rburgst]

I see the same problem in the case where I press preview and the page does not have any uncommitted changes.

I have to modify a field for the ActionMonitor to actually start the preview process.

[MobyDigg]

@TylerBarnes @rburgst I tried to change all kinds of post types / ACF fields etc. without luck. Any ideas what this might be?

[rburgst]

sorry, unfortunately no. For me it works when I change any ACF (I usually pick the topmost one). You can turn on debugging of the preview on gatsby side and run the preview container with --verbose (see https://github.com/gatsbyjs/gatsby-source-wordpress-experimental/blob/master/docs/features/preview.md#debugging-the-build-process-of-previews). That might give you a slightly better idea of whats happening and whether the preview request actually reaches your gatsby server.
Also make sure to open the browser console in the preview window, you should also see a bit more info there.

[MobyDigg]

@rburgst thanks, I did that. I also can see now, that the changes I made appear in the log – so I guess data is transfered properly to Gatsby Cloud. In the end it even says gatsby-source-wordpress Successfully sent Preview status back to WordPress post cG9zdDo1OQ== during invokeAndCleanupLeftoverPreviewCallbacks. @TylerBarnes the console on the preview page reads NO_PREVIEW_PATH_FOUND. What does that mean?

[MobyDigg]

@TylerBarnes I found out, that once I hit "Preview Changes" on the WP backend, the preview builds on Gatsby Cloud – but the respective page disappears / turns white on the preview instance. And only that specific one. Once I hit "Update" on the backend to save the post, the page gets rebuild and I can see it again on the preview instance. So somehow the preview button triggers a rebuild, which is buggy. hmmm

Also I get

DevTools failed to load SourceMap: Could not load content for https://wp720.wpengine.com/preview-client.js.map: HTTP error: status code 404, net::ERR_HTTP_RESPONSE_CODE_FAILURE

…in the console of the preview page.

[TylerBarnes]

@MobyDigg previews use the build process so that's expected. It sounds like there's a react error happening in your template during previews. If you follow the guide here it should help identify what's going on in your template https://github.com/gatsbyjs/gatsby-source-wordpress-experimental/blob/master/docs/features/preview.md#debugging-previews-in-react. The .js.map 404 shouldn't have any effect

[MobyDigg]

@TylerBarnes @rburgst I found out what it was: A silly mistake and quite logical, but I didn't think of it first. I hope this might help others, too:

In my gatsby-node.js I queried pages/ posts dependent on the status being "published":

{
      allWpPage(filter: { status: { eq: "publish" } }) {
        edges {
          node {
            id
            title
            databaseId
            slug
            uri
            status
          }
        }
      }
}

…therefore the preview could not find the reworked, unpublished page. Simply deleting the filter, did the trick. Anyways, maybe it would be nice to include one sentence in the docs, which mentions this.

[TylerBarnes]

That one has tripped up a lot of folks! We added it to the docs very recently which is likely why you didn't see it when you were setting up previews initially. Glad to hear it's working for you and apologies this wasn't in the docs earlier. We didn't realize this would be an issue for folks until we started getting reports about it. Hopefully folks in the future will be diverted around this pain 😜