-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Proposal: Remove block-templates and block-templates-parts directories for FSE - Full site editing #34550
Comments
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. |
So this can be simple solved with File Heading as is also done for custom template files. 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.
It's as complicated as using custom templates.
If I need a subdir I want to call it as I want.
The first issue is about the semantic name of the block-templates-* so, without this strict rule we solve that issue. |
@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. |
This migth be related to the following issue, in case is not I will open another one: About
|
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. |
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 The lack of standards for classic themes it cannot be solved by a folder.
It's the same as above, if I see the json file and|or html files I know what kind of theme it is.
More or less it is.
This is not the way to lowering the entry barrier.
If a test do not pass because of those directories I think that the test is not well written at all. |
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. |
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 |
@gziolo @youknowriad @jffng |
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). |
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. |
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. |
There is no need to be filterable, I also add that |
What problem does this address?
Now we have a
block-templates
andblock-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-partsThe 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
The text was updated successfully, but these errors were encountered: