Closed priethor closed 2 years ago
There is nothing on a strictly functional level that prevents a template part from working inside a post or page content. It's more a question of protocol, and while most would agree it's a good protocol to leave template parts out of post or page content, that should be left to site administrators to decide. Would there then be a filter or similar that could bring back template parts to the post inserter if someone wanted to do so?
Thanks for chiming in! Adding a filter is an interesting approach, although I'm wondering what could be a benefit of adding template parts to posts and pages rather than using reusable blocks, as the latter can be created directly from the post editor, are meant to contain content, and belong to the post context. Template parts are created from the site editor and template editors, more geared towards defining the structure and layout of the site itself rather than the content, and are not semantically meant to be added to the posts themselves (to post templates yes).
Could you provide any use-case that would benefit from using template parts rather than reusable blocks, if you happen to have one in mind? I can't seem to come up with one myself.
To clarify, I'm not envisioning an ad-hoc filter specifically for this block, but some kind of universal system that controls the block inserter for the different contexts.
There have been many cases where it's been deemed that a given block should only appear in the inserter in certain context(s). This could be within another block (e.g. Column only inside Columns), or it could be only in certain editors, or it could be only in certain post types, or it could be only for certain user capabilities, or it could be the negation/conjunction/disjunction of any of the above.
In this case, I assume you're talking about restricting this block to only be available for a particular post type (i.e. wp_template) but it's the same kind of idea as Column only being available inside Columns, for instance.
However, it seems that there has not been a consistent approach to the implementing restrictions like these. In some cases, it's been done by de-registering the entire block type. In other cases, it's been done by just hiding it from the inserter but allowing the block to be added using code view.
Would it not make sense to do all of this through a centralised system, to increase consistency while also allowing site administrators to modify the configuration through a filter if they want to? It would also make it trivial to solve this issue, rather than spend days discussing the best way to implement it.
Template part block is not part of 5.8, that said, we still need a long term solution for this. I'm removing this from the 5.8 board.
Adding Needs Dev
back to this as https://github.com/WordPress/gutenberg/pull/36810 did not work out. It'd be appreciated if a dev can pick this up and explore alternative approaches to fixing this for WP 5.9. Perhaps the one mentioned by @gziolo in https://github.com/WordPress/gutenberg/pull/36810#issuecomment-979348374.
To me, a block is self-contained and don't need to understand how all the different editors work. I explored using filters to make the editor modify block supports as it needs in https://github.com/WordPress/gutenberg/pull/37065.
@adamziel: Just confirming, is #37157 the current PR folks ought to review in order to action this issue?
@noisysocks yes, for me.
Could you provide any use-case that would benefit from using template parts rather than reusable blocks, if you happen to have one in mind? I can't seem to come up with one myself.
@priethor One potentially interesting use case: the Block Pattern Directory.
If I want to create Block Patterns that can be easily dropped onto page.html, single.html, etc, right now I cannot because I can't use the the template part block.
Hi @johnstonphilip , thanks for the feedback.
Let me see if I understand the scenario. Would you like to create Block Patterns in the Post Editor and submit them to the directory? If so, is there currently any blocker to create those same patterns in the Site Editor instead, where the Template Part block is indeed available and given those patterns are meant to be used in templates like single.html
, etc?
@priethor Not completely. I would like to submit block patterns to the directory using the UI provided here: https://wordpress.org/patterns/new-pattern/
Notice that it appears to be using the post editor, not the site editor, and therefore, the template part block is not available.
According to the instructions here, this is the only way to submit patterns.
Thanks for the extra context! I think this is more of a limitation in the Pattern Creator rather than an issue with the Post Editor, so I've opened an issue in the Pattern Directory repository accordingly.
I was pointed to this issue from #core-editor when I asked "why, in the Post Editor, the block inserter doesn't display template parts but I can still paste them?"
In previous comments there were questions regarding a use case for using template parts versus reusable blocks.
Well, one answer is:
I used template parts in Dec 2020 to demonstrate my prototype for internationalizing and localizing a block based theme. See https://github.com/WordPress/gutenberg/issues/27402 or https://herbmiller.me/localization-of-full-site-editing-themes/
I don't particularly want to revert the change that was implemented for this issue but would like to point out that in the current implementation.
<!-- wp:template-part {"slug":"i18n-test","theme":"fizzie"} /-->
And I look forward to this continuing to be the case.
Description
As of 10.4-RC1, Template Part blocks can be added to the Post Editor in the same way reusable blocks can be added. However, template parts can only be created from the Site Editor.
This issue is related to #30669, which presents the opposite logic for reusable blocks. Original discussion in #30308
Step-by-step reproduction instructions
Expected behaviour
Template parts should only be available to insert in template editors.
Actual behaviour
Template parts can be inserted in posts or pages.
WordPress information