Gatsby returned unsuccessful Preview status: NO_PAGE_CREATED_FOR_PREVIEWED_NODE

ardiewen commented 4 years ago

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

{JSON.stringify(data, null, 2)}

}

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 (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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

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 commented 4 years ago

@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 commented 3 years ago

@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 commented 3 years ago

Woo :D glad to hear it!

MobyDigg commented 3 years ago

@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 commented 3 years ago

@MobyDigg what's your Gatsby Cloud dashboard url?

MobyDigg commented 3 years ago

@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 commented 3 years ago

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 commented 3 years ago

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

rburgst commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

@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 commented 3 years ago

@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 commented 3 years ago

@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 commented 3 years ago

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 😜

gatsbyjs / gatsby-source-wordpress-experimental