Behavior of template hierarchy in Settings -> Reading when "Posts page" is set but "Front page displays" is not

[Frumph]

similar ticket #22131 closed as fixed

Setting a post page but not a front page displays (in settings -> reading), makes both the landing page and the page set to posts use the home.php template (i.e. both are is_home()), should the landing page (root page) be default to front-page.php instead (if) posts page is used?

No option set on the front page display also makes both locations the blog loop and the landing page register as is_home(), while at this point they are indeed different.

Otto on the TRT threads say it's a bug that you can set one and leave the other not set; but having it default to making the landing page is_front_page() with nothing selected would (imo) alleviate this bug - forcing the system to consider the posts page is_home() and the landing page is_front_page() regardless if a page is specifically selected

Take note I'm bad at articulating what I mean so bear with me; if you need me to further clarify.

[boluda]

I think WordPress should't accept setting a Front Page and not a Posts page or vice versa if A static page is selected on Front page displays.

Both fields should be required, to avoid the user failing to set it up completely. Specially considering that if the settings are incomplete and you will get wonky results.

By the way, Otto didn't say "It's a bug" but "You can consider this a core bug if you like". ;)

[Frumph]

The only 'wonky' results that occur is that both the posts page and the landing page consider itself is_home(); by having it auto-set to have the landing page as is_front_page() when only the posts page is set alleviates that.

[SergeyBiryukov]

Related: #16379, #23669.

[chipbennett]

Setting a post page but not a front page displays (in settings -> reading), makes both the landing page and the page set to posts use the home.php template (i.e. both are is_home()), should the landing page (root page) be default to front-page.php instead (if) posts page is used?

I see this as valid core behavior, rather than a bug. The two options get_option( 'page_on_front' ) and get_option( 'posts_page' ) have no meaning unless 'page' == get_option( 'show_on_front' ).

There are valid reasons for leaving the two page options set, but have 'show_on_front' changed between 'page' and 'posts'. The most obvious one is testing. A user (or developer) may want to alternate between having the front page display a static page and the blog posts index (e.g. to see which one is preferred).

No option set on the front page display also makes both locations the blog loop and the landing page register as is_home(), while at this point they are indeed different.

Are you sure about this?

Unless 'page' == get_option( 'show_on_front' ), the page set as get_option( 'front_page' ) will be displayed not as the site front page, but rather as a normal static page.

I believe the relevant handling is in query.php, on lines 1683-1689:

if ( $qv['page_id'] ) {
    if  ( 'page' == get_option('show_on_front') && $qv['page_id'] == get_option('page_for_posts') ) {
        $this->is_page = false;
        $this->is_home = true;
        $this->is_posts_page = true;
    }
}

In other words, unless 'page' == get_option('show_on_front'), when the Page ID is queried, is_page() is true, is_home() is false, and is_front_page() is false.

forcing the system to consider the posts page is_home() and the landing page is_front_page() regardless if a page is specifically selected

I'm not following this last part. How can there be a landing page if a page is not specifically selected (as the landing page)?

[Frumph]

if the posts page and the root document (landing page in this case) both show as is_home() that, in itself could be construed as wrong behavior.

[chipbennett]

Replying to Frumph:

if the posts page and the root document (landing page in this case) both show as is_home() that, in itself could be construed as wrong behavior.

But how do you get that to happen? How does WordPress recognize a static page as "landing page", unless get_option( 'page_on_front' ) is set?

Can you provide a list of steps to recreate the issue?

[Frumph]

Chip, I read your other request in the trac; #23669 that ticket concerns a similar interest however different by making the front-page.php a standard. You are purposely making arguments and it's not warranted.

The domain landing page is the index, the domain's root. I have stated the steps to take in the first post. Please re-read.

I will reiterate, setting of the posts page and not a front page in the settings -> reading, works, the UI allows it; it makes the posts page and the domains landing page both is_home(), if no front page is set in the settings it should default the domains landing page to is_front_page() instead.

[chipbennett]

I'm not trying to be argumentative. I'm trying to understand exactly how to recreate the issue, and what exactly the issue is.

So, start with a clean install (core-bundled Theme, no Plugins, default configuration):

• get_option( 'show_on_front' ) = 'posts' (front page displays blog posts index
• get_option( 'page_on_front' ) = NULL (Settings -> Reading -> Front Page dropdown is disabled)
• get_option( 'posts_page' ) = NULL` (Settings -> Reading -> Posts page dropdown is disabled)

That's how things are initially. So, from here, I'm trying to understand how we get to the issue you observe. Is this it?

1. Create two static pages, A and B
2. Settings -> Reading -> Front page displays = "A static page"
3. Settings -> Reading -> Front page = not set
4. Settings -> Reading -> Posts page = Static Page B

If this is it, then I understand how you get there; but it clearly an incomplete configuration. The user has indicated I want to use a static page as site front page, but has not specified what static page to use as the site front page.

setting of the posts page and not a front page in the settings -> reading, works, the UI allows it; it makes the posts page and the domains landing page both is_home() - if no front page is set in the settings it should default the domains landing page to is_front_page() instead.

And what would that accomplish? WordPress would still not know what to output on the site front page. It won't have a page ID to query for get_option( 'page_on_front' ), so it's still going to show the blog posts index.

As an alternate proposal to handle this incorrect configuration, I recommend:

• Not allowing get_option( 'posts_page' ) to be set unless get_option( 'page_on_front' ) is set
• Not allowing 'page' == get_option( 'show_on_front' ) to be set unless both get_option( 'posts_page' ) and get_option( 'page_on_front' ) are set)
• Providing an admin notice regarding the incorrect/incomplete configuration.

[chipbennett]

Replying to Frumph:

Chip, I read your other request in the trac; #23669 that ticket concerns a similar interest however different by making the front-page.php a standard.

Actually, #23669 is a completely separate issue, dealing with the way the Template Hierarchy (template loader) handles get_option( 'show_on_front' ) when fetching template files. If implemented, it would allow Theme developers to treat front-page.php as specifically a custom, static-page template for the site front page, because WordPress would automatically use get_home_template() if 'posts' == get_option( 'show_on_front' ). As it is currently, Theme developers have to build-in support in front-page.php for both 'posts' and 'page' as get_option( 'show_on_front' ). It really has nothing to do with how WordPress handles incorrect/incomplete configuration of the static front page settings.

[Frumph]

This trac ticket has been purposely convoluted by Chip Bennett, please close it.

[johnbillion]

Replying to Frumph:

This trac ticket has been purposely convoluted by Chip Bennett, please close it.

We're not in the business of closing tickets just because of a convoluted discussion.

That said, Chip's point here is valid:

If this is it, then I understand how you get there; but it clearly an incomplete configuration. The user has indicated I want to use a static page as site front page, but has not specified what static page to use as the site front page.

If you've selected "A static page" for your "Front page displays" setting but then not actually selected a page for your front page, that is an incomplete configuration. You may well see unexpected behaviour if a plugin or your theme is performing logic based on the value of the show_on_front option but there's nothing in the page_on_front option.

I've tested this particular configuration and is_front_page() is indeed set to false on the front page when you might expect it to be true.

That said, I don't think we should be attempting to correct the return value of a conditional when a site is using an incomplete configuration. The bug here really relates to the shortcomings of the UI for controlling what's shown on the front page and what's shown on the page for posts.

To that end, I'm closing this as wontfix. As Sergey pointed out, see #16379 for the UI issue.