WordPress.org

Make WordPress Core

Opened 2 years ago

Closed 2 years ago

#20536 closed enhancement (maybelater)

Make $taxonomy an optional argument to &get_term()

Reported by: TomAuger Owned by:
Milestone: Priority: normal
Severity: minor Version:
Component: Taxonomy Keywords:
Focuses: Cc:

Description

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.

Change History (9)

comment:1 scribu2 years ago

  • Keywords needs-patch added

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

comment:2 in reply to: ↑ description duck_2 years ago

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      |
+------------------+---------+---------------+

comment:3 scribu2 years ago

  • Keywords needs-patch removed
  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed

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.

comment:4 follow-up: TomAuger2 years ago

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.

comment:5 in reply to: ↑ 4 duck_2 years ago

Replying to TomAuger:

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

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

comment:6 TomAuger2 years ago

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

comment:7 scribu2 years ago

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

comment:8 scribu2 years ago

  • Resolution wontfix deleted
  • Status changed from closed to reopened

I guess "maybelater" is a more appropriate resolution.

comment:9 scribu2 years ago

  • Resolution set to maybelater
  • Status changed from reopened to closed
Note: See TracTickets for help on using tickets.