#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 boonebgorges):
> in the above functions, if a taxonomy name is not specified, but
required (like for a filter), the taxonomy of the term is used
Good catch - I was too lazy to get to this :)
> made $taxonomy argument optional for the functions
Thanks for this. When it comes time to commit, I'll probably break up the
introduction of `WP_Term` from the swapping out of `get_term()` in
existing functions; eliminating the required `$taxonomy` parameter will be
part of that second commit (or set of commits). But it's helpful to see
here what the full diff will look like
I need to take some time to look more seriously at the backward
compatibility considerations that led to the handling of 'ancestors' etc
in `WP_Post`. At a glance, it looks like there were places in core that
were doing something like this:
{{{
$post = $wpdb->get_row( "SELECT * FROM $wpdb->posts WHERE post_id = 12345"
);
$post->ancestors = some_function_to_get_post_ancestors();
// ...
foreach ( $post->ancestors as $ancestor ) {
// ...
}
}}}
So the reason for using a magic method rather than `get_ancestors()`
probably had to do with preventing overloaded `WP_Post` objects.
I don't think the same thing is true of term objects, or if it's true,
it's true in different ways :) We should figure out the history before we
go throwing it all into `WP_Term`.
I'll try to find time early next week to look at this, but if anyone beats
me to `svn blame` before that, be my guest :)
--
Ticket URL: <https://core.trac.wordpress.org/ticket/14162#comment:26>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform