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

[jasonbahl]

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

[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.

[jasonbahl]

Gutenberg has a naming problem

"the block editor" 🤣

[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.

[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.

[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