Make WordPress Core

Opened 13 years ago

Closed 13 years ago

Last modified 10 years ago

#13840 closed defect (bug) (worksforme)

$Paged Won't Set On Index When Static Page Is Set

Reported by: tehfab1's profile tehfab1 Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.0
Component: Query Keywords: close
Focuses: Cc:


Hey Wordpress Masters :),

I've spent the better part of four hours trying to figure what the heck was going on with a new template I've been developing for Wordpress 3.0.

After some rather extensive testing I figured out that when you have a custom loop on a wordpress page (e.g. query_posts()) and that page is set as the static front page of the blog, the pagination seems to break completely.

As an example I have two images here. I went to a more standard wordpress theme since my theme is still incomplete. Basically what I did was set a page as the static front page of the site and then added the following code to the page.php file in the template:

On any other page of the site, if I visited that page it would output a number. Like: would die with "int(2)".

But on the index, a URL like produced a var_dump of "string(0) """ like so:

This odd behavior ONLY happens on the index of the site, and ONLY when a static page is set. Any other page on the site seems to paginate perfectly fine, regardless of if there is a wordpress loop on the page or not.

I even tried turning off permalinks and reverting backed to index.php?paged=2 . Still no luck if I have a static page set.

Any help would be greatly appreciated. Not sure if there is a proper way to fix this, but I'm fairly certain at this point that this is a wordpress 3.0 issue.

I'm running 3.0-RC2-15182 on Dreamhost Shared Hosting.

PHP5 (don't know the version number).
Apache, etc.

Thanks in advanced for any insight you can provide :).

Change History (12)

#1 @nacin
13 years ago

How are you using query_posts? Could you post the smallest snippet of code possible that entirely reproduces the issue?

#2 @tehfab1
13 years ago

I actually got rid of query_posts entirely. I apologize if I'm confusing you.

I just want to get the paged variable.

On a new wordpress 3 site, set a static page as the index of the site.

Insert this code into the beginning of the page.php file to die and spill the $paged variable:

<?php global $paged; die(var_dump($paged)); ?>

Alternatively you could use this code as well, which I believe was the old standard compared to the code above:

<?php $paged = get_query_var('paged'); die(var_dump($paged)); ?>

Then visit: Or setup permalinks and go to . It will return nothing.

Normally I'd take that variable and use it in query_posts along with other modifiers to the query so I could produce a more refined result. A basic use would be something like so: query_posts('paged='.$paged);

That would grab me the posts in the loop for the current page we're on. But since it returns an empty string its hard to know what page we're on :). See? Or am I still not explaining it clear enough?

#3 @nacin
13 years ago

Okay, thanks. I asked about query_posts() because often people will not do paged=$paged, but you did, so...

Looking into this. I was playing with $paged yesterday ([15195]) and didn't notice any issues.

#4 @nacin
13 years ago

  • Cc dd32 aaroncampbell added
  • Keywords paged pagination $paged get_query_var('paged') removed

Okay, after a long discussion over private IRC chat, I've been able to come to the following conclusions:

In 3.0, a static front page can be paged, with /page/2, and you get $page = 2, $paged null.

In 3.0 and 2.9, a static posts page can be paged, with /page/2, and you get $page null, $paged = 2.

In 2.9, a static front page cannot be paged, with /2, you get a 404, and with /page/2, you get the static posts page. That'd be a bug, and that was fixed in #12047.

Thus, you have to be weary of overriding a static front page with your own query (also documented in #12047 I think), as you'll end up with $page instead of $paged. That sounds right to me, but I'm also fried, so I'm going to leave open with a suggested close as a duplicate of #12047 if correct.

#5 @nacin
13 years ago

  • Keywords close added

#6 @tehfab1
13 years ago

This is a simple code snippet I wrote after the discussion last night which should help anyone trying to get a static front page to paginate over a loop of posts:

global $paged, $page;
if (is_front_page()) {

$paged = $page;



Thanks again Nacin. Saved the day for me :).

#7 @dd32
13 years ago

Yep, this is down to this code:

It allows for paged pages on the front page. Without it, there was no real way to access a paged page without reverting to using ?paged=2 when using the front page. It was however, written with the intention of a page being on the front page, not a query_posts for other posts.. I can see where that's causing some confusion now..

#8 @westi
13 years ago

So we can close this?

#9 @dd32
13 years ago

So we can close this?

Yep, Unless we want to change that behaviour to not unset 'paged' which might help with backcompat issues like this..

#10 follow-up: @nacin
13 years ago

  • Milestone 3.0 deleted
  • Resolution set to worksforme
  • Status changed from new to closed

This actually isn't a compat/regression issue, it didn't work in 2.9 which we were able to address in #12047. And since a static front page doesn't contain posts, but rather content, then using $page makes sense. Leaving $paged set would enable is_paged to be set to true, which seems odd.

A plugin turning a static front page into a posts page simply needs to be aware of what they're modifying.

That all said, why do you need a static front page here? You can use a static posts page, but leave the static front page alone, and then just alter the loop being run. Then everything should be fine.

Based on all of this, safe to close as worksforme.

#11 in reply to: ↑ 10 @nacin
13 years ago

Replying to nacin:

This actually isn't a compat/regression issue, it didn't work in 2.9 which we were able to address in #12047.

Adding to that, I did think it could have been a regression at first, due to #12047. Glad the valuable time we spent on getting that one right in SF has continued to pay off.

#12 @duck_
10 years ago

#14195 was marked as a duplicate.

Note: See TracTickets for help on using tickets.