Framework: Add support for dynamic templates #4659
Conversation
aduth
added
Framework
There was a problem hiding this comment.
Looks great. The flow of data (which hooks are influencing what; what the filtered data looks like) isn't immediately obvious, but I'd attribute that more to the nature of WordPress template hierarchy. The code is clear and points to the right places (@see tags).
lib/template.php
Outdated
| return $template_name; | ||
| } | ||
|
|
||
| // `$template` filter value is a absolute path, so check that template |
lib/template.php
Outdated
| // If post is explicitly assigned a dynamic template, return immediately. | ||
| if ( ! preg_match( '/\.php$/', $template_name ) ) { | ||
| return $template_name; | ||
| } |
There was a problem hiding this comment.
Worth extracting this check as a function? IMO that would be useful insofar as it codify what a dynamic template's slug looks like.
lib/template.php
Outdated
| */ | ||
| function gutenberg_map_template_slug( $template_name ) { | ||
| return preg_replace( '/\.php$/', '', $template_name ); | ||
| } |
There was a problem hiding this comment.
The map part of the name threw me off a bit. Is it a leftover of something using array_map, or is it map as in mapping a raw name to the proper one?
There was a problem hiding this comment.
It was an attempt to clarify that the function is meant to be used in the context of array_map, but I guess this isn't really a clarification that needs to be made. Maybe "get" instead of "map" ?
lib/template.php
Outdated
| } | ||
| } | ||
|
|
||
| // Remove file extension from template paths before slug lookup. |
There was a problem hiding this comment.
In the spirit of our conversation moments ago about comments (😉), how 'bout something like "Prepare template paths for slug lookup"? That would preserve the motivation/intent and remove possible implementation details from the comment.
|
Related branch try/inject-template (diff) extends the behavior here to explore how we might inject the dynamic template within the theme's own intended output. This is made tricky by the fact that Specifically, see d4b5f5e |
aduth
force-pushed
the
add/dynamic-templates
branch
from
864df38
to
d059337
Compare
|
Closing as experimental. Ideas will be split out into separate incremental steps. |
aduth
added
the
[Type] Technical Prototype
Related: #3588
Note: Experimental
This pull request seeks to explore dynamic templating, in an effort to support user-defined page layouts leveraging yet-to-be-implemented layout blocks (e.g. content, logo, menu, etc). The changes here introduce a new
wp_templatepost type. When a page is loaded, we use the template hierarchy to attempt to find a valid dynamic layout post to use in place of the default theme template file. Priority matters here, as if a theme defines apost-143.php, it should still take precedence over a user-definedindextemplate. Further, users may create templates which do not correspond to the template hierarchy at all, and which instead are associated with specific post types to be offered by the "Template" field in the editor (related: #991).Testing instructions:
Verify that creating a new Template post type with a slug corresponding to the template hierarchy is used in place of that theme template, when appropriate (no other files having precedence).
Verify that creating a new Template post type and assigning its Post Types terms makes the template available as an option (in Classic Editor, see #991) for Page Attributes > Template.
post,page)Next Steps:
wp_head,wp_footer)