Preview blanks remote nodes in the schema

[stupearce]

When the page query includes remote nodes: SInce v3.3.0 #318 the schema is now good however: The preview page data only contains WP nodes, any remote nodes are empty. Tyler see #318 for the GC panel and the config etc

[TylerBarnes]

Hi @stupearce , thanks for this! What do you mean by remote nodes?

[stupearce]

if you recall from #318 we have an additional graphql source included with the page queries. Yesterday you fixed that these nodes got lost from the schema when a preview update occurred, however the data is still lost, so when a preview occurs the page retains any wp data but looses any data from our booking graph Our GC dashboard: https://www.gatsbyjs.com/dashboard/75ca2548-438c-406d-9162-1f30d1a54ada/sites/74c4ab7c-7f51-4d39-a55d-00d5d7ee91be/deploys

from gatsby config: or 'remote node'

 {
      resolve: "gatsby-source-graphql",
      options: {
        typeName: "BookingGraph",
        fieldName: "bookingGraph",
        url: `${process.env.GATSBY_GRAPH_ADDR}/graphql`,
      },
    },

[stupearce]

I should say that incremental build of the master does not surfer this issue, it only appears to be the preview trigger

[TylerBarnes]

Ahh got it! I think this might be a bug in gatsby-source-graphql 🤔 . @vladar's our expert on that plugin but he's out of office today. @vladar when you're in can you take a look at this?

@stupearce is there a chance we could have an admin account created for us on your staging site so we can reproduce the issue more easily? No worries if not but that'd be helpful :)

[vladar]

@stupearce Is it possible to reproduce this locally (i.e. using a __refresh endpoint)? Also, can you elaborate a bit on how do you know that the data is not there? What happens if you run a query in graphiql manually?

[TylerBarnes]

I was able to pull this down and verify that it's not a problem with gatsby-source-graphql. Thanks for jumping in though @vladar !

@stupearce the problem happens on the WPGraphQL side of things. If you check in the Gatsby site directory in WordPress/GraphQL/Property/node-preview-query.gql you'll find the preview query used internally. If you copy that into wp-graphiql and add the node id of a recently previewed property to the vars section, you'll see that the propertyRef field returns 0 instead of the correct property id. The problem is the asPreview api.

If you change

property(id: $id, idType: ID, asPreview: true) {

to

property(id: $id, idType: ID, asPreview: false) {

It returns the correct property id. How is the propertyRef field being added to the schema? It will need to be adjusted to work in previews. If this is fixed, previews will work for your site with gatsby-source-graphql 😄

cc @jasonbahl

[stupearce]

@vladar @TylerBarnes yes it can be reproduced locally. Prior to any preview action (immediately after develop) on the properties pages specifically(https://chc-cms.staging.gendall.io/wp/wp-admin/edit.php?post_type=property). If I check the page-data.json for a page I can see I have all the WP nodes and the booking graph data node has content BUT: After a preview the page-data.json for that page has lost the booking graph data node content: bookingGraph":{"getProperty":null}. The /__graphql playground still has the bookingGraph node (thanks to the fix last week) and it can still be queried for data and returns correctly. To me it seems like when preview rebuilds the page-data its not using the full page query, only the wordpress bit

[jasonbahl]

@stupearce as @TylerBarnes mentioned, if we can get some info on how the propertyRef field was added to the Schema, that could go a long way in resolving this.

You might need to adjust how you're resolving for preview posts. I'll need more info on how the field was added to the Schema to know what to recommend.

[stupearce]

Hi @jasonbahl @TylerBarnes Thanks for looking into this this from the functions file

add_action( 'graphql_register_types', function() {
    register_graphql_field( 'property', 'propertyRef', [
        'type' => 'String',
        'description' => __( 'propertyRef', 'wp-graphql' ),
        'resolve' => function( $post ) {
            $propertyRef = get_post_meta( $post->ID, 'propertyRef', true );
            return ! empty( $propertyRef ) ? $propertyRef : '0';
        }
    ] );
} );

Note The property posts are programatically created/ updated by a php script on a manual update action, which reads from a remote api.

[jasonbahl]

@stupearce are you using Gutenberg (the WordPress block-based editor) by chance?

[stupearce]

@jasonbahl No we are using the basic editor, fyi the field is not editable. @TylerBarnes has an admin login to the WP instance so feel free to poke around its a dev site.

[TylerBarnes]

@stupearce how is that post meta added initially? I think the problem might be that your resolver will be checking for that post meta on the post revision during previews. To fix it you need to check if there's a post parent in your resolver and get the post meta from the original post instead of from the revision. What I'm seeing in GraphiQL during previews is "0" is returned which indicates get_post_meta( $post->ID, 'propertyRef', true ); is returning false.

This is psuedo code but you probably want to do something like:

add_action( 'graphql_register_types', function() {
    register_graphql_field( 'property', 'propertyRef', [
        'type' => 'String',
        'description' => __( 'propertyRef', 'wp-graphql' ),
        'resolve' => function( $post ) {
            $post_id = isset( $post->post_parent ) && $post->post_parent !== 0 ? $post->post_parent : $post->ID;

            $propertyRef = get_post_meta( $post_id, 'propertyRef', true );
            return ! empty( $propertyRef ) ? $propertyRef : '0';
        }
    ] );
} );

[stupearce]

@TylerBarnes this is added by an import script. This is totally working before we upgraded and is still working on a previous site we built that we havent yet updataed so I guess something in the WPGatsby plugin changed to break this ?

[TylerBarnes]

@stupearce this part is handled by WPGraphQL so I don't believe a WPGatsby change would break it. Did you happen to upgrade your version of WPGraphQL as well?

[stupearce]

@jasonbahl @TylerBarnes Hi guys, yes we did upgrade WPGraphql

[TylerBarnes]

@stupearce I'm 99% sure this is a WPGraphQL bug. For now if you update your resolver like above ☝️ it should fix it. Would you mind opening an issue on the WPGraphQL repo? That way you'll get notifications when it's fixed. If not, no worries, I can open one :)

[jasonbahl]

@TylerBarnes @stupearce I created an issue on the WPGraphQL Repo to track this:

https://github.com/wp-graphql/wp-graphql/issues/1615

[TylerBarnes]

Sweet, thanks @jasonbahl :D let's close this one in favour of that one

[jasonbahl]

@TylerBarnes after digging some more, I think we need to re-open this and close https://github.com/wp-graphql/wp-graphql/issues/1615

From what I can tell, data is coming out of WPGraphQL fine, but not making it to Gatsby as expected.

[jasonbahl]

Querying directly in WPGraphQL works:

But we get a "0" value in Gatsby:

This leads me to believe that somehow the data in Gatsby isn't being sourced properly.

I'll try to start investigating in the source plugin and see what I can find.

[jasonbahl]

@TylerBarnes @stupearce what a wild ride. Closing this issue (again) in favor of https://github.com/wp-graphql/wp-graphql/issues/1615. See comment here: https://github.com/wp-graphql/wp-graphql/issues/1615#issuecomment-741817101