Template definitions don't belong in theme.json

[scruffian]

What problem does this address?

The theme.json file should work for any theme and is meant to define the visual appearance of a site, it should not be coupled to templates in any way. We currently have keys for both customTemplates and templateParts in theme.json, but these don't belong here.

What is your proposed solution?

This information should live somewhere else, not sure where!

[carolinan]

I'm not so sure, I thought one of the goals were to move even more things to theme.json, for example the data in the style.css header?

[scruffian]

I think it depends on the things. The way I see it a theme.json file should work for any theme, so it can't be tied to templates.

[carolinan]

It will never work for any theme unless the color and font size slugs are forced and the custom option is removed.
That is a much larger discussion than template definitions.

[scruffian]

I think that's why we're having these discussions about settling on a standard naming for spacing and typography. I don't think we need to remove custom, themes just need to be aware that things in there aren't transferable to other themes.

[carolinan]

Establishing a best practices is not the same as enforcing and not allowing any custom slugs though.
There are already strong opinions voiced about enforcing the set folder names.

[carolinan]

WordPress should handle templates and parts that are listed in theme.json but does not exist in the theme without any errors.
I haven't tested that though.

[Humanify-nl]

If only there would be some way to specify the information coupled to a template (& -part) just like we do it with file headers in php (patterns).

From my point of view It makes more sense if that info is in the template file itself, instead of the overarching theme.json.

[carolinan]

That makes sense to me too. I always found it a strange missmatch that classic templates has that file header, but when we added the HTML block based templates, they didn't. And then we added the file header to the patterns instead and the inconsistencies increased.
I guess at that time:

• We did not have a use case for parsing a file header.
• Not having a file header meant there was a little bit of friction that helped us separate PHP and HTML templates, when the HTML templates were a new concept.

[jonathanbossenger]

Out of interest, can we make use of the current class template file header parsing for this? I would guess it would be a case of using that functionality when the theme loads, parsing the files in the templates and parts directories and then setting them up in the same way the theme.json parser would.