WordPress.org

Make WordPress Core

Opened 3 years ago

Closed 3 years ago

#16002 closed defect (bug) (fixed)

Static homepage not displaying as expected in 3.1-RC1

Reported by: donalmacarthur Owned by:
Milestone: 3.1 Priority: normal
Severity: normal Version: 3.1
Component: General Keywords: needs-patch
Focuses: Cc:

Description

I've noticed that if I set a static page as my homepage in 3.1-RC1, the page does not display as the site's front page. Instead the blog page is shown. If I revert to 3.03, the static homepage displays as expected.

I've tried this in two themes, including the copy of Twenty Ten bundled with 3.1-RC1, and the behaviour is identical in both.

There are a number of posts on the issue on the support forums here: http://wordpress.org/support/topic/static-home-page-not-showing-31

The problem seems to be related to the permalink structure used. I've been doing some experimenting and this is the behaviour I've noticed so far:

If I use the default permalink structure (or any of the preset options), the problem disappears and the static homepage works as expected.

If I set a custom permalink structure with the format /%postname%/ or /%category%/%postname%/ the problem reappears.

If I set a custom permalink structure with the format /articles/%postname%/ the problem disappears.

It seems that including a static element in the custom permalink solves the problem, whatever it is.

Attachments (4)

16002.diff (740 bytes) - added by greuben 3 years ago.
16002.1.patch (740 bytes) - added by SergeyBiryukov 3 years ago.
16002.2.patch (772 bytes) - added by SergeyBiryukov 3 years ago.
16002.2.diff (761 bytes) - added by ryan 3 years ago.

Download all attachments as: .zip

Change History (17)

comment:1 nacin3 years ago

  • Milestone changed from Awaiting Review to 3.1

greuben3 years ago

SergeyBiryukov3 years ago

comment:2 greuben3 years ago

  • Keywords has-patch added; static homepage removed

SergeyBiryukov3 years ago

comment:3 SergeyBiryukov3 years ago

I was able to reproduce on a clean 3.1-RC1 install by manipulating Permalinks, Reading and custom template settings. Can't do it again on the second install, though. However I've managed to debug the issue on the first one.

This condition in query.php is not satisifed:

if ( empty($_query) || !array_diff( array_keys($_query), array('preview', 'page', 'paged', 'cpage') ) ) {

$_query is Array ( [page] => [pagename] => ), array_diff() returns Array ( [1] => pagename ).

I've made two patches both of which solve the problem for me. Not sure which one is more correct (if any).

comment:4 follow-up: greuben3 years ago

@SergeyBiryukov hahaha we patched the same, but I did it first ;)

comment:5 in reply to: ↑ 4 SergeyBiryukov3 years ago

@greuben: Yep, looks like you got there faster :)

comment:6 jondavis3 years ago

Tested 16002.diff locally and it works using each configuration of permalinks plus custom /%postname% and /%postname%/

comment:7 ryan3 years ago

We need to find where the regression happened. That block of code is identical to 3.0.

comment:8 nacin3 years ago

  • Keywords needs-patch added; has-patch removed

comment:9 SergeyBiryukov3 years ago

Looks like the regression was introduced in [15770] as a fix for #10710. Without this change the behaviour is same as in 3.0.

comment:10 filosofo3 years ago

So can't we just check for empty rather than not isset? It seems less lame.

comment:11 follow-up: ryan3 years ago

It would be interesting to see what the matched_rule var in the WP class is set to. There shouldn't usually be a matched rule.

comment:12 in reply to: ↑ 11 SergeyBiryukov3 years ago

Replying to ryan:

It would be interesting to see what the matched_rule var in the WP class is set to.

It's ()(/[0-9]+)?/?$.

ryan3 years ago

comment:13 ryan3 years ago

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

(In [17162]) Ignore an empty pagename when correcting is_* for page_on_front requests. Props donalmacarthur, SergeyBiryukov, filosofo. fixes #16002

Note: See TracTickets for help on using tickets.