-
Notifications
You must be signed in to change notification settings - Fork 143
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
Comments
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" |
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. |
I think this one will have an issue of "how will the plugin decide what template to use with each custom type?" |
Yes, for example with the sample borrowed from https://fullsiteediting.com/how-to-lock-blocks-and-templates/
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. |
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. |
Ideas worth considering. |
https://wordpress.org/support/topic/feature-request-cpt-block-templates/
The text was updated successfully, but these errors were encountered: