Update template hierarchy with blog.php, front-page.php templates, and custom URL routes

November 29, 2018 · 05:32 ·

Greg Schoppe

Description

To make theming more logical and extensible for CMS users, the following changes should be made to the template hierarchy:

a 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
If a custom page template is selected by a user, it should override all other templates, including 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.
TENTATIVE: 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.

A feature plugin implementing these changes currently exists at: https://gschoppe.com/wordpress/better-template-hierarchy/

Voters

+15 more

Tags

Discussion

James Nylen

· November 29, 2018 · 05:43

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'); in functions.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:

Custom Path: url/path/here
Parse Subdirectories: true

Tim Kaye

· November 29, 2018 · 05:56

Definitely! Anything that stops the nonsense of home.php being the default blog template gets my vote!

Greg Schoppe

· November 29, 2018 · 06:32

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.

Pieter Bos

· November 29, 2018 · 09:11

Big FAT upvote from me!

David Decker

· November 29, 2018 · 10:30

Makes total sense, please implement ;-)

Greg Schoppe

· November 29, 2018 · 13:39

Based on @James analysis of the lack of need for a theme_support flag, I've refactored the included feature plugin to remove it.

Mike Schinkel

· December 1, 2018 · 05:15

Thumbs up from me.