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

[rudiwebworx]

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]

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

[lindseybradford]

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

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]

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

• WPGraphQL Content Blocks: Version 4.0.1
• WPGraphQL: Version 1.27.2
• Faust.js™: Version 1.3.2
• Wordpress: 6.5.5

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]

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

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]

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

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]

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.

[justlevine]

Upon review -

1. Using WP 6.6, PHP 8.2, and WPGraphQL Content Blocks 4.2.0, all of the "missing fields" mentioned in this ticket are visible:

   • CoreButtonAttributes.tagName
     
   • CoreButtonAttributes.type:
     
   • CoreHeadingAttributes.content:
     
   • CoreQuoteAttributes.citation:
     
   • CorePreformattedAttributes.content:
     
   • CoreImageAttributes.caption:
     

2. The remaining issue is that this plugin generates types optimistically instead of deterministically, as Jason mentioned, which can be worked around by aliasing. This causes type conflicts, potential changes between versions, and non-DX friendly types (e.g. using float for integer values or strings instead of enums).

Using determinate attribute types would both fix the type conflicts along with the possibility of an attribute getting removed/renamed from the block.json (which didnt happen btw).

This is being tangentially tracked in #136 (see this outdated list of type issues: #136 (comment) )