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

[discobot]

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: Improving the WordPress Template Hierarchy | Greg Schoppe

---

Read-only archive: Issues · ClassicPress/ClassicPress · GitHub

Author: Greg Schoppe

Vote count: 21

Status: open

Tags:

• request-modify-feature

---

Comments

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

~ posted by James Nylen

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

~ posted by Tim Kaye

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.

~ posted by Greg Schoppe

Big FAT upvote from me!

~ posted by Pieter Bos

Makes total sense, please implement

~ posted by David Decker

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

~ posted by Greg Schoppe

Thumbs up from me.

~ posted by Mike Schinkel

[joyously]

@discobot

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)

No, it shouldn’t. The home.php template already does this. And index.php is used if home.php doesn’t exist.

@discobot

If a custom page template is selected by a user, it should override all other templates

I agree with this. My solution, however, is to get rid of front-page.php because the theme shouldn’t decide what is shown on the front page. There are already options for that, that the theme is “supposed” to follow but doesn’t have to. And the child theme can’t override.
I’ve seen so many themes with front-page.php files that ignore the content of the static Page chosen as the home page, just so they can put a big image or three boxes or a countdown or team lists or all these crazy things that belong in a plugin. If the user really wants that stuff, put it in the static Page and choose that template. At least when you switch themes, your home page will still have the content you stored in the Page.

@discobot

offering a new file header comment that defines templates that should run at specific custom paths

I don’t like this because that is not a theme’s job. The theme should cover all the queries that core handles. If it’s non-wordpress PHP then how would core even be invoked to load the template?
If it’s external, integration should be with a plugin, not a theme.

---

It would be a breaking change to remove front-page.php, but I think it’s a good thing to do. If at the same time you rename home.php to blog.php, I could live with that.