Block template parts in subfolders are not loaded in the Full Site Editor

[Netzberufler]

Describe the bug
I have created a block-based theme recently and used subfolders in the block template parts folder:

block-template-parts
|__ content
|__ entry
|__ layout
    |__ footer.html
    |__ header.html
    |__ ...

The template parts are loaded from other block templates with this line:
<!-- wp:template-part {"slug":"layout/header","theme":"ambitious"} /-->

This works fine in the frontend, but the block template part is missing / not showing in the backend on Gutenberg > Site Editor (beta) when subfolders are used.

To reproduce
Steps to reproduce the behavior:

1. Install and activate the TwentyTwentry Blocks theme from the Theme Experiments repo.
2. Move the header.html in /block-template-parts in a subfolder named /layout
3. Change index.html in /block-templates to load header template from subfolder:
   <!-- wp:template-part {"slug":"layout/header","theme":"twentytwenty-blocks"} /-->
4. The header vanishes from the Site Editor in the backend.

Context
Gutenberg version 7.5.0

[epiqueras]

Nested files like that are not supported. Is that something we want to support? I think it makes sense for PHP template parts because you would import them based on a path. Here, that doesn't apply anymore.

[Netzberufler]

For me it is all about structure and organization of block templates within a theme, not necessarily how they are imported.

I think block-based themes will have more template files than today. Typical template functions will all be extra block templates, not live in one template-tags.php. And themes will have more custom block templates (former page templates) for specific things (about, contact, services page) and to provide starter content.

Aside from that, custom themes will still want to provide more than the standard templates, similiar to traditional themes. For example block templates for custom post types or plugins like wooCommerce.

I can see themes with dozens of block templates and don't want to dump all of them in just one flat folder.

[aristath]

Supporting nested templates would be something necessary for anything that has more than 5-6 templates - like an e-commerce site. Otherwise the templates folder is just going to end up an unmanageable folder with dozens of files...

[carolinan]

I agree that sub folders are needed to create a clear manageable file structure.
But if it is not intended to be supported, it should not be supported on the front either because it is confusing.

[noahtallen]

The header vanishes from the Site Editor in the backend.

It looks like even though this happens, it does still show up in the template part dropdown:

I think we should support this behavior. I'm not sure why the template part is loaded correctly if you select it directly, but does not work at all via the template part block itself. But that indicates to me that it might be easy enough to support.

[noahtallen]

I think there is also an issue where we remove the / from template part slugs, which we would might want to start supporting here.

[noahtallen]

Yep that was the issue! When loading from the template part block, it searches for test-dir/new-template-part instead of test-dir-new-template-part. I think this is an issue because WordPress changes formats the 'title' of the template part CPT when setting it to the slug.

[noahtallen]

Fix here: #25030

[noahtallen]

Should be working now so long as template parts in subdirectories are referenced from templates. There might still be some edge cases to fix. For example, a block template part in a subdirectory which is not referenced by a block template directly might not show up in the list of template parts to select from in the site editor.

[Netzberufler]

Thanks so much for fixing this 👍

[noahtallen]

For example, a block template part in a subdirectory which is not referenced by a block template directly might not show up in the list of template parts to select from in the site editor.

Note that we fixed this issue in #25063, so it should be all good to go!