Size Change: -373 B (0%)

Total Size: 1.36 MB

_{compressed-size-action}

Every time I see "page templates" or "custom templates" referenced I need to spend a few seconds figuring out what we mean in the context. The problem is that we have lots of things called "templates", is there any way we can make it a bit easier to understand that this refers to custom templates specifically for pages?

This is not specifically for "pages", it can work with any custom post type, it just happens that the "pages" are the default CPT where these are applied if you omit the "postType" key.

One thing I think we need to reconsider is where we declare templates and whether the template metadata could live in the template itself (as core/template attributes) or on its own separate files / calls (like block.json does). It seems a bit odd to use theme.json for this — we don't register patterns nor blocks in theme.json, and templates are the same in that regard.

This feedback should not block this PR.

My understanding is that the title key is mandatory but the postTypes is not. As a follow-up to this, does it make sense to add some validation / escaping / pre-load for this fields as we have for settings/styles? Some potential ideas:

• only save the custom templates that have a title => get_custom_templates won't list them.
• pre-load the postTypes field with page if the theme doesn't define any (this way we don't need to replicate that page logic anywhere else and can be expressed in tests).

If this makes sense, I can help with this, if that's useful.

Makes a lot of sense.

That said, as said by @mtias we might explore finding ways to define these inline in the files themselves in the future. I guess validation would still be useful but implemented differently in that case.

Created WordPress/theme-experiments#202 for updating TT1-blocks.