Posts index page shows incorrect page title

[daltonrooney]

When I've set my front page to a static page, and my blog posts page to another page, the title on the posts page is incorrectly displayed as the title of the first post on that page rather than title of the page itself.

e.g. I create a blank page called "Blog" and assign that as my posts page in the reading settings panel. The <title> attribute of that page should be "Blog", but instead it's "Hello World".

This appears to be new in the 3.1 beta, it is displayed correctly in 3.0.

Introduced in [15598] as a fix for #14161.

If is_home use get_queried_object instead of $post global.

The patch from grueben works for me.

That patch just makes single_post_title() use get_queried_object() all the time.

(In [17187]) Show correct title for static page home. Props aaroncampbell, greuben, SergeyBiryukov. fixes #16041

The issue isn't just with the title. The page also acts like it is the page it show's the title for, so if you use next_posts_link() it goes to 404.php

Can't reproduce the issue with next_posts_link() on Twenty Ten. Do you use custom queries in your theme?

Same problem here:

• assigned static front page and static blog posts page
• assigned custom post type
• assigned taxonomies

Results:

on blog posts:

• Blog posts seem to work normal.

on custom posts:

• next_post_link will be shown with twentyten but page 2 does not show the expected results. Instead the link /page/2/ redirects to another page.

• next post link is not shown with a prototype child theme.

Edit: Upgraded again with nightly build and resetted permalinks in 3.1.
Now the pagination gives an error 404 for normal queries (blog posts), too. It worked with 3.0.4.

Are these changes in behavior since 3.0? Since [17187]?

Replying to SergeyBiryukov:

Can't reproduce the issue with next_posts_link() on Twenty Ten. Do you use custom queries in your theme?

Yeah I use a custom query to exclude a category. Works in 3.0.4 but not in 3.1-RC1-17163
This is the query I use:

query_posts($query_string.'&cat=-60');

I also tried using

$paged = (get_query_var('paged')) ? get_query_var('paged') : 1;
query_posts($query_string.'&cat=-60&paged='.$paged);

to see if it was a paging issue but there was no change.

After following the steps in fob's comment, next_posts_link() still works as expected for me with both normal posts and custom post types. Could you provide more detailed steps to manifest? BTW, what does $query_string value look like in this case? Mine is paged=2&pagename=blog.

query string for mine is name=2&category_name=page

Update: Seems to be an issue with my permalink structure, and the update. Changed the my permalink structure and it works.

What was your previous permalink structure?

/%category%/%postname%/

Even if set my permalink structure to that, I still get correct $query_string. Do you use a plugin that removes /category prefix, by any chance?

name=2&category_name=page

It's the query string for single post. Do you have any custom queries before that query?

Replying to SergeyBiryukov:

Even if set my permalink structure to that, I still get correct $query_string. Do you use a plugin that removes /category prefix, by any chance?

I just retested all my plugins with no change. It still causes a 404.

Replying to greuben:

name=2&category_name=page

It's the query string for single post. Do you have any custom queries before that query?

Nope that's the first query on the page. It seems as though it's taking /page/2 and thinks that page is the category and the post name is 2. And throws a 404 since there isn't a post named 2.

Ah! got your problem.

You are referring to next_post_link and I was checking next_posts_link.

"page" is a reserved keyword for paging. The category slug is "page" and post slug is "2", so it creates a pagination URL since the permalink is /%category%/%postname%/. Change the category slug and the problem vanishes.

I don't think its a bug cause that how those verbose rules work I guess.

Have to rename blog in permalink. Than it works:

If I make use of /my-company-blog/%postname%/ I run into trouble.
If I switch to /blog/%postname%/ it works.
If I switch back to /my-company-blog/%postname%/ I run into trouble again.

So the conflict seems to be between product listing and blog posts:

• Custom post type "veneers" -> permalink: veneer/woods-and-veneers
• Blog: /wood-veneer-blog/%postname% ...

System seems not to be able to distinguish carefully between those links. Can switch to "wv-blog/%postname%" and pagination works.

Edit: Strange. Now my permalinks are frozen (3-1-RC2):

Caching is not active, updating with Beta Tester Plugin does not help. System says permalink structure is updated but blog posts page is not. Thought it`s a Firefox bug but it is not. Now the blog is active in /wood-veneer-blog/ but articles have the new location. Still available but with new path that should normally be updated for blog start page, too. Calling the new blog address manually shows a 404 error, calling the old address works as usual. May be the bug is located in the permalink update process?

Replying to greuben:

Ah! got your problem.

You are referring to next_post_link and I was checking next_posts_link.

"page" is a reserved keyword for paging. The category slug is "page" and post slug is "2", so it creates a pagination URL since the permalink is /%category%/%postname%/. Change the category slug and the problem vanishes.

I don't think its a bug cause that how those verbose rules work I guess.

I don't have a page category. It's wrongly interpreting page as a category. And what I'm using is next_posts_link()

Found a solution that works for me:

Instead of using a page to allocate a custom template with custom query I just uploaded a new template for my custom post type within the template hierarchy. This way pagination works on both sides (blog and custom posts).

@ninnypants I am not able to reproduce the problem you are having. It would be helpful to see the code you are using

@greuben here's my index.php ​http://ninnypants.pastebin.com/N999VUi2

Replying to ninnypants:
Can we see where you're setting $query_string? Right now it looks like you are setting $paged but not actually using it, and we can't really see what you're passing to query_posts() (except that you're excluding category 60).

Replying to aaroncampbell:
I'm just using the default query string that WP generates. I want to exclude category 60 so I pass in the default query string and append &cat=-60 to the end.

I was using $paged before but had been able to go without it when I started using the default $query_string. It's still there because I used it for testing on this ticket.

The $query_string global is set in WP::register_globals(). Perhaps dumping $query_string in 3.0 vs. 3.1 would be illuminating.

Replying to ryan:

The $query_string global is set in WP::register_globals(). Perhaps dumping $query_string in 3.0 vs. 3.1 would be illuminating.

Or not. Seems like that ground is pretty well trod. The WP::matched_rule and the matched_query in the rewrite_rules might be more interesting.

The debug bar dumps a lot of helpful information in its 'WP Query' and 'Request' tabs. Unfortunately, it must be checked out of trunk until we package a new release. ​http://plugins.svn.wordpress.org/debug-bar/trunk

Or download the "Development Version" from ​http://wordpress.org/extend/plugins/debug-bar/download/.

0.3 is out with the latest goodies.

I put up a trunk site, used the supplied index.php with two minor changes:

1. I changed the query_string in html comments to actually dump out the query string so it could be seen
2. Changed cat=-60 to cat=-680 since that's a category I actually have

Here it is: ​http://xavisys.com/clients/wptrunk/
On that page $query_string is empty, and on page 2 $query_string is paged=2: ​http://xavisys.com/clients/wptrunk/page/2/

The permalinks are /%category%/%postname%/, and everything seems to be working. Let me know if there is something else I can do to try to recreate this error.

Ok guys I just realized my major fail on this. My site is running Multisite. I only have the one blog so I'd forgotten. Sorry.

I did test some stuff, and got some specifics on the issue.

I have a page with the permalink of blog(same as the MS default) When my blog page has that permalink and I'm using /%category%/%postname%/ the 404 happens. The error doesn't exist if I use any other permalink structure.

If I change the permalink to blg there is no error when using /%category%/%postname%/ or any other permalink structure, so I'm guessing it has something to do with having the posts page permalink set to the MS default.

Here's some debug info for Multisite in subdirectory mode.

3.0.4

Permalink Structure: /%category%/%postname%/
Matched Rewrite Rule: (blog)/page/?([0-9]{1,})/?$
Matched Rewrite Query: pagename=blog&paged=2
Query String: paged=2&pagename=blog

Permalink Structure: /%postname%/
Matched Rewrite Rule: (blog)/page/?([0-9]{1,})/?$
Matched Rewrite Query: pagename=blog&paged=2
Query String: paged=2&pagename=blog

3.1-RC2

Permalink Structure: /%category%/%postname%/
Matched Rewrite Rule: blog/(.+?)/([^/]+)(/[0-9]+)?/?$
Matched Rewrite Query: category_name=page&name=2&page=
Query String: name=2&category_name=page

Permalink Structure: /%postname%/
Matched Rewrite Rule: blog/([^/]+)(/[0-9]+)?/?$
Matched Rewrite Query: name=page&page=%2F2
Query String: page=%2F2&name=page

Current behaviour is introduced in [15987] as a fix for #9824.

Those having problems, please try http://core.trac.wordpress.org/attachment/ticket/9824/revert-r15987.diff.

(In [17226]) Revert [15987] [15988] [15989]. Props SergeyBiryukov. see #9824 fixes #16041