Consider 'template' and 'template_lock' support

[tw2113]

'template'
(array) Array of blocks to use as the default initial state for an editor session. Each item should be an array containing block name and optional attributes.
'template_lock'
(string|false) Whether the block template should be locked if $template is set.
If set to 'all', the user is unable to insert new blocks, move existing blocks and delete blocks.
If set to 'insert', the user is able to move existing blocks but is unable to insert new blocks and delete blocks. Default false.

https://wordpress.org/support/topic/feature-request-cpt-block-templates/

[hadamlenz]

even if on the FSE editor (themes.php?page=gutenberg-edit-site&postType=wp_template) the post type was now represented when a site author clicked "add new"

[tw2113]

template_lock looks straightforward enough to implement. Probably dropdown with "all", "insert", and "none" with none equating to false for us.

The template parameter is more complex because we need to provide an array of block names AND one to many attributes to use with each block. This part could get messy very quickly from a UI standpoint. Because of that, I may regulate that to a documentation tutorial on how to integrate with CPT arguments at a code level before we register an item.

[emilse-webdev]

I think this one will have an issue of "how will the plugin decide what template to use with each custom type?"

[tw2113]

Yes, for example with the sample borrowed from https://fullsiteediting.com/how-to-lock-blocks-and-templates/

function myplugin_register_book_post_type() {
    $args = array(
        'public' => true,
        'label'  => 'Books',
        'show_in_rest' => true,
        'template' => array(
            array( 'core/image', array(
                'align' => 'left',
            ) ),
            array( 'core/heading', array(
                'placeholder' => 'Add Author...',
            ) ),
            array( 'core/paragraph', array(
                'placeholder' => 'Add Description...',
                'lock' => array(
                    'move'   => true,
                    'remove' => true,
                 ),
            ) ),
        ),

        template_lock => 'insert';
    );
    register_post_type( 'book', $args );
}
add_action( 'init', 'myplugin_register_book_post_type' );

Finding a way to have a UI-friendly way to create this array of arrays (blocks) with their own arrays of arguments for each block. We would need to either find a way to know exactly which blocks are available, or expect the user to know how to find them, as well as figure out how to read all the available attributes for each. Then piece it all together in a way that we can save it easily. I'm not THAT worried about the saving part, because we could just make use of either some serialization or probably more preferably json_encode, though that would make our import/export really interesting.

I am more than happy to type up some documentation for the specific topic and for usage with https://github.com/WebDevStudios/custom-post-type-ui/blob/master/custom-post-type-ui.php#L538-L550 as well

What I'd be worried about most is reading/determining the available things and/or providing UI to save one-to-many possible values intended for each template parameter. While I want to be as much of a tool for everyone as we can be, this specific one still feels like it's more for power users who wouldn't need CPTUI in the first place, especially since this is very much an attribute meant for Full Site Editing, which is a lot of planning and bundling right from the start.

[emilse-webdev]

Yes, my main concern is the UI, after reading or storing the available blocks how to determine which block would be registered / shown for each custom type ? in that sense it would be safer to create a standard block for all cpts and leave open for the user to extend it, or another way would be to show available blocks and let the user choose.

[tw2113]

Ideas worth considering.

[tw2113]

I'm going to go with wontdo for this one.

We already have filters available on the arguments before we pass to register_post_type() that can be used as needed. It's also been nearly 4 years and there may be other methods developed since then to do this via WP Core UI.