Make WordPress Core

Opened 14 years ago

Closed 11 years ago

#14195 closed defect (bug) (duplicate)

$paged is not set when a Static Page is set as the Front Page

Reported by: der's profile der Owned by: wonderboymusic's profile wonderboymusic
Milestone: Priority: normal
Severity: normal Version: 3.0
Component: Query Keywords: has-patch close 2nd-opinion
Focuses: Cc:

Description

If a static page is set as the front page of your WordPress site, and you request paginated content from the page via its URL (with permalinks enabled or disabled, doesn't matter), the $paged variable is not set.

This causes custom pages (those ones displaying posts), to always go to Page 1, even if you click other pages. ( This is happening because $paged is set to null, and if it's set to null, it always goes to page 1).

Also, get_query_var('paged'), also returns null, when it should return page 2 (if you clicked on page 2 for example).

After inspecting $wp_query, I noticed that the correct paginated value is stored on

$wp_query->query['paged']

So, I have to do the following on all my themes on header.php, so the pagination doesn't break:

global $wp_query, $paged;
$paged = $wp_query->query['paged'];

This sets $paged again,with the correct value from $wp_query and fixes the bug. Since $paged is null whenever a custom page is selected as your homepage.

This fix works with permalinks enabled or disabled.

Attachments (1)

dont-unset-paged.diff (486 bytes) - added by wonderboymusic 12 years ago.

Download all attachments as: .zip

Change History (14)

#1 @nacin
14 years ago

Related/Duplicate #13840

#2 follow-up: @nacin
14 years ago

  • Component changed from General to Query
  • Keywords pagination paged removed

To further clarify, I'm not sure if or why the 'paged' query var is set within $wp_query. A single post with paginated content uses the 'page' variable, while paginated multiple posts uses 'paged'. So $page I imagine stores exactly what you want.

If that sounds right, then the only thing that we may need to investigate is why paged is still being set deep in the query and not exposed in the query var, which doesn't sound right.

#3 follow-up: @scribu
14 years ago

I think we should fix the root of the problem, i.e. not rely on the $paged global at all and use get_query_var() instead.

#4 in reply to: ↑ 3 @nacin
14 years ago

Replying to scribu:

I think we should fix the root of the problem, i.e. not rely on the $paged global at all and use get_query_var() instead.

Unless I'm missing something, the $paged global should equal get_query_var( 'paged' ), and the $page global should equal get_query_var( 'page' ). So I'm not sure that's the root of the problem.

#5 @nacin
14 years ago

  • Milestone changed from Awaiting Review to Future Release

#6 @wonderboymusic
12 years ago

  • Milestone Future Release deleted
  • Resolution set to worksforme
  • Status changed from new to closed
Last edited 12 years ago by wonderboymusic (previous) (diff)

#7 @wonderboymusic
12 years ago

  • Resolution worksforme deleted
  • Status changed from closed to reopened

#8 @SergeyBiryukov
12 years ago

  • Milestone set to Future Release

#9 @wonderboymusic
12 years ago

  • Owner set to wonderboymusic
  • Status changed from reopened to accepted

#10 @wonderboymusic
12 years ago

  • Keywords has-patch added

Patch attached - all Unit Tests pass when paged remains set, page remains set to the value of paged

#11 @wonderboymusic
11 years ago

  • Milestone changed from Future Release to 3.7

small change, still applies to trunk

#12 in reply to: ↑ 2 @duck_
11 years ago

  • Keywords close 2nd-opinion added

Replying to nacin:

A single post with paginated content uses the 'page' variable, while paginated multiple posts uses 'paged'. So $page I imagine stores exactly what you want.

Exactly. When using a static front page it is expected that the page query variable is set and paged isn't. The confusion is due to the fact that /page/XX style pretty permalinks are used for page_on_front, see #12391 for why this happened. Also #13840 and comment 10 in particular.

If that sounds right, then the only thing that we may need to investigate is why paged is still being set deep in the query and not exposed in the query var, which doesn't sound right.

The reason it is set in the $query property is due to the use of /page/XX which passes paged=XX to WP_Query. The code introduced in [13494] for #12391, and removed in the patch here, switches this to the page query variable, but doesn't modify the $query property. I don't think we should modify this because it is still the input.

#13 @duck_
11 years ago

  • Milestone 3.7 deleted
  • Resolution set to duplicate
  • Status changed from accepted to closed
Note: See TracTickets for help on using tickets.