[Merl-786] post_type_supports -> use_block_editor_for_post_type

[theodesp]

Description

Replaces the post_type_supports with use_block_editor_for_post_type when resolving the get_supported_post_types. This has the added benefit of running the use_block_editor_for_post_type hook that was missed, potentially including blocks that dont work with the block editor.

Tasks

• Has automated tests confirming schema accuracy on post types that support blocks and post types that do not support blocks.
• Has been tested with WPGraphQL for WooCommerce
• Has been tested with WPGraphQL for ACF (existing and new)
• Has a changeset

Closes #27

[changeset-bot]

🦋 Changeset detected

Latest commit: c5bedba

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@wpengine/wp-graphql-content-blocks	Major

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[mindctrl]

Let's get some tests that confirm the schema is correct for post types that do and do not support blocks.

[jasonbahl]

@theodesp any updates on when this might be released?

I'm trying to use WPGraphQL Content Blocks + ACF Blocks, and anytime I register a block to be available on only one specific post type, I am seeing it exposed to the Schema on all post types, which is not ideal.

[jasonbahl]

I'm trying to use WPGraphQL Content Blocks + ACF Blocks, and anytime I register a block to be available on only one specific post type, I am seeing it exposed to the Schema on all post types, which is not ideal.

Ah, I think I'm running into a different, but related issue.

If I register a a block and set it to only be exposed to a single post type, it still implements the interfaces for all post types.

For example, I've registered a block that is only available on the "Post" post type.

But it gets the following interfaces applied to it:

And it can be queried on any post type, not just the Post Post Type.

I would expect a Block registered to just one Post Type to have the Interface for that Post Type implemented. In my case, I would expect PostEditorBlock to be implemented but not EventEditorBlock, PageEditorBlock, etc.

[jasonbahl]

Update:

I think what I'm doing is a bit custom and not necessarily expected to be working.

I'm using ACF Extended which provides a way to register block types and constrain which post types the block type should be available on.

The Blocks registered with constraints are still being exposed in WPGraphQL Content Blocks to all post types via Registry->get_block_context_interfaces( $block_name )

This is because ACF Extended adds a post_types => [] configuration to each block type, but this isn't actually something supported by core Gutenberg (yet, at least as far as I can tell: WordPress/gutenberg#9855 (comment))

So, because this is added functionality of ACF Extended, there's no reasonable expectation WPGraphQL Content Blocks would have supported this.

I'll open a new issue and corresponding PR to add a filter so 3rd parties can hook in and customize some of the logic.

I'm supporting ACF Extended Fields in WPGraphQL for ACF and since I'm also working on supporting ACF Blocks + WPGraphQL Content Blocks in that codebase, I would like to filter this logic so things play nice, but I'll need a filter to exist.

[jasonbahl]

I opened an issue (#147) and PR (#148) to help with the situation I was facing. 🙏🏻

[theodesp]

Check with with WPGraphQL for WooCommerce

Created one product:

[theodesp]

Check with with [wp-graphql-acf] old and new.

Created one block:

[theodesp]

Using add_filter('use_block_editor_for_post_type', '__return_false');

the editorBlocks field is not registered

[mindctrl]

This LGTM. Would be nice to have tests that confirm the desired behavior.

[jasonbahl]

One thing to note:

This will cause breaking changes to the Schema on any site that updates.