Make WordPress Core

Opened 11 years ago

Last modified 5 years ago

#23669 new enhancement

Allow front page template to fall back to home template when site displays blog posts index on front page

Reported by: chipbennett's profile chipbennett Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.5.1
Component: Themes Keywords: has-patch needs-testing close
Focuses: template Cc:

Description

The front-page.php template file is intended to define custom, static front page content. However, this template file takes precedence, regardless of whether get_option( 'show_on_front' ) is set to 'posts' or 'page'.

If the user sets the front page to display the blog posts index, this choice is effectively superseded by front-page.php, and the blog posts index is not displayed unless the Theme specifically accounts for this setting in the template file, using something like so:

 if ( 'posts' == get_option( 'show_on_front' ) ) {
     get_template_part( 'home' );
 } else {
     // front page markup goes here
 }

But requiring all Themes to include such a conditional in front-page.php essentially defeats the purpose of the the front-page.php file in the template hierarchy.

Instead, WordPress should consider get_option( 'show_on_front' ), and should return either front-page.php (for 'page') or home.php (for 'posts') on the site front page.

Attached patch modifies get_front_page_template() accordingly.

Impact to current Themes is almost certainly minimal to none, for Themes that already properly use front-page.php and home.php.

Attachments (1)

template.php.front_page_template.use.home_template.diff (890 bytes) - added by chipbennett 11 years ago.
Allow get_front_page_template() to be aware of get_option( 'show_on_front' )

Download all attachments as: .zip

Change History (20)

@chipbennett
11 years ago

Allow get_front_page_template() to be aware of get_option( 'show_on_front' )

#1 @emiluzelac
11 years ago

  • Cc emil@… added

#2 @cais
11 years ago

  • Cc edward.caissie@… added

#3 @philiparthurmoore
11 years ago

  • Cc philip@… added

#4 follow-up: @mfields
11 years ago

My understanding of front-page.php is that it should be used as the template to display content when the user visits the "root" of the WordPress installation. This is almost always accomplished by visiting the url of the website. The awesome thing about front-page.php is that it allows theme developers to always include certain elements regardless of user's settings. Such elements might be a welcome message or featured content areas.

We started using this front-page.php on WordPress.com for newer themes that include a post slider on the front page after receiving a grip of support questions asking why featured content areas were not displayed on sites even though the sliders had been configured correctly. In each case, the user had their site configured to use a static page as their front page. Using front-page.php allowed us to display the featured content in both situations.

The proposed change to template hierarchy would change the behavior of themes that are using front-page.php as described by the Codex:

front-page.php - Used for both Your latest posts or A static page as set in the Front page displays section of Settings -> Reading

I suggest close as wontfix.

#5 @mfields
11 years ago

  • Cc michael@… added

#6 in reply to: ↑ 4 ; follow-up: @chipbennett
11 years ago

Replying to mfields:

My understanding of front-page.php is that it should be used as the template to display content when the user visits the "root" of the WordPress installation. This is almost always accomplished by visiting the url of the website. The awesome thing about front-page.php is that it allows theme developers to always include certain elements regardless of user's settings. Such elements might be a welcome message or featured content areas.

We started using this front-page.php on WordPress.com for newer themes that include a post slider on the front page after receiving a grip of support questions asking why featured content areas were not displayed on sites even though the sliders had been configured correctly. In each case, the user had their site configured to use a static page as their front page. Using front-page.php allowed us to display the featured content in both situations.

That stems from Themes not properly implementing the template hierarchy, and really has no bearing on this proposed change, because for such users, nothing would change.

Further, this change would have absolutely no impact on the wordpress.com Themes that include front-page.php. The change would be completely invisible to users who have set their site front page to display a static page.

The proposed change to template hierarchy would change the behavior of themes that are using front-page.php as described by the Codex:

front-page.php - Used for both Your latest posts or A static page as set in the Front page displays section of Settings -> Reading

Yes. The intent is to change the described behavior/use of front-page.php.

The problem is that developers - logically - don't account for the valid user option of displaying the blog posts index on the site front page. Typically (and almost exclusively), front-page.php is coded only to display static front page content, and does not account for the need to display the blog posts index.

