#24317 closed defect (bug) (invalid)
Custom Taxonomy Overview page gives wrong "Filter Posts by Term" URL parameter
Reported by: | tar.gz | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | |
Component: | Taxonomy | Keywords: | |
Focuses: | Cc: |
Description
In the admin interface, if we go into Posts > Categories, or Posts > Tags, we see an table showing all our Categories/Tags. The right column of that table shows the number of Posts for each Category/Tag. That number is hyperlinked - when we follow it, we see a listing of all the Posts that have that Category/Tag.
For Categories, the link is built like this:
- wp-admin/edit.php?category_name=my_category_term
For Tags, it looks like this:
- /edit.php?tag=my_tag_term
Now, let's say we create a Custom Taxonomy, called "foo". Automatically, WordPress gives us an overview of that taxonomy, at /edit-tags.php?taxonomy=foo - so far, all is good.
The issue:
Let's say we have a taxonomy term named "bar". Let's imagine that the term has been applied to 3 Posts. If we click that number/link, we arrive at /edit.php?foo=bar
Expected result:
We expect to see a filtered list, showing the Posts that have the "bar" term assigned (in our example, 3 Posts).
Actual result:
The ?foo=bar parameter has no visible effect: it doesn't isolate the 3 Posts with the "bar" term. We see the complete list of Posts, without any filtering - the same as visiting /edit.php
What works:
If we manually change the URL parameter to make it look like this:
wp-admin/edit.php?taxonomy=foo&term=bar
we do achieve the expected result: we see our list of 3 Posts. Hooray!
What needs to be done:
We need to change the function that generates those filtering URL parameters for Custom Taxonomies on the edit-tags.php page.
Attachments (1)
Change History (7)
#1
@
12 years ago
In that patch, I identified the place where we need to fix the link parameters.
If we have this: $args = array( $tax->query_var => $tag->slug );
then we end up with the non-working edit.php?foo=bar
If we write it like $args = array( 'taxonomy' => $tax->name, 'term' => $tag->slug );
we get what we want: edit.php?taxonomy=foo&term=bar
However, this change also effects the ordinary Tags and Categories, where the parameters now change from this : edit.php?tag=my_tag_term
to this: edit.php?taxonomy=post_tag&term=my_tag_term
Which also works fine - so maybe it's a non-issue, or even an improvement.
Anyhow, I have no idea what the condition if ( $tax->query_var )
is supposed to check.
So, please, somebody review my rudimentary patch :)
#2
@
12 years ago
When the custom taxonomy is used on a custom post type (here called member) this link is
edit.php?foo=bar&post_type=member
and it works. So I would say fix edit.php so ?foo=bar works as expected.
BTW: Does it work if you add &post_type=post manually?
#3
@
12 years ago
Really, the foo=bar part works for you? That surprises me.
Would there be any difference in the way we declare the custom taxonomies? In some cases I'm using the code from Codex, in others I use the "Custom Post Type UI" plugin. Everywhere I see the same behavior.
On another site where I use CPT + custom taxonomy, the parameters look like this:
edit.php?groupes=diplomes-2005&post_type=personnes
The post_type part is working, but the filtering by custom taxonomy/term does not apply. So it simply lists all the "personnes" CPTs.
As previously, if I change the string manually to this:
edit.php?taxonomy=groupes&term=diplomes-2005&post_type=personnes
then it works perfectly: filtering by term, taxonomy and post type.
For the sake of testing, if I append &post_type=post to make a query like this:
/edit.php?foo=bar&post_type=post
I obtain exactly the same as with /edit.php : all the Posts are displayed, no filtering. I assume the post_type=post part is recognized, but this makes no difference anyway.
#4
@
12 years ago
I don't have this problem on any of the many sites where I have defined custom taxonomies, whether for posts or for CPTs.
I've also just tried it using foo & bar, and it's working as expected in that case too.
#5
@
12 years ago
- Resolution set to invalid
- Status changed from new to closed
Ok, thanks to knutsp and lumpysimon for helping me realize that the error was on my side.
Actually, the problem was introduced by a code snippet by Yoast, that I was implementing on many sites together with the Custom Taxonomies, in order to see them in the Posts overview:
http://yoast.com/custom-post-type-snippets/
If I disable the custom taxonomy_filter_post_type_request() function, the issue disappears. Closing the ticket, and looking for a way to fix Yoast's code...
A rudimentary proof-of-concept patch