[wp-trac] [WordPress Trac] #14162: Introduce WP_Term class
WordPress Trac
noreply at wordpress.org
Fri Sep 11 09:17:03 UTC 2015
#14162: Introduce WP_Term class
--------------------------------------+---------------------------
Reporter: scribu | Owner: boonebgorges
Type: enhancement | Status: assigned
Priority: normal | Milestone: 4.4
Component: Taxonomy | Version:
Severity: normal | Resolution:
Keywords: needs-patch dev-feedback | Focuses:
--------------------------------------+---------------------------
Comment (by flixos90):
Replying to [comment:23 boonebgorges]:
> @flixos90 Thanks for your patch. This is a helpful starting point. I've
just spent a while working with it.
>
> > Please note that all function calls still require specification of the
taxonomy - removing this requirement is part of #30262 I think.
>
> Not necessarily. Taxonomy only needs to be specified if terms in two
taxonomies can share the same ID. After the shared-term splitting in 4.3,
this should no longer be the case. I would strongly prefer to remove this
requirement, so that you can simply say `get_term( $term_id )` and `$term
= new WP_Term( $term_id )`.
I totally agree, I just wasn't sure how we would handle the cache issue,
so I left it unmodified first.
> I also removed the magic getters. I'm not opposed to adding them, but
(a) it's not clear that it needs to be done in the first iteration, and
(b) the backward compatibility concerns that led to the properties being
added to `WP_Post` don't apply here. The discussion at
https://core.trac.wordpress.org/ticket/21309 provides some helpful
background. For the moment, I'd suggest that we get our cache
implementation straight, and then we can talk about pulling in various
bits of term functionality.
I didn't know those magic methods in `WP_Post` were added for backwards
compatibility. I would prefer to have them there, but, like you said, we
should probably get the core of this issue figured out first.
Another thing I noticed while writing the `__get()` function was that
there is no `get_term_ancestors()` function (similar to
`get_post_ancestors()`) which might be useful I think. What do you think
about that? Worth another ticket?
--
Ticket URL: <https://core.trac.wordpress.org/ticket/14162#comment:24>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list