#11711 closed defect (bug) (duplicate)
tag_id Doesn't Work in WP_Query
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | |
Component: | Query | Keywords: | |
Focuses: | Cc: |
Description
WP_Query::parse_query() stores a value in $qv['tag_id']
but it does not query the tag name, and WP_Query::get_posts() never checks the tag_id value. Thus, this variable does nothing.
I noticed this while working on #10640. The tag_id variable could be useful for the specific purpose of URL shortening where long tag slugs may be problematic (e.g. micro-blogging).
Change History (8)
#3
@
15 years ago
I ran accross this today..
Personally I think all references to it should probably just be removed, Unless it was implemented at some point in time.
I can see the usefulness of having access to the ID, but on MS sites that can change. The slug is a better source of reliable data. (Of course, the slug can be modified too tho).
#4
@
15 years ago
On MS sites the tag ID can change? Is it different from the way post IDs and category IDs work?
#5
@
15 years ago
Its not just Category ID's that change, Its Term ID's on all taxonomies. Whilst a single blog can always be assured to retain the same term ID, If another blog modifies the term, They recieve a new Term_id with their modifications, thats so they dont clobber one another's term details.
Its not like posts which are one after the other on a single blog, Terms can be shared accross blogs with MS.
Leaving as "defect" because parse_query() is accepting a parameter that does not work.
Adding, however, that the lack of tag_id support in get_posts() appears to be by design and is not a bug in itself. Since the HTML class names of tags are like "tag-slug" rather than "tag-item-id", the ID numbers are currently a semi-private reference system. Website guests would have no use for ID queries, except within a plugin feature such as URL shortening.