wpengine / wp-graphql-content-blocks

Plugin that extends WPGraphQL to support querying (Gutenberg) Blocks as data
https://faustjs.org/docs/gutenberg/wp-graphql-content-blocks
GNU General Public License v2.0
104 stars 12 forks source link

Latest version of Wordpress 6.5.4 returns null for various core block attributes #242

Open rudiwebworx opened 3 months ago

rudiwebworx commented 3 months ago

On the latest version of wordpress 6.5.4 getting the following errors

 graphQLErrors: [
    {
      message: 'Cannot query field "tagName" on type "CoreButtonAttributes".',
      extensions: [Object],
      locations: [Array]
    },
    {
      message: 'Cannot query field "type" on type "CoreButtonAttributes". Did you mean "style"?',
      extensions: [Object],
      locations: [Array]
    },
    {
      message: 'Fields "attributes" conflict because subfields "align" conflict because they return conflicting types String and String!. Use different aliases on the fields to fetch both if this was intentional.',
      extensions: [Object],
      locations: [Array]
    },

Seems that there have been some changes to gutenberg core blocks that require the refactoring of this plugin.

theodesp commented 2 months ago

Hello @rudiwebworx are you using the latest version of this plugin? I have a similar setup but I cannot reproduce this issue.

lindseybradford commented 1 month ago

Hi 👋 — We're also running into this upon updating from WordPress 6.4.3 to WordPress 6.5.5:

Screen Shot 2024-07-09 at 2 59 16 PM Screen Shot 2024-07-09 at 2 55 32 PM

This broke all pages where these fields were queried and forced us to roll back and defer updates.

Our environment, arrows indicating the updated environment we tried that resulted in an outage: Plugin Version
Faust 1.3.0 → 1.3.2
WordPress 6.4.3 → 6.5.5
WPGraphQL 1.26.0 → 1.27.2

Essential fields like content and caption are now suddenly missing from Gutenberg queries, with no visible alternates in the IDE. I'm not sure if this an issue arising from WordPress Gutenberg's end or not.

I tried updating plugins and the system first—no-go. Then tried just updating the system—also a no-go. That's why I suspected the issue being that Gutenberg blocks have changed but that change isn't reflected in the content block plugin for GraphQL.

rudiwebworx commented 1 month ago

@theodesp yes we are using the latest with the following:

Errors: Error occurred prerendering page "/en". Read more: https://nextjs.org/docs/messages/prerender-error ApolloError: Fields "attributes" conflict because subfields "align" conflict because they return conflicting types String and String!. Use different aliases on the fields to fetch both if this was intentional. Fields "attributes" conflict because subfields "align" conflict because they return conflicting types String and String!. Use different aliases on the fields to fetch both if this was intentional.....

In GraphQL IDE query e.g

query PostBySlug {
  pages(where: {id: 2}) {
    nodes {
      editorBlocks {
        ... on CoreParagraph {
          anchor
          apiVersion
          attributes {
            content
            align
          }
        }
        ... on CoreButtons {
          anchor
          apiVersion
          attributes {
            align
            cssClassName
            className
            style
          }
        }
        ... on CoreButton {
          anchor
          apiVersion
          attributes {
            title
            type
            url
          }
        }
      }
      title
      slug
    }
  }
}

returns null several times for align... e.g

{
  "anchor": null,
  "apiVersion": 3,
  "attributes": {
    "content": "Beast Philanthropy is a 501(c)3 organization ....",
    "align": null
  }
},

Rolling back to WP 6.4.5 fixes this so assuming gutenberg has changed something which means this plugin needs some refactoring. Thanks in advance!

MKlblangenois commented 1 month ago

Hey! I run with the same issue on my side with an ACF block when I try to get attributes.align

image

BlockCtaSmall.fragments = {
    blocks: gql`
        fragment BlockCtaFragment on EditorBlock {
            ... on AcfBlockCta {
                anchor
                fields: blockCta {
                    title
                    description
                    button {
                        url
                        title
                        target
                    }
                }
            }
        }
    `,
};
Plugin Version
WordPress 6.6
WPGraphQL 1.27.0
WPGraphQL Content Blocks 4.0.1
erikhartin commented 1 month ago

Hey! I run with the same issue on my side with an ACF block when I try to get attributes.align

image

BlockCtaSmall.fragments = {
  blocks: gql`
      fragment BlockCtaFragment on EditorBlock {
          ... on AcfBlockCta {
              anchor
              fields: blockCta {
                  title
                  description
                  button {
                      url
                      title
                      target
                  }
              }
          }
      }
  `,
};

Plugin Version WordPress 6.6 WPGraphQL 1.27.0 WPGraphQL Content Blocks 4.0.1

I think this is a separate issue, that I've been meaning to file too – but it's unclear to me whether the bug is in this repo or stemming from the graphql-acf plugin.

I'd wager a guess that you are querying 'align' on all blocks, and the error is thrown only on the acf block. to fix this, you need to remove 'align' from the part that queries all blocks and add it back to each individual fragment. for acf blocks, you then need to query align as an alias, like so

  attributes {
    backgroundColor
    alignment: align
  }

finally you can rename 'alignment' back to 'align' in the endpoint that pulls the data.

not pretty but it works.

jasonbahl commented 1 month ago

I ran into this as well. I believe this is an issue related to a change in WordPress core that is getting passed downstream.

WPGraphQL Content Blocks reads the block registry and converts it into a GraphQL Schema. If a registration of a block is changed, it can lead to changes in the Schema, and I believe that is the case here.

I want to look into it further, but I do believe it's related to a WordPress core update.