Deploy preview for using-drupal ready!

Built with commit a745398

https://deploy-preview-5006--using-drupal.netlify.com

Deploy preview for gatsbygram ready!

Built with commit a745398

https://deploy-preview-5006--gatsbygram.netlify.com

I'm not against this change, but just for context - what problem does this solve?

It looks like this reverses the default ordering:
https://codex.wordpress.org/Class_Reference/WP_Query#Order_.26_Orderby_Parameters. Is this ok to merge in?

It won't break anything - only nodes will be inserted in different order and therefore also returned in different order if user didn't specify sort by field in query.

@sebastienfi Can you let us know why you want this change?

Sure!
So, the idea is to normalize the order of the created nodes. Therefore, the default order served by the source plugin. Some installation of WordPress will expose the post ordered ID DESC, some other by last modification date DESC.
That could be a problem for the GraphQL invariant schema. A lot of people using ACF Pro for its dynamic fields have chosen the "dummy post" strategy: create a dummy post immediately after post type creation - so its ID is the lowest, and expose in this dummy post all the possibilities of your schema. When Gatsby then infers the GraphQL schema, it will start with that post. The following posts, will compare to this schema deduced from the reference point (the dummy post) and not the other way around.
With this change, we normalize the order of the nodes and ensure that the nodes will always compare to the aimed schema.

Unless there is bug, order of nodes shouldn't affect resulting schema - we construct exampleValue (used to generate schema) from all nodes of same type, not just first node (maybe this jsdoc would explain it better than me - https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby/src/schema/data-tree-utils.js#L140 ).

@pieh That's true, I may be wrong, but it seems to me the schema builds by fusionning all the posts one by one to a consolidated vision of the fields, excluding each time what doesn't fit in the model at build.
Let's say you have in the REST API these 2 posts :

{
id: 1,
acf: { 
  file: {
     key: "/anything.jpg",
     bucket: "my-bucket",
     region: "us-east-2"
    }
  }
},
{
id: 2,
acf: { 
  file: false
  }
},

I give you that an REST API sending this kind of result is completely wrong. Welcome in WordPress.

If the post with ID of 1 is applied to the schema first, then querying file.key of the post with ID of 2 will send null.
The other way around, if post with ID of 2 is applied to schema first, querying file.key of the post with ID of 1 will throw a GraphQL error.
I prefer the first option, because on the second option the build fails.

In your example if we have mixed types for same field (acf.file - object / boolean) gatsby should skip this field (because it can't infer correct type) and show warning in console (warning was added recently - in [email protected]).

This is why I recommend on wordpress side to add acf filters to return null if value is empty for fields like relationship, image, etc - otherwise gatsby would skip those fields. (null is neutral for gatsby, that's why this works and boolean false doesn't)

@pieh Interesting. May you have an example of WP code to send null instead of false in such scenario?

@sebastienfi check this comment - #4461 (comment)

Is this something we could handle better in the WordPress plugin? e.g. if a field has false and Object values, show a link to @pieh's comment. Or add a config option that lets you decide how to handle this.

I guess it's tricky to get this right automatically. But maybe we can make it easier to deal with.

@m-allanson That's actually good idea - I'll give it a try. Previous idea was to replace all false values with null, but that would break stuff that has legitimate boolean values

@sebastienfi Can we close this PR?

Closing as this seems inactive. Please re-open if you'd like to pick this up again!