Opened 5 years ago

Closed 3 years ago

#6801 closed enhancement (fixed)

Should have a template file for front page

Reported by: AaronCampbell Owned by: westi
Priority: normal Milestone: 3.0
Component: Template Version:
Severity: normal Keywords: has-patch tested commit
Cc:

Description

Now that we have is_front_page() in addition to is_home(), I think we should have a template file for it. I'm suggesting that we use front-page.php falling back on home.php then index.php. I'm attaching a patch.

Attachments (10)

6801.001.diff (1.3 KB) - added by AaronCampbell 5 years ago.
6801.002.diff (1.3 KB) - added by AaronCampbell 5 years ago.
6801.003.diff (1.2 KB) - added by AaronCampbell 5 years ago.
6801.003.2.diff (1.2 KB) - added by AaronCampbell 5 years ago.
6801.005.diff (2.0 KB) - added by aaroncampbell 4 years ago.
6801.diff (2.3 KB) - added by Denis-de-Bernardy 4 years ago.
6801.006.diff (2.4 KB) - added by aaroncampbell 4 years ago.
6801-alternative-ordering.diff (2.0 KB) - added by westi 3 years ago.
My proposal
6801.2.diff (2.2 KB) - added by Denis-de-Bernardy 3 years ago.
refreshed version of westi's patch
6801.3.diff (2.4 KB) - added by Denis-de-Bernardy 3 years ago.

Download all attachments as: .zip

Change History (60)

  • Milestone changed from 2.5.1 to 2.6

I'm sorry, that should have been 2.6 from the beginning. I'm not sure how/why I set it to 2.5.1

The new diff (6801.002.diff), changes the fall-back order, actually creating a fork in order to keep backwards compatibility. If the user uses posts as the front page, it uses:
front-page.php -> home.php -> index.php

If the user uses a static page:
customTemplate -> front-page.php -> page.php -> index.php

  • Resolution set to wontfix
  • Status changed from new to closed

This change would require that a theme developer that includes a front-page.php use an if-else in that file to see if it's for posts or if it's a page. They can already do this in another page to accomplish the same basic thing.

While it would be handy in my cases, it would be less handy for others.

  • Resolution wontfix deleted
  • Status changed from closed to reopened

Trying to keep up with opinions here. It looks like it could still be useful. However, home.php is for the front page if it's posts. So, since that case is already handled, lets make this one handle just a static front page. This options does that, with the static front page going to:

CustomTemplate -> front-page.php -> page.php -> index.php

  • Milestone changed from 2.9 to 2.7
  • Milestone changed from 2.7 to 2.9

The problem with this at the moment is that if you have posts on the front_page then the home template is going to win over the front_page template.

I have a feeling that front_page might want to win over home and in effect home should be come deprecated.

not sure this is 2.7 ready yet.

needs some discussion first

Westi: I honestly prefer it your way, I was just trying to go for backwards compatibility. I don't use WordPress as blogging software, I use it as a CMS that has blogging software built in.

I use home.php to customize the front page when using WordPress as a CMS.

  • Milestone changed from 2.9 to 2.8

In my opinion, "home page" and "front page" are normally used synonymously in the context of a website. I'd sure like home.php to be the default template file for the front/home page of the site, regardless of whether that page incorporates blog posts or not.

I've posted to the forum about this in an effort to gather more opinions.

  • Milestone changed from 2.8 to Future Release

Punting due to time constraints, will be reconsidered in next release cycle.

I'd rather see a blog.php template for a blog page that is set on a static front page

  • Milestone changed from Future Release to 2.8.1
  • Keywords needs-patch added; has-patch needs-testing removed
  • Milestone changed from 2.8.1 to 2.9

enhancement

Lol...this one's bouncing around quite a bit. Did we decide how we want this to be implemented? I'd be happy to write the patch for it (and I do think 2.9 is the right place for it, I wasn't complaining).

  • Keywords dev-feedback added
  • Keywords dev-feedback removed

+1 for front page.php

comment:20 in reply to: ↑ 19   aaroncampbell4 years ago

Replying to Denis-de-Bernardy:

+1 for front page.php

As in, you'd like it to just fall back to page.php and have a theme author use is_front_page to fork that page into separate logic (if needed) to handle the front page one way and other pages another way?

Personally, I'd suggest page template (if any) then try front-page.php, then home.php, then try page.php for best compat.

comment:22 in reply to: ↑ 21   filosofo4 years ago

Replying to Denis-de-Bernardy:

Personally, I'd suggest page template (if any) then try front-page.php, then home.php, then try page.php for best compat.

That should be refined, I think:

If static front page set:
custom template > front-page.php > page.php > index.php

If not a static front page:
front-page.php > home.php > index.php

home.php should not be considered for the front page, when a static front page is set, because is_home() will be false for the front page.

mm, for backwards compat it's probably better to keep home.php in there for static front pages.

comment:24 in reply to: ↑ 23   filosofo4 years ago

Replying to Denis-de-Bernardy:

mm, for backwards compat it's probably better to keep home.php in there for static front pages.

How is that backwards-compatible? home.php currently loads only when is_home() is true, unless I'm missing something.

Doesn't it load when is_front_page() returns true? If not, you're 100% correct -- ignore my last comment. (I never use these, myself.)

template_loader.php just has:

} else if ( is_home() && $template = get_home_template() ) {

so I think it should go: Custom Template -> front-page.php -> page.php -> index.php

I'll try to update the patch (if it needs it...I haven't looked, but it's old) tomorrow.

how about using:

if ( is_front_page() && !is_home() && $template = get_front_page_template() ) {
} else if ( is_home() && $template = get_home_template() ) {
}

and then, in get_home_template(), we add a check: if is_front_page() and try front-page.php.

the case to avoid is, if it's a static front page, we want to behave like a page, but if it's a blog front page, we'd also want to catch front-page.php.

Denis: This was written before your reply:

6801.005.diff is the latest patch based off the current trunk.

I looked into is_front_page, and it returns true if show_on_front is 'posts' and is_home is true. However, that seems a little redundant unless some plugin is messing with it, because in query.php starting at line 1460 is_home is set to false if show_on_front == 'page'

The patch adds a check for is_front_page AFTER the is_home check. This means that if the blog page is the front page it checks for home.php -> custom template -> front-page.php -> page.php -> index.php. If the front page is a static page, it checks custom template -> front-page.php -> page.php -> index.php.

I think that makes sense.

seems so. thoughts on making front-page.php work for is_home() on the front page?

  • Keywords has-patch added; needs-patch removed

uploaded a patch that adds front-page.php to is_home()

couldn't reproduce the issue you seemed to describe when applying mine, too.

I added 6801.006.diff ...I think the only difference functionally is that Denis' would go front-page.php -> home.php -> index.php for a blog on the front. Mine would go home.php -> front-page.php -> index.php for the same.

comment:34 follow-up: ↓ 35   thee174 years ago

I don't agree with home.php being used for a static page.

comment:35 in reply to: ↑ 34   aaroncampbell4 years ago

Replying to thee17:

I don't agree with home.php being used for a static page.

Neither of the available patches here do that.

  • Keywords tested added

actually, there's a bit more difference.

Aaron's does:

  • static front: page template -> front-page.php -> page.php -> index.php
  • blog: home.php -> index.php

Mine does:

  • static front: page template -> front-page.php -> page.php -> index.php
  • blog front: front-page.php -> home.php -> index.php
  • blog: home.php -> index.php

comment:37 in reply to: ↑ 36   aaroncampbell4 years ago

Actually, mine does:

  • static front: page template -> front-page.php -> page.php -> index.php
  • blog front: home.php -> front-page.php -> page.php -> index.php
  • blog: home.php -> index.php

The reason mine has that functionality for blog front is because it first tried is_home and if that's true but home.php doesn't exist, it then tests is_front_page and goes through it's flow.

I meant to put this in the last message, but the differences as I see them are that mine prefers home to front-page if the front-page is a blog, and mine also travels through page.php for a blog front page. I think that last one is really the issue, and for that reason Denis' fix is probably better.

  • Keywords commit added; tested removed

let's go with 6801.diff then.

  • Owner changed from anonymous to westi
  • Status changed from reopened to reviewing

@westi -- I'm pretty certain you'll wonder about this:

front-page.php -> page template -> page.php

rather than:

page template -> front-page.php -> page.php

the reasoning is, if a user specifies a page template (e.g. a sales letter template), he means it and wants that on the front page.

  • Milestone changed from 2.9 to 3.0

Moving this to 3.0

2.9 is Feature frozen.

  • Keywords commit removed

Been thinking about this a bit while reviewing this patch and have the following counter proposal:

  • is_home() stays as is and always does home.php -> index.php
  • is_front_page() is put at a higher priority than is_home() and does:
    • For page on front: front-page.php -> _wp_page_template -> page-slug.php -> page-id.php -> page.php
    • For posts on front: front-page.php -> home.php -> index.php

This way for is_front_page() the most specific template gets used first and I think gives the most consistent behaviour for theme developers.

If they put a front-page.php in the theme it will always be used for the root of the site whatever the config.

Then depending on the type of post on the front page we follow the normal rules for that type.

New patch incoming for discussion.

Removing commit for now.

westi3 years ago

My proposal

Quickly reviewed your patch global $wp_query; looks like a leftover from copy/paste.

Needs a refresh, but I like westi's patch here. Makes a lot of sense.

refreshed version of westi's patch

refreshed version of westi's patch attached

Just thought I'd chime in and say that while it seems to me that a page template should override the front-page.php file, that's a pretty minor issue and I'm fine with Westi's patch.

  • Keywords tested commit added

6801.3.diff additionally fixes a bug in the templating engine that I ran into while testing.

works as expected -- it loads the correct template for static front pages and for blog post pages.

Rereading through my patch it looks like I added too much code :-)

Tidying up and committing now.

  • Resolution set to fixed
  • Status changed from reviewing to closed

(in [14276]) Introduce a template file for the Front Page of a site. Has priority over every other template which applies and falls back to the standard template flow for the page / list of posts.
Fixes #6801

Note: See TracTickets for help on using tickets.