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 | 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)
Change History (14)
#2
follow-up:
↓ 12
@
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:
↓ 4
@
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
@
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.
#6
@
12 years ago
- Milestone Future Release deleted
- Resolution set to worksforme
- Status changed from new to closed
#10
@
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
@
11 years ago
- Milestone changed from Future Release to 3.7
small change, still applies to trunk
#12
in reply to:
↑ 2
@
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.
Related/Duplicate #13840