WordPress.org

Make WordPress Core

Opened 4 years ago

Closed 8 months ago

#14195 closed defect (bug) (duplicate)

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

Reported by: der Owned by: 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 18 months ago.

Download all attachments as: .zip

Change History (14)

comment:1 nacin4 years ago

Related/Duplicate #13840

comment:2 follow-up: nacin4 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.

comment:3 follow-up: scribu4 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.

comment:4 in reply to: ↑ 3 nacin4 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.

comment:5 nacin3 years ago

  • Milestone changed from Awaiting Review to Future Release

comment:6 wonderboymusic18 months ago

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

comment:7 wonderboymusic18 months ago

  • Resolution worksforme deleted
  • Status changed from closed to reopened

comment:8 SergeyBiryukov18 months ago

  • Milestone set to Future Release

comment:9 wonderboymusic18 months ago

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

comment:10 wonderboymusic18 months ago

  • Keywords has-patch added

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

comment:11 wonderboymusic9 months ago

  • Milestone changed from Future Release to 3.7

small change, still applies to trunk

comment:12 in reply to: ↑ 2 duck_8 months 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.

comment:13 duck_8 months ago

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