Revise folder structure on themes made with blocks

[mtias]

We are on the cusp of establishing a new organization of theme files that can help creators orient themselves. This is a relatively minor issue, all things considered, but it can still have fundamental implications for the experience of building themes and its perceived simplicity, so we should act now in accordance.

(There is a related discussion in #34550 that also raises some good points.)

I'm suggesting:

• Rename /block- folders to their simpler and more direct /templates and /parts (or maybe /sections for the latter, though we can discuss this one at a later stage). Keep compatibility with “block-” prefixes as aliases. If there's a really strong desire to preserve /block- at least rename /block-template-parts to /block-parts.
• Consider in the future we'll likely have a /styles folder to allow different theme.json files, both as variations and as context providers (mapping to theme hierarchy).
• Allow the existence of a /patterns folder that automatically loads pattern files contained inside.
  • Avoid manual registration. Patterns should be a breeze for themes to author.
  • These patterns become available for the theme to use directly in wp:pattern.
  • Categories and metadata is managed in file header.
• Ensure themes can include and load PHP templates as expected alongside block templates when an HTML one cannot be found. This is important to allow the presence of specific dynamic templates for given routes (i.e. a specific custom post type archive, etc). This should be properly documented as a faculty of the design.

[bgardner]

Allow the existence of a /patterns folder that automatically loads pattern files contained inside.

Huge fan of this suggestion. +100

[carolinan]

I disagree with changing the existing folders for one point only and that is the existing themes and existing documentation.
The folder structure is already established.

I agree that having a pattern folder is a good idea, but then again the same problems with the naming as in #34550 will happen, and some developers will feel limited by this.

Please consider that developers have been developing these types of themes for the past year, and changing the folder structure now is too late.

[kafleg]

I totally agree with @carolinan here.

[francescamarano]

I can't comment on the technical solution, which seeing from the comments is definitely welcome.

But today, Beta 1 of WordPress 5.9 is being released and this is a Feature, which should have been proposed and merged before November 9th.
In addition, as @carolinan mentioned, developers - yes, not many - but some developers have been building block themes for a year now, and introducing this will burden them with additional work that not all of them might be able to afford (I don't want to make assumptions about other people's allocation of time).

@mtias you referenced to #34550, an issue that - to my understanding - addresses the same problem. It was opened in September. May I ask you why today we are putting this in a list of "Must Haves"?

I am trying to understand the process better and help whenever possible, by also reviewing my team time allocation. Thanks!

[mtias]

The volume of current block themes out there pales in comparison to what we'll see over the next year once it's released in core, so I think we should consider this a good time to evaluate our decisions so far if we can improve upon them without much disruption. We can retain aliases and ensure everything still works while establishing a better structure for the years to come. One of the main points of having an extended period of testing with the plugin is so we can have the space to evaluate what works, what doesn't, and what can be improved.

@francescamarano I think it's in must-haves to give visibility to the fact we need to acknowledge a decision. My sentiment on this is not super strong, but I'd like us to consider it fully. The auto-loading pattern suggestion is also not a requirement for 5.9, it's there to give context of a separate issue that is worth streamlining and considering widely.

[overclokk]

I'm suggesting to remove completely the needs to use any directory names in particular and let the theme developer to chose the one that works well for him/her, so wp:template-part can work similar to get_template_part() the only thing you can add is a deprecation notice for who still use the older structure (and the code to not break those themes), no filters needed.

Also for the other 2 points, please, do not add other folders names, there is already a way in core to find the right file for the right purpose, don't add others, otherwise we are at the starting point.

You have 2 solution, one already in core to find files and one to use theme.json to declare the files to use, pattern, alternative theme.json etc, like you do in block.json for the assets css and js.

I also want to notice that I rised an issue before #34550 about wp:template-part at 22 february #29228 under the "Presentation logic vs business logic".

[francescamarano]

The volume of current block themes out there pales in comparison to what we'll see over the next year once it's released in core

Sad but true 💔

Thanks for the clarification, I appreciate it!

[overclokk]

@mtias

I think it's in must-haves to give visibility to the fact we need to acknowledge a decision.

So, the decision was made without a discussion about it #36647

Why?

[youknowriad]

I think the required changes for this issue for 5.9 are done. Styles and patterns should be explored later post 5.9. Let me know if we want to close this for now or move it out of the must-haves.

[noisysocks]

I'll remove it from the board if the required changes for 5.9 are done. We ought to keep the issue open or open a new one if there's more work to be done.

[mtias]

@overclokk sorry missed the ping — this had enough consensus for making the name updates. The discussion about not using folders is a separate thing. The point about theme.json providing the boundary is not correct because theme.json can be used by non-block themes, and will be more usable in the future as it allows to consolidate defining palettes, controlling block supports, etc. There's a chance that template parts could support a path attribute that allows using any directory grouping if there's appetite for it.

[overclokk]

@mtias

this had enough consensus for making the name updates.

I did not see any consensus, only a decision without a discussion.

The discussion about not using folders is a separate thing.

It is not a separate thing, it is the same as using folders, I do not see any difference.

The point about theme.json providing the boundary is not correct because theme.json can be used by non-block themes, and will be more usable in the future as it allows to consolidate defining palettes, controlling block supports, etc.

Who said boundary?

I like the theme.json, but are the hardcoded things I hate most.

There's a chance that template parts could support a path attribute that allows using any directory grouping if there's appetite for it.

Why not doing it now, there is no issue about open this possibility to developers, you can have templates as the main folder for index, archive and so on (even if it is hardcoded) and wethever parts folder I want where I want, for example for my preference the folder for template-parts (now parts) should be placed inside the templates folder so I will have every view toghether.

Also in this view folder (templates) I can put patterns, variation and so on, every thing is a view should be placed here.

The same for different version of theme.json, I don't like styles as folder name and I don't like to have another folder at all, because the theme.json is a config file where you can config also styles and settings, not only styles (I'm not here to tell you what is a theme.json obviously), so for my preference I would like to place this files in a assets folder, and another dev would like to place wethever he/she wants.

[carolinan]

I believe that all suggestions in the issue description has been solved, can this be closed?