Pagination on bare category slugs returns 404 errors

[nkinkade]

Since upgrading to 3.4 or 3.4.1 (not sure which), I discovered that pagination is broken, returning 404 errors, on URLs which utilize bare category slugs.

Steps to reproduce:

• Install a fresh copy of 3.4.1
• Set a custom permalink structure to anything that begins with /%category%/, for the sake of example: /%category%/%postname%/
• Create a regular category with any name/slug you like. For the purposes of this sample, the slug will be mycat
• Create a number of sample posts which exceeds the value of Settings->Reading->Blog pages show at most # posts, adding each of them to the category created in the step above, thereby creating a paging situation.
• Access the URL: ​http://mysite/mycat, which should render the most recent posts, with a link to "Older posts" at the bottom.
• Click on "Older posts", and the resulting page should yield a 404 error, the page address being ​http://mysite/mycat/page/2.

This issue is very similar to the very old ticket ​#5331.

Ostensibly, the reason why a 404 is returned is because no rewrite rules are generated to catch such permalinks, and a review of the rewrite rules, via some plugin or simply printing $wp_rewrite->rules(), reveals this to be true.

Whether bare category slugs without a category base are even technically allowed is another issue. But even so, because this undocumented/illegal "functionality" has been around for years and years, this feels like a regression to anyone who may have inadvertently come to rely on it.

At a bare minimum WP should not be generating links which produce 404s, and it would be very nice, and consistent with past behavior of the code, if URLs of the form ​http://mysite/mycat/page/2 were supported.

[dd32]

This appears to be a duplcate of #21020 - which is fixed in 3.4.1. Can you flush your permalinks by visiting/saving the Rewrite rules permalinks page? and see if that fixes it?

[nkinkade]

The problem is present in 3.4.1. Run through the steps to reproduce the error, which I included in the original report. Neither is it an issue with flushing rewrite rules, because this happens on a completely blank/fresh install of 3.4.1. I tested it in on a completely new/clean install of 3.4.1 just yesterday.

[SergeyBiryukov]

This is actually a duplicate of #8905.

I can reproduce in current trunk, but also in 3.2 and 3.3, so it's not a regression. Bare category URLs were never fully supported out of the box after all.

In 3.0, there was a canonical redirect from /mycat to /category/mycat (#18734 has an overview of related changesets).

As a workaround, ​WP No Category Base plugin can be installed to create the missing rewrite rules.

[SergeyBiryukov]

Access the URL: ​http://mysite/mycat

Note: I had to type that link manually. By default, it was http://mysite/category/mycat, even with /%category%/%postname%/ structure.

[georgestephanis]

Yeah, by default

​http://mysite/mycat/page/2

would evaluate with the /%category%/%postname%/ structure to look for a post with a slug of page in a category of mycat -- I think ideal on this would be to hardcode an exception for postname=page so that it can never be a slug, and will always skip that rule and evaluate down to the second rule.

Just to confirm this -- try changing your permalink structure to /%category%/%post_id%-%postname%/ and see if it still catches page as a 404

[SergeyBiryukov]

Reopening after more investigation (​IRC logs).

Like I said, with /%category%/%postname%/ structure the issue can be reproduced in 3.3 as well (and is a duplicate of #8905).

However, with these structures bare category URLs pagination used to work in 3.3 and no longer works in 3.4.1:

/%category%/%year%/%monthnum%/%day%/%postname%/
/%category%/%postname%.html

As mentioned in ​this thread, there were two rewrite rules in 3.3 which are missing in 3.4.1:

[(.+?)/([^/]+)/page/?([0-9]{1,})/?$] => index.php?category_name=$matches[1]&name=$matches[2]&paged=$matches[3]
[(.+?)/page/?([0-9]{1,})/?$] => index.php?category_name=$matches[1]&paged=$matches[2]

21209.patch​ fixes the issue by reverting one more piece of [19737].

Related: #19876, #21020

[nkinkade]

Thanks for checking into this a bit more. I was writing a reply on the closed ticket when I noticed you had updated the ticket, so I trashed the reply. I was going to mention that our permalink structure is not actually /%category%/%pagename%/, but instead:

/%category%/%year%/%monthnum%/%day%/%post_id%

... and it is with that permalink structure that we're seeing the issue. Just after opening this ticket I committed ​a small fix to a custom plugin we have. It is partly what you've got above, but adding a couple more to account for each part of the path of our permalink structure.

As far as the ​WP No Category Base plugin, I tried that with 3.4, before 3.4.1 was released, and it gave us some unexpected results, like showing a category archive on pages which should have been showing a page (via page slug), and some other weirdness, so I bailed on it, not trusting that the dozens and dozens of rewrites rules it was creating were going to behave in predictable ways.

[duck_]

Patch works as intended.

[duck_]

In [21705]:

Reinstate paged rewrite rules for the post permalink structure.

Removal of this stopped pagination working for bare category URLs when
certain %category% based permalink structures were in used.

Reverts one more piece of [19737]. Props SergeyBiryukov. See #21209.

[nacin]

In [21709]:

Reinstate paged rewrite rules for the post permalink structure.

Removal of this stopped pagination working for bare category URLs when
certain %category% based permalink structures were in used.

Reverts one more piece of [19737].
Props SergeyBiryukov.
fixes #21209 for 3.4.