CorePostTerms doesn't expose any way to ask for the terms

[jasonbahl]

When querying Blocks, if a block is of the CorePostTerms block type, there's no way on the block to fetch the terms.

In the Block Editor I can see the terms:

However when querying for blocks, I cannot find any field in the Schema that would allow me to fetch these terms and make use of them.

I would like to be able to query the terms as a connection.

Something to the tune of:

query WysiwygField($uri: String! = "my-uri") {
  nodeByUri(uri: $uri) {
    id
    uri
    ...on NodeWithEditorBlocks {
      editorBlocks {
        __typename
        ...on CorePostTerms {
          ## There's no way to query the terms here 🤔
          terms { ## Would be great to be able to query like this
            nodes {
              __typename
               id
               name
            }
          }
        }
      }
    }
  }
}

[theodesp]

Hey @jasonbahl is CorePostTerms a Block type or we have to create an artificial type there?

[jasonbahl]

@theodesp it's a core block.

You can use it to add terms from a connected taxonomy to the post, but you cannot query those terms as nodes in the graph from the block

[justlevine]

@jasonbahl afaik no query blocks are currently supported by this plugin. and @theodesp I'd be wary of creating an Artificial type to support it without planning for forward compatibility with the Block Bindings API that we'll hopefully start seeing the impacts of in WP 6.5 (and when completed should provide the missing pieces we need for FSE).

Without that piece, the part to overcome is setting the state for a Query's children in a performant way and without polluting the global context.

[jasonbahl]

This is maybe something that should exist in plugin / custom code territory for the moment then 🤔 🤷🏻‍♂️

Right now, the only way to get the terms from the block is by using renderedHtml, but if I want the term nodes as data so my client component can decide how the markup should be output, I cannot do that currently.

I feel like this block has limited utility as-is 🤷🏻‍♂️

But also understand any hesitation to make a decision to support something like a Block->TermNode connection

[theodesp]

@jasonbahl is there a way to use the Selector API to define an array attribute for this?

With this PR we support array types

So it works similar with CoreTable block

We could include an extension of this by adding a CorePostTerms block in this list here:

https://github.com/wpengine/wp-graphql-content-blocks/tree/main/includes/Blocks

[jasonbahl]

@theodesp not sure, haven't looked into it yet.

Just was trying to use the block and determined it was essentially useless for me at the moment so wanted to open an issue to discuss. I imagine anyone else using blocks in a headless environment might find this block difficult to use as-is. 🤷🏻‍♂️

For the moment, I'm using an ACF Block and an ACF Field on the block to solve my current need of being able to query a list of terms from a block.

[justlevine]

I imagine anyone else using blocks in a headless environment might find this block difficult to use as-is. 🤷🏻‍♂️

💯
To add for those stumbling across this ticket: none of the "dynamic"* core blocks currently serve any purpose beyond acting as a flag to load a custom Frontend component or to parse their rendered HTML (depending on the block).

• meaning core blocks that are bound to a WP reference, Gutenberg has a naming problem.

[jasonbahl]

Gutenberg has a naming problem

"the block editor" 🤣

[theodesp]

@jasonbahl do you think we can include an additional field to resolve the Post Terms similar to the CoreImage block?

https://github.com/wpengine/wp-graphql-content-blocks/blob/main/includes/Blocks/CoreImage.php#L49