Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider 'template' and 'template_lock' support #842

Open
tw2113 opened this issue Feb 17, 2022 · 6 comments
Open

Consider 'template' and 'template_lock' support #842

tw2113 opened this issue Feb 17, 2022 · 6 comments

Comments

@tw2113
Copy link
Member

tw2113 commented Feb 17, 2022

'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
Copy link

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
Copy link
Member Author

tw2113 commented May 17, 2022

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
Copy link

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

@tw2113
Copy link
Member Author

tw2113 commented Jun 15, 2022

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
Copy link

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
Copy link
Member Author

tw2113 commented Jun 15, 2022

Ideas worth considering.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants