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.