Full Site Editing: Only allow FSE blocks in wp_template CPT

[Copons]

Changes proposed in this Pull Request

• Restrict the usage of Content and Template blocks in the wp_template CPT.

Note: my first thinking was to use the allowed_block_types filter, which seems designed exactly for this purpose, but in fact falls short of our needs.
The first parameter (and return value) can be true if all blocks are allowed, false if none, or a whitelist of allowed blocks.
This means that, if we want to disallow FSE blocks from all post types except wp_template, we would need to return an array including all blocks except the FSE ones.
The filter doesn't make such list available, and as far as I know there is no way to get it in PHP.

JS-side, it's slightly easier but less elegant: once the DOM is ready, only register the blocks if the current post's type is wp_template.

Testing instructions

• Create or edit a Template post, and make sure it's possible to insert both the Content and Template blocks. Also check on the front-end, and make sure Content output a temporary placeholder message, and Template the selected post.
• Create or edit a post of any other type, and make sure the Content and Template blocks aren't available.

Part of #32618 and #32619

[matticbot]

Test live: https://calypso.live/?branch=update/fse-restrict-blocks-usage

[matticbot]

This PR does not affect the size of JS and CSS bundles shipped to the user's browser.

Generated by performance advisor bot at iscalypsofastyet.com.

[mattwiebe]

This approach is fine in the short term but will break once we move to a more universal editing model, since the wp_template template would, in the example of a homepage, be edited within the context of the page post type as that which contains the content being edited.

In lieu of better logic for showing/allowing blocks in varying contexts, we could also approach this by modifying the internal logic of the block's edit function to show warnings etc and also on the frontend to educate users on proper usage.

But I think that would be premature, this gets us moving just fine.

[Copons]

This approach is fine in the short term but will break once we move to a more universal editing model, since the wp_template template would, in the example of a homepage, be edited within the context of the page post type as that which contains the content being edited.

In lieu of better logic for showing/allowing blocks in varying contexts, we could also approach this by modifying the internal logic of the block's edit function to show warnings etc and also on the frontend to educate users on proper usage.

But I think that would be premature, this gets us moving just fine.

Good point, I didn't think about that.
I agree it would be premature: we'll have to find a custom solution anyway, but we don't have enough elements yet to figure out how to approach it.

[dmsnell]

I'm less of a fan of doing this in JavaScript even though the approach in abstract is how I'd prefer to do it - conditionally register the blocks based on if we're editing a wp_template

Doing it in JavaScript opens us up to even more data races that have already given us headaches with conditionally-registered block types.

How about conditionally queuing the script in PHP in the plugin based on whether the current page is a wp_template? Did you try that approach?

[Copons]

@dmsnell I did try that, but to be honest I haven't explored it enough, once I got stuck trying to figure out the action order.
The editor post type isn't available in init yet (unless we check $_GET, which doesn't seem a nice approach to me), and so I would have needed to move enqueues and registrations to other hooks - and then I saw the domReady example in the official docs. 🙂

I can push an alternative approach to this one, it would also solve the Core's core/template extension issue (paAmJe-fT-p2 #comment-569).

[dmsnell]

The editor post type isn't available in init yet

@Copons that sounds like a golden comment to add in the implementation here if you ask me

// Note: we _could_ have conditionally enqueued this script from the server
// but at the time that the `init` hook runs in PHP we don't know the post type
// so we can't make that choice there whether or not to load this
//
// It _may_ be possible to transition to a server-based approach and that could
// alleviate related issues with data-races affecting block registration.

[vindl]

For some reason I'm no longer able to insert this blocks to any post type (including wp_template). 🤔 It works fine on the commit before this was merged.