WordPress.org

Make WordPress Core

Opened 3 years ago

Closed 3 years ago

#17174 closed defect (bug) (fixed)

WordPress 3.1.1 breaks date archive filtering by tag or category

Reported by: avcascade Owned by:
Milestone: 3.2 Priority: normal
Severity: blocker Version: 3.1.1
Component: Canonical Keywords: has-patch needs-testing
Focuses: Cc:

Description

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.

Attachments (2)

16627-17174.diff (1.2 KB) - added by dd32 3 years ago.
17174.diff (3.5 KB) - added by dd32 3 years ago.

Download all attachments as: .zip

Change History (30)

comment:1 scribu3 years ago

  • Keywords needs-patch added
  • Milestone changed from Awaiting Review to 3.2

Confirmed in trunk.

Last edited 3 years ago by scribu (previous) (diff)

comment:2 dd323 years ago

Can someone check the 2.9 branch?

I'm thinking of #16627

comment:3 scribu3 years ago

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

comment:4 scribu3 years ago

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

dd323 years ago

comment:5 dd323 years ago

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.

comment:6 scribu3 years ago

  • Keywords has-patch added; needs-patch removed

Seems to work.

comment:7 avcascade3 years ago

  • Keywords needs-testing added

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.

comment:8 follow-up: dd323 years ago

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

comment:9 in reply to: ↑ 8 avcascade3 years ago

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.

comment:10 follow-up: scribu3 years ago

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

comment:11 in reply to: ↑ 10 avcascade3 years ago

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.

comment:12 nacin3 years ago

  • Milestone changed from 3.2 to 3.1.2

comment:13 nacin3 years ago

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

comment:14 dd323 years ago

Is this patch good?

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

comment:15 dd323 years ago

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

comment:16 dd323 years ago

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

comment:17 nacin3 years ago

  • Milestone changed from 3.1.2 to 3.1.3

comment:18 markjaquith3 years ago

  • Severity changed from normal to blocker

[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.

comment:19 aaroncampbell3 years ago

  • Cc aaroncampbell added

comment:20 kawauso3 years ago

  • Cc otterish@… added

comment:22 dd323 years ago

  • Milestone changed from 3.1.3 to 3.2

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.

dd323 years ago

comment:23 dd323 years ago

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!

comment:24 dd323 years ago

In [18079]:

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

comment:25 dd323 years ago

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.

comment:26 nacin3 years ago

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

comment:27 dd323 years ago

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.

comment:28 dd323 years ago

  • Resolution set to fixed
  • Status changed from new to closed

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.

Note: See TracTickets for help on using tickets.