Proposal: Remove block-templates and block-templates-parts directories for FSE - Full site editing

[overclokk]

What problem does this address?

Now we have a block-templates and block-templates-parts directories designed to integrate with the new FSE, those directories are not essential to make the FSE work, yes, I know that without a block-templates/index.html it does not display the "Site Editor" button, but the same behavior it can be obtained the same without those dirs for example using File Headers for index, single and so on like we do for custom PHP template.

And maybe we don't even need to use File Header at all because FSE knows that all html are template and could also fallback to the related php just in case html is missing.

So

What is your proposed solution?

For the main template files (index, page, single ecc) just use the root of the theme directory as we do for PHP files, and for template-parts let the developer choose the name of the directory and in the block wp:template-part slug it can be added the custom directory where the parts are.

<!-- wp:template-part { "slug":"my_parts_dir/header" } /-->

Where my_parts_dir is the directory with all block-templates-parts

The slug attribute should refer to the current theme directory so it will be easier to include the partial file.

This can solve this issue #34366
And works well with this #32939

[carlomanf]

The subdirectories are good because old themes could potentially have HTML files for other reasons and we wouldn't want them to be misread as block templates.

As you mention, the file header could achieve this in an alternate way, but it seems like a more complicated way to me. I don't see any real harm that the subdirectories do. I also don't see how the issues you linked are relevant.

[overclokk]

The subdirectories are good because old themes could potentially have HTML files for other reasons and we wouldn't want them to be misread as block templates.

So this can be simple solved with File Heading as is also done for custom template files.
Main template files like index, single, page and so on should be placed at the root level of the theme directory not inside an another subdirectory.

I don't know why in a theme there should be HTML files called index, single, page and other hierarchical names, every name used by core should never being used by developer, this is a best practice and we know how templating hierarchy works.

The subdirectories block-templates and block-templates-parts are bad because the author of the theme cannot choose the name he wants.

but it seems like a more complicated way to me.

It's as complicated as using custom templates.

I don't see any real harm that the subdirectories do.

If I need a subdir I want to call it as I want.
If wp:template-part refer to the current template I can also use subsubdir because I can add the slug with all subs names, get_template_part() works in this way.

I also don't see how the issues you linked are relevant.

The first issue is about the semantic name of the block-templates-* so, without this strict rule we solve that issue.
The second issue will work also if we accept this issue.

[annezazu]

@jffng @carolinan could you all perhaps chime in here? This was brought up in today's core editor meeting and I'd be curious to get a wider perspective.

[overclokk]

This migth be related to the following issue, in case is not I will open another one:

About wp:template-part block:

That block should be a mirror to the get_template_part() so also with removing those directories for html template and let the developer choose where to put her/him files it shoud not add any div container as it does right now, and also should not have any behavior other than propagate to child element some configuration you put on it. This is something I rised in this issue #29228 a while ago it's the same problem query-loop and others blocks have.

Whith adding all those node to the tree DOM it can become very problematic to apply styles to those blocks, simple example: you add a wide width to the parent container (in this case the wp:template-part) and a full width to the child block, what style should be applied?

Another issue is that if I want to change something in the wp:template-part config I have to update all the file where I put that snippet so it is not so good for maintainability if a theme has a lot of template.

[carolinan]

The directories work well because they create a clear separation between "classic" themes and "block themes" and they are part of a solution for a problem, namely the lack of standards for classic themes.

When you open the folder of a block theme you will immediately identify that it is a block theme just by looking at the structure.

I believe in developer freedom. This is not about forcing anyone to use folder names they do not like.
But after reviewing thousands of themes the last 11 years, I also believe in lowering the entry barrier.
It is not about the names. It is not about the structure. But that to lower the entry barrier, a common accepted standard is needed.
In addition to that, an accepted standard is needed to make automated testing possible.

[overclokk]

The directories work well because they create a clear separation between "classic" themes and "block themes" and they are part of a solution for a problem, namely the lack of standards for classic themes.

A clear separation is made by the theme.json file, if a theme has that file is a block based theme even if the theme has also php (and|or html) template because they are needed if you want to migrate at small steps.

Finding that solution another problem was added for example now wp:template-part can't include other file other than those in those folders, a simpler solution should be a wp:template-part behave like get_template_part(), let say I want to use a view folder instead, with get_template_part() I can, and if I want to use a sub-folder? The same only with get_template_part() I can.

The lack of standards for classic themes it cannot be solved by a folder.

When you open the folder of a block theme you will immediately identify that it is a block theme just by looking at the structure.

It's the same as above, if I see the json file and|or html files I know what kind of theme it is.

This is not about forcing anyone to use folder names they do not like.

More or less it is.

But after reviewing thousands of themes the last 11 years, I also believe in lowering the entry barrier.
It is not about the names. It is not about the structure. But that to lower the entry barrier, a common accepted standard is needed.

This is not the way to lowering the entry barrier.
With a good documentation you lower the barrier.

In addition to that, an accepted standard is needed to make automated testing possible.

If a test do not pass because of those directories I think that the test is not well written at all.

[carolinan]

Documentation is necessary, not comparable to ease of use.

This is only code. It means that there are as many ways to achieve something as there are developers.
You can name your folders anything you want and create a build process that produces a theme that follows standards,
while still allowing beginners to have all the benefits from learning from a simple structure.

[overclokk]

You can name your folders anything you want and create a build process that produces a theme that follows standards,
while still allowing beginners to have all the benefits from learning from a simple structure.

I know I can and I already did for the theme.json fille with a json generator.

But the issue remains, it's not about to let the beginners learning from a simple structure, they can still learning from every structure in place, no matter what.

You can always make those directories mandatory for theme uploaded on theme directory (as a good practice and not as best practice), I'm fine with that but the issue is that you can't use wp:template-part like get_template_part() because the directories name are hardcoded and does not accept other names and|or other subdirectories.

[carolinan]

@gziolo @youknowriad @jffng
A decision needs to be made about this -at least short term, for 5.9, because this proposed core change will depend on it:
Allow block themes to be activated without index.php
(There needs to be a failproof way to identify a block theme.)

[overclokk]

I like that, and maybe the theme may have the html templates directly in the root of the theme folder (so, we don't need a block-template dir).

[tex0gen]

Not to thread hijack but it seems related, could we possibly have a filter to change or add a directory of the block-templates/block-template-parts? I did have a look through the code but couldn't find a method to do so. Perhaps then it would be down to the theme developer to choose if root theme directory is used, the default as it stands or an alternative solution altogether.

[mtias]

I linked a related proposal above. I also thought of allowing this to be filterable like other admin folders are, but it should not prevent us from establishing a baseline that works for most cases and can be enforced in the public directories.

[overclokk]

There is no need to be filterable, get_template_part() works as is without a filter, you just insert the relative path to a template you want to include an that function include it so why the behavior of wp:template-part is different?

I also add that wp:template-part adds an html wrapper outside of the template included when the get_template_part() does not, why?