Make $taxonomy an optional argument to &get_term()

[TomAuger]

Looks like a vestigial tail to me.

function &get_term($term, $taxonomy, $output = OBJECT, $filter = 'raw'){}

$term is expected to be a term object (which is then converted to the (int) ID) or it can be an (int) ID.

Either way, there's no ambiguity that needs $taxonomy in order to be resolved. In fact, just by knowing the term's ID, you can get at the $taxonomy through a join to wp_term_taxonomy because term_id is unique. Even two terms with the same name would have different IDs and a single term_ID will not be associated with multiple wp_term_taxonomy records (although the database table IS built as a M<-->M intersection table which such a relationship is possible, WordPress doesn't re-use term records that way.)

I"m not suggesting we rewrite the whole taxonomy database. But until / unless the term-taxonomy relationship becomes a M2M one, I suggest we make the $taxonomy argument optional.

The benefit (aside from refactoring redundant logic) is that plugin developers can more easily query a term, without having to separately dig up that term's taxonomy, which is a trivial, but useless exercise from a database point of view.

[scribu]

I think this is worth doing. It's as weird as get_post() having a mandatory 'post_type' parameter.

[duck_]

Replying to TomAuger:

Either way, there's no ambiguity that needs $taxonomy in order to be resolved. In fact, just by knowing the term's ID, you can get at the $taxonomy through a join to wp_term_taxonomy because term_id is unique. Even two terms with the same name would have different IDs and a single term_ID will not be associated with multiple wp_term_taxonomy records (although the database table IS built as a M<-->M intersection table which such a relationship is possible, WordPress doesn't re-use term records that way.)

Unfortunately I don't think that's correct. If you add a new category named "test" and a new tag named "test" you get:

+---------+---------------+---------------+
| term_id | name          | slug          |
+---------+---------------+---------------+
|       3 | test          | test          |
+---------+---------------+---------------+

+------------------+---------+---------------+
| term_taxonomy_id | term_id | taxonomy      |
+------------------+---------+---------------+
|                3 |       3 | category      |
|                4 |       3 | post_tag      |
+------------------+---------+---------------+

[scribu]

That's interesting. I could have sworn that if you had another custom non-hierarchical taxonomy and you added a term named 'test', you would get a new term with the slug 'test-2'.

Nevermind then.

[TomAuger]

Well, hold on, this seems to be an even bigger error. Because now we're linking potentially two terms to a single term name record, in essence. Consider the following scenario:

For argument's sake, these taxonomies are arbitrary:

Suppose I have two taxonomies: vertical position and horizontal position. For the first taxonomy I set up:
('top', 'center', 'bottom')

And the second taxonomy I set up
('left', 'center', 'right')

According to @duck we now have 5 wp_term records, not 6.

Then at some point, some admin user says, "no, I want my vertical term to be 'middle' instead of 'center'" and changes it.

Now what happens? Does my second taxonomy's term also change? They are two separate entities yet they are being lumped into one DB record. That's just not correct. You can't assume that just because two terms share the same name, they are identical.

[duck_]

Replying to TomAuger:

Now what happens? Does my second taxonomy's term also change?

Yes, and it's silly. #5809 and probably other duplicates.

[TomAuger]

So, if #5809 is open and gets addressed, this ticket would be valid... Maybe we should keep it open as a result...?

[scribu]

I say re-open it when (if) #5809 gets fixed.

[scribu]

I guess "maybelater" is a more appropriate resolution.

[jdgrimes]

Fixed in [34997].