How to Review Front Page Display Settings

One of the most important functional aspects of a Theme that must be tested during Theme review is the Theme’s handling of front page display settings.

It seems that this test is either getting missed during Theme reviews, or else is being misunderstood. The misunderstanding is, unfortunately, related to Justin’s earlier post regarding front page settings and demo content. Some Theme developers are using the technique of displaying demo content when 'posts' == get_option( 'show_on_front' )`, and then using other methods, such as Theme options, to configure the front page display settings otherwise. In other instances, the front page may show custom content along with a custom query of blog posts, thinking that the custom query suffices. In other instances, the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. handling of front page display simply might not be well-understood.

(Note: the point of this post is not to point fingers, name names, or accuse anyone of doing anything intentionally wrong; rather, the focus is on ensuring that all reviewers are testing the front page display functionality consistently.)

The WordPress core handling of the front page display, and the blog posts index, and static pages can be a bit confusing. Please read this tutorial if you need additional information.

Review Requirements

In short:

  • When Settings->Reading->Front page displays is set to “Your latest posts”, the Theme must display the blog posts index
  • When Settings->Reading->Front page displays is set to “A static page”, the Theme must display a static page, and the blog posts index must be displayed on a static page.

Testing this functionality requires either studying the relevant template code, or installing the Theme, setting Settings->Reading->Front page displays to both settings, and verify what the Theme actually displays.

Environment Setup

In your test setup, you should have two static pages, one for the Front Page, and one for the blog posts index. I usually name these pages “Front Page” and “Blog”, and populate them with some dummy content. (The dummy content is important, to verify that the Theme is displaying the front page and blog posts index properly.)

Front Page Display: Latest Posts

The default state is Settings->Reading->Front Page displays = “Your latest posts”, which corresponds to 'posts' == get_option( 'show_on_front' )`.

When testing, the site front page should display the blog posts index, which should be rendered using the Home Template hierarchy, which is home.php, which falls back to index.php.

The site should render the Front Page page as a regular static page, with its dummy content displayed.  The site should render the Blog page as a regular static page, with its dummy content displayed.

Front Page Display: Static Page

Next, test the Theme with Settings->Reading->Front Page Displays to “A static page”, which corresponds to 'page' == get_option( 'show_on_front' )`. In the select dropdowns that appear, set “Front page” to “Front Page”, and set “Posts page” to “Blog”.

When testing, the site front page should display a static page. If the Theme includes front-page.php, the dummy content on the Front Page page will not be displayed; instead, the markup of front-page.php will be displayed. Otherrwise, the site front page will be rendered using the Page Template hierarchy, which is essentially page.php, which falls back to index.php. The Page Template hierarchy includes custom page templates and other complexity, so you may need to consider that as well.

The site should render the Front Page page as the site front page. The site should render the Blog page as the blog posts index, and the blog posts index display should replace the dummy content on the Blog page.

User Impact

Unfortunately, the impact to end users to fix incorrect handling of front page display settings after the fact is significant. Fixing Themes will almost always involve users having the behavior of their sites change when they update their Theme, and that is, quite simply, bad. Currently, there are some very heavily used Themes that will need to correct their handling of front page display, and thousands of users are going to be impacted.

I cannot stress enough how important it is that we get this aspect of the review correct before the Theme is approved. Many other issues can be addressed with minimal – or no – impact to users. Fixing this issue is going to cause a lot of surprise and frustration for many users.

But the Core Handling Sucks

Yes, the core handling might be less than ideal. Yes, the core workflow requires creating two “dummy” pages, changing a setting, and then changing two more settings. But unless and until core changes, Themes are required to support the core settings, and the core workflow. That is all the more reason to ensure that Themes are handling front page display properly before they are approved. If all Themes handle front page display the same way, the learning curve for the user is minimized, and the workflow is consistent from one Theme to the next.