Inconsistent front page option behavior

[ElectricFeet]

Correct/expected behaviour:

If you change your settings in Settings > Reading > Front page displays as follows:

From:

A static page (select below)
-- Front page: home
-- Posts page: blog

To:

Your latest posts

then the Show_on_front setting is correctly changed to posts and the Page_on_front setting correctly gets reset to 0.

Incorrect behaviour:

If instead you change the same settings from Appearance > Customize, the Show_on_front setting is correctly changed to posts, but the Page_on_front setting is not reset and remains set to the previous setting's page ID.

Testing done:

I replicated this behaviour with several themes, including twenty fourteen, with all plugins deactivated.

Why this is a problem:

This is inconsistent and may cause errors--e.g. if a theme or plugin author checks the Page_on_front setting without also checking the Show_on_front setting. This is how I encountered it, in Polylang; plugin author had to work around it; details here: ​http://wordpress.org/support/topic/wrong-front-page-showing-in-appearance-customize-with-polylang-loaded).

Solution (indicative; I'm not an expert):

Re-use the "Settings > Reading > Front page displays" code in the "Appearance > Customize" functions.

[ElectricFeet]

Another addition: The page_for_posts setting is also not reset correctly by Appearance > Customize. It should be set to 0 when selecting a static front page.

Settings > Reading > Front page displays correctly sets it to 0, but Appearance > Customize instead leaves it set to the page ID that it was previously set to.

[ElectricFeet]

Apologies, the above should read:
(correction in bold)

Another addition: The page_for_posts setting is also not reset correctly by Appearance > Customize. It should be set to 0 when selecting "Your latest posts".

Settings > Reading > Front page displays correctly sets it to 0, but Appearance > Customize instead leaves it set to the page ID that it was previously set to.

[kwight]

page_for_posts probably shouldn't be reset when switching the Front page displays setting, so that their last setting is maintained if the user again switches back to a static page on front. I'd say we have the correct behaviour already.

Devs should just check against the show_on_front setting when trying to determine if the front page is a static page or posts.

[ElectricFeet]

Replying to kwight:

page_for_posts probably shouldn't be reset when switching the Front page displays setting, so that their last setting is maintained if the user again switches back to a static page on front. I'd say we have the correct behaviour already.

Devs should just check against the show_on_front setting when trying to determine if the front page is a static page or posts.

Thanks for picking this one up!

Personally, my vote would be to reset in both places (as Settings does now), simply because users will change this rarely, but plugins and themes will use it frequently. For users, it's a minor inconvenience not to retain the setting; while for devs, it's a major pain to discover/debug (it took me ages (as a user) to figure out what was wrong with the Polylang plugin).

But I can live with whatever is considered to be the "correct" behaviour.

However, the problem is that the Customizer does one thing, while Settings does another: for both page_on_front and page_for_posts, they behave differently. It is this inconsistency that needs to be fixed---they should behave in the same way.

[kraftbj]

Replying to kwight:

page_for_posts probably shouldn't be reset when switching the Front page displays setting, so that their last setting is maintained if the user again switches back to a static page on front. I'd say we have the correct behaviour already.

Devs should just check against the show_on_front setting when trying to determine if the front page is a static page or posts.

To echo @ElectricFeet, there needs to be parity between the two ways to set it. Via Settings->Reading, there is no way to retain the previous settings while the Customizer silently retains it.

[westonruter]

#36536 was marked as a duplicate.

[celloexpressions]

In terms of usability, the user settings should definitely be maintained when they're disabled. Especially because the user may try the front page option to see what it does, then quickly change back.

Therefore, the settings page would be updated if we want parity, not the customizer. This was likely an intentional enhancement when the feature was built in the customizer. That being said, I don't think that it's critical that these two distinct interfaces have the same behavior.

[celloexpressions]

Let's take a look at this in the context of Settings -> Reading.