To make theming more logical and extensible for CMS users, the following changes should be made to the template hierarchy:
blog.php
template should be introduced as the default page template for the blog archive (whether on the front-page or on a dedicated page). After blog.php
the template hierarchy would proceed as expected to front-page.php
and home.php
blog.php
, front-page.php
and home.php
. As the hierarchy is currently, you cannot offer homepage page templates in a child theme, if the parent theme includes a front-page.php
. This removes choice from the user for no apparent reason.A feature plugin implementing these changes currently exists at: https://gschoppe.com/wordpress/better-template-hierarchy/
These all sound like good changes to me. Well-thought out and without backwards compatibility implications (as far as I can tell).
> Custom Permalink routing and embedding non-wordpress PHP functionality could be vastly simplified by offering a new file header comment that defines templates that should run at specific custom paths.
> The last change is extreme enough to require the theme to include
add_theme_support('custom_path_templates');
infunctions.php
, to enable.Why does this require a theme support flag? I think it wouldn't do anything if the newly introduced header comments are not present:
Definitely! Anything that stops the nonsense of
home.php
being the default blog template gets my vote!Honestly, the only reason I hid the custom routing functionality behind an add_theme_support flag was that I was worried that compared to the other two changes, it was significantly more invasive to the existing template heirarchy, so I thought it was more likely to catch flak for being poorly conceived or for completely bypassing custom permalink rules, when dealing with the more stodgy members of the WP community.
I see no reason why we would need to keep that flag, if these changes were adopted, although it might be useful to keep a filter that can enable/disable the functionality at will, in case of edge-case compatibility issues.
Big FAT upvote from me!
Makes total sense, please implement ;-)
Based on @James analysis of the lack of need for a theme_support flag, I've refactored the included feature plugin to remove it.
Thumbs up from me.