Thus, what happens currently is that users can configure their site to display the blog posts index as the site front page, and the Theme would display the custom front-page.php content instead of the blog posts index.

There are two alternatives:

  1. Force developers to code front-page.php such that it behaves as described in the Codex, which would require some variation of the conditional output as shown in the ticket description
  2. Make a simple, unobtrusive change to allow the front page to fall back to the home template if the user has configured the site to display the blog posts index as the site front page.

The second option is easier for both developers and end users.

#7 @chipbennett
11 years ago

To add a bit further, in response to this argument (via Otto, who articulates the opposing argument well):

No, I agree with Michael Fields on that one. The front-page.php file
should be used as the "front page" regardless of what the user has set
to be on the front-page. If this is not desired, then the
front-page.php file should be removed entirely.

There's basically two use cases here:

  1. Theme wants to always have the front page look the same way, regardless of user choice. Solution: Use front-page.php. Done and done. User choice then only affects the content of that front-page, by choosing whether to use the blog posts or the content from a static Page.
  1. Theme wants user choice to change the look of the front page. Solution: Don't use front-page.php at all. Use home.php, which will always be used for the blog posts regardless of location, then provide a special Page Template (named something other than front-page.php) if the theme wants to provide a special look for the static-page case. The user can then choose to use that Page Template or not, as they desire. Alternatively, you could just use page.php if the pages across the site are all supposed to look special.

There's no real good reason I can think of to have front-page.php check for the blog-on-front case and load home.php instead. If that is the desired use case, then front-page.php should simply not be included at all.

Just because a Theme has an awesome static front-page template doesn't mean that the user should be forced to use it. Presumably, the rest of the Theme is just as awesome as the static front-page template. So, while some users may opt to use the Theme with a static front page, other users very well may want to use the Theme while displaying the blog posts index as the site front page.

There's simply no reason for the Theme to trump user choice here, and in this regard, the discussion very closely resembles the "WordPress-as-CMS" Themes discussion held some time ago. The logical conclusion of that discussion was that there was a trivial difference between supporting blog posts and not supporting blog posts (the so-called "CMS" use of WordPress), and that "WordPress as CMS" was therefore not a valid special-use/niche case. I believe the same is true for static-page-as-front-page. Just because a Theme provides the option doesn't mean that it should be able to force users into using that option.

It makes even less sense to force a Theme to use "template-front-page.php", and instruct the user to jump through an extra hoop (apply template via Page Attributes) beyond the normal static-front-page configuration steps, just to make the static front page option truly *optional*. But that's essentially what you're arguing for.

IMHO, it makes infinitely more sense for WordPress simply to fall back automatically to the home template when the user has specified to display the blog posts index on the site front page.

#8 in reply to: ↑ 6 ; follow-up: @mfields
11 years ago

Replying to chipbennett:

Further, this change would have absolutely no impact on the wordpress.com Themes that include front-page.php. The change would be completely invisible to users who have set their site front page to display a static page.

I disagree. This change would have an impact on any theme that is currently using front-page.php as defined by both behavior in core and documentation in the Codex. If such a theme is installed on a user's site and the site is set to display recent posts on the front-page, the template that displays these posts will switch from front-page.php to home.php or index.php. The proposed change makes the assumption that home|index.php has been designed to display recent posts in the same manner as front-page.php has. The possibility exists that this is not true. In the event that the theme provides a front page specific items in front-page.php these items will be removed from the user's Front Page because they are not implemented in home|index.php.

The problem is that developers - logically - don't account for the valid user option of displaying the blog posts index on the site front page. Typically (and almost exclusively), front-page.php is coded only to display static front page content, and does not account for the need to display the blog posts index.

I can see where developers could get confused by the name of the template - for sure. While the name of the template is more-than-likely the cause for this confusion but, I do not believe that it is a good argument for theme developers to use the template incorrectly.

Thus, what happens currently is that users can configure their site to display the blog posts index as the site front page, and the Theme would display the custom front-page.php content instead of the blog posts index.

I see this as a feature rather than a bug. The option in core states "Front page displays" and then provides the option to choose the latest posts or static page content. A loop can be added to front-page.php to display either the post content or the page content. I works in both contexts. If further customization is needed "content" templates can be used and toggled by is_page().

  1. Force developers to code front-page.php such that it behaves as described in the Codex, which would require some variation of the conditional output as shown in the ticket description

I think that education is the best way to go here. If a lot of developers are missing the intended use of this template, than we should find a way to bring this to their attention - maybe through tutorials, theme review guidelines, and/or codex updates.

  1. Make a simple, unobtrusive change to allow the front page to fall back to the home template if the user has configured the site to display the blog posts index as the site front page.

I think that this change to template hierarchy has the potential to be obtrusive as well as remove a very useful feature that themes can take advantage of to cut down on code duplication as well as provide a better user experience when themes are viewed in the Live Preview.

#9 @sennza
11 years ago

  • Cc bronson@… added

#10 follow-up: @philiparthurmoore
11 years ago

Typically (and almost exclusively), front-page.php is coded only to display static front page content, and does not account for the need to display the blog posts index

Do you have anything to back this up? I've always understood front-page.php to be the template used for front page display regardless of what a user has chosen on his reading settings page. For themes that take advantage of featured areas on the home page (like sliders or welcome messages), regardless of whether a static page or index of posts has been chosen for the home page, wouldn't your proposed change effectively break themes that are doing it right?

Thus, what happens currently is that users can configure their site to display the blog posts index as the site front page, and the Theme would display the custom front-page.php content instead of the blog posts index.

This seems OK and exactly the intended use of that template file, as described in the Codex, and is a design decision when done well. front-page.php can include custom design and content elements on the home page and also take into account whether a user has chosen a posts or page front page.

There are two alternatives

Both are bad, in my opinion. The first isn't practical and the second changes how themes have come to use front-page.php since it was introduced three years ago in [14276]. I'm not exactly sure why this proposed change would make sense.

#11 in reply to: ↑ 10 ; follow-up: @chipbennett
11 years ago

Replying to philiparthurmoore:

This seems OK and exactly the intended use of that template file, as described in the Codex, and is a design decision when done well. front-page.php can include custom design and content elements on the home page and also take into account whether a user has chosen a posts or page front page.

Whether to display the blog posts index or a static page on the site front page is not a design decision. It is a user configuration decision.

The design decision is the design/markup/style/functionality of the static front page template. The choice to use it or not is and should be the end user's. There is absolutely no reason that a Theme with a customized static front page template cannot be used to display the blog posts index on the front page, other than the Theme superseding that user configuration decision.

#12 in reply to: ↑ 11 ; follow-up: @philiparthurmoore
11 years ago

Replying to chipbennett:

The choice to use it or not is and should be the end user's.

Agreed, and this is why front-page.php is perfectly fine, unless I'm missing something here:

http://p-am.net/grabs/fc-wm-content.jpg

Having to split that code into multiple template files after adopting the proposed patch in this ticket feels like a step backwards.

#13 in reply to: ↑ 12 @chipbennett
11 years ago

Replying to philiparthurmoore:

Replying to chipbennett:

The choice to use it or not is and should be the end user's.

Agreed, and this is why front-page.php is perfectly fine, unless I'm missing something here:

http://p-am.net/grabs/fc-wm-content.jpg

Having to split that code into multiple template files after adopting the proposed patch in this ticket feels like a step backwards.

The problem is that this is not how developers typically have used front-page.php. The vast majority, in my experience (anecdotal, but based on Theme reviews), do not account for display of the blog posts index in front-page.php. And when pointing this out to the developer, the usual reaction is that the developer never even considered the use case to be a problem, much less how to fix it elegantly within the front-page.php template itself. (The second most-common reaction is that the developer is primarily concerned with how the front page renders in the Theme previewer, rather than supporting the end user's front-page configuration settings.)

Again, the end result is that the end user has no way to display the blog posts index on the site front page, and it is that end result that concerns me.

#14 in reply to: ↑ 8 @chipbennett
11 years ago

Replying to mfields:

I disagree. This change would have an impact on any theme that is currently using front-page.php as defined by both behavior in core and documentation in the Codex. If such a theme is installed on a user's site and the site is set to display recent posts on the front-page, the template that displays these posts will switch from front-page.php to home.php or index.php. The proposed change makes the assumption that home|index.php has been designed to display recent posts in the same manner as front-page.php has. The possibility exists that this is not true. In the event that the theme provides a front page specific items in front-page.php these items will be removed from the user's Front Page because they are not implemented in home|index.php.

Are there many such Themes?

I can see where developers could get confused by the name of the template - for sure. While the name of the template is more-than-likely the cause for this confusion but, I do not believe that it is a good argument for theme developers to use the template incorrectly.

The problem is that this is not an isolated or edge-case issue. It is widespread to the point of being mainstream. We've spent the past three years getting developers to stop misusing home.php as the static front page template, but in so doing, front-page.php has proliferated primarily as a static-page-only template, with no consideration for the use case of displaying the blog posts index on the front page.

I see this as a feature rather than a bug. The option in core states "Front page displays" and then provides the option to choose the latest posts or static page content. A loop can be added to front-page.php to display either the post content or the page content. I works in both contexts. If further customization is needed "content" templates can be used and toggled by is_page().

How is it a feature when the user has configured the site to display the Blog Posts Index on the site front page, and the Theme instead displays a static page template? Merely including some variation of a "recent posts" loop does not cause the static page template to be equivalent to the blog posts index template.

I think that education is the best way to go here. If a lot of developers are missing the intended use of this template, than we should find a way to bring this to their attention - maybe through tutorials, theme review guidelines, and/or codex updates.

It is because of efforts to educate/enforce proper usage of front-page.php via Theme reviews that I have realized the need for this change. Education and Guidelines enforcement isn't working.

I think that this change to template hierarchy has the potential to be obtrusive as well as remove a very useful feature that themes can take advantage of to cut down on code duplication as well as provide a better user experience when themes are viewed in the Live Preview.

Yes, the Live Preview seems to be a sticking point for a lot of developers. Once #19627 gets approved, the Live Previewer will have a way to determine whether to display the static page template or the blog posts index on the front page.

#15 @mfields
11 years ago

Replying to chipbennett:

Are there many such Themes?

Not sure how we'd come up with a number here. One would be enough IMHO though. Front-page.php was added to core almost 3 years ago in r14276. Changing it now can put many themes in jeopardy of changing how they function. Determining a number is hard, we'd have to factor all public free and premium themes, as well as private child and custom themes. The number is probably quite large seeing that WordPress is used to power a large amount of websites.

The problem is that this is not an isolated or edge-case issue. It is widespread to the point of being mainstream. We've spent the past three years getting developers to stop misusing home.php as the static front page template, but in so doing, front-page.php has proliferated primarily as a static-page-only template, with no consideration for the use case of displaying the blog posts index on the front page.

I'm sorry to hear this, but I feel that it would be a step in the wrong direction to remove existing functionality because theme developers did not read the documentation before choosing to use a particular template. Do you have an example of such I theme? If the front-page.php file has a loop then it should display both post or page content in this loop.

Merely including some variation of a "recent posts" loop does not cause the static page template to be equivalent to the blog posts index template.

This is where I feel that front-page.php is a strong feature. It is not intended to serve as a duplicate of home|index.php rather a template specifically designed to be the landing page of the entire site. I think the option provided in Settings -> Reading exists to change the query on the front page rather than to decide which template is used to display the query.

It is because of efforts to educate/enforce proper usage of front-page.php via Theme reviews that I have realized the need for this change. Education and Guidelines enforcement isn't working.

Perhaps this would be a good "make" discussion or one for the WPTRT mailing list?

I looked though the Theme Review Guidelines and I did not see front-page.php mentioned. It sounds like incorrect use of this template would be considered a blocker though.

Yes, the Live Preview seems to be a sticking point for a lot of developers. Once #19627 gets approved, the Live Previewer will have a way to determine whether to display the static page template or the blog posts index on the front page.

Ticket #19627 is actually for an entirely different use case. Not all themes provide a custom page template to be used on the front page.

#16 @nacin
10 years ago

  • Component changed from Template to Themes
  • Focuses template added

#17 @chriscct7
8 years ago

  • Keywords close added

This seems to me like it'd be a huge breaking change for many themes that wouldn't expect this.

This ticket was mentioned in Slack in #themereview by themezee. View the logs.


8 years ago

Note: See TracTickets for help on using tickets.