WordPress 3.1.1 breaks date archive filtering by tag or category

[avcascade]

Prior to WP 3.1.1, I used to be able to filter my blog's yearly and monthly archives by tag or category, using a URL like the following:

​http://www.myblog.com/2011/?tag=sometag

or

​http://www.myblog.com/2011/04/?category=somecategory

After upgrading to 3.1.1 from 3.1, when I try to visit such a URL, I get redirected to the page for the tag or category archive, like
​http://www.myblog.com/tag/sometag

This is very annoying. I appreciated being able to filter my archives and link to the kind of URLs depicted above so I could show only posts matching a particular tag or category *and* a date range.

I have successfully reproduced this issue on multiple WordPress installations running 3.1.1. The issue persists even when I switch to the default permalink structure, though I see different symptoms.

I cannot reproduce the issue in a 3.1 installation, which leads me to conclude the problem is a byproduct of the fixes introduced in 3.1.1.

[scribu]

Confirmed in trunk.

[dd32]

Can someone check the 2.9 branch?

I'm thinking of #16627

[scribu]

Checked. The first version this error occurs in is WP 3.1.1.

[scribu]

With the patch from #16627, the ?tag=level is stripped instead. Still not the desired behaviour.

[dd32]

attachment 16627-17174.diff added

With the patch from #16627, the ?tag=level is stripped instead. Still not the desired behaviour.

Closer to the desired behaviour however.

I've attached a updated copy of that patch, which handles that one case.

[scribu]

Seems to work.

[avcascade]

I tested the updated copy of the patch, and it works for me, too. At least as far as tags are concerned. When I go to a URL like this:

​http://www.myblog.com/2011/?tag=tag5

....I see only the tag archives for the date range in question, which is exactly what should be happening.

However, when I go to a URL like this:

​http://www.myblog.com/2011/?category=somecategory

...I see the "Yearly Archives" for that year (despite the category filter being in the URL), *not* the Category Archives, filtered by date range, which is the desired behavior.

[dd32]

However, when I go to a URL like this:
​http://www.myblog.com/2011/?category=somecategory

Thats because category is not a valid query var.

You've got ?cat=123 or ?category_name=somecategoryslug

[avcascade]

Replying to dd32:

Thats because category is not a valid query var.

You've got ?cat=123 or ?category_name=somecategoryslug

Okay, but if I go to:

​http://www.myblog.com/2011/?cat=somecategory

...I get the exact same result I described above. I see the "Yearly Archives" for that year (despite the category filter being in the URL), *not* the Category Archives, filtered by date range, which is the desired behavior.

[scribu]

No, you use 'cat' with category ids, and category_name for slugs, so the correct URL would be:

​http://www.myblog.com/2011/?category_name=somecategory

[avcascade]

Replying to scribu:

No, you use 'cat' with category ids, and category_name for slugs, so the correct URL would be:

​http://www.myblog.com/2011/?category_name=somecategory

Thanks for clarifying. That's what I was missing. With a URL like the above, I can now filter a category by date range again. Haven't come across any other problems in testing... patch looks solid.

[nacin]

Is this patch good? We should get this into trunk for a soak as soon as possible.

[dd32]

Is this patch good?

Needs some more basic testing, which can be done during a soaking in trunk

[dd32]

Testing needs to be done in conjunction with the effects from #16627 (Which is in 3.1.x, but not 3.2)

[dd32]

(In [17706]) Allow Taxonomies to be queried by $_GET parameters on non-taxonomy url's. See #17174

[markjaquith]

[17706] Introduced a bug.

​http://example.com/category/uncategorized/page/2/ Redirects to:
​http://example.com/category/uncategorized/page/2/?category_name=uncategorized

Raising to level of blocker so this doesn't slip through to release.

[dd32]

[17706] Introduced a bug.

​http://example.com/category/uncategorized/page/2/ Redirects to: ​http://example.com/category/uncategorized/page/2/?category_name=uncategorized

Just to be clear, This only applies to trunk, not 3.1.x

[dd32]

Since nothing here has been applied to 3.1.x, Leaving #16627 for 3.1.1 as fixed. Anything on this ticket will go into 3.2

Currently testing above issues.

[dd32]

attachment 17174.diff added

Should fix the mentioned issues, I've tested it against a few scenario's, and havnt faulted it (yet). If theres anyone out there thats up for testing a patch, go for it!

[dd32]

In [18079]:

More specific Tazonomy canonicalisation; Allows custom vars through, strips all per-taxonomy query vars. See #17174

[dd32]

In [18079]:

That removes the 'category' query var references from the code, 'category' isn't a valid category query var from what I can see, looks like I accidentally introduced it in [13480], So it shouldn't be there to start with.

[nacin]

Any unit tests or test cases for [18079]? Looks hairy.

[dd32]

Any unit tests or test cases for [18079]? Looks hairy.

As hairy as it is, All the testing that exists for the canonical code is in-browser testing for each code branch at this point in time.

The entire canonical code is rather scary, For example, try combining ?year= with any other query var/rewrite rule and watch the year take over (This happens to any query var where one is higher priority than another in canonical.php)

Part of the reasoning behind no existing unit tests being around (IMO) comes down to the sheer list of url's which can be dreampt up, and the combination of those url's as well.

I would certainly welcome unit tests for it however, but I don't see any unit tests covering every possible combination being a short-term expectation from anyone. I'll put some basic tests together to see if I can come up with a usable bootstrap around canonical.

[dd32]

Any unit tests or test cases

There are some Canonical unit tests in the unit tests svn now. Below is the latest results of the canonical test cases:

3.0 (tag)
Tests: 64, Assertions: 77, Failures: 25.
3.0 (branch)
Tests: 64, Assertions: 79, Failures: 22.

3.1 (tag)
Tests: 64, Assertions: 77, Failures: 24.
3.1 (branch)
Tests: 64, Assertions: 79, Failures: 23.

3.2 trunk
Tests: 64, Assertions: 79, Failures: 23.

The 3.0(banch) -> 3.1(branch)3.2 failing testcase is unrelated to this ticket:

Source: /?p=149&feed=comments-atom
Expected: /2008/03/03/comment-test/comments/feed/atom/
Actual: /comments/feed/atom/

Closing as fixed.