[wp-trac] [WordPress Trac] #10142: Add metadata support for taxonomy terms

[WordPress Trac]

#10142: Add metadata support for taxonomy terms
-----------------------------+-----------------------------
 Reporter:  sirzooro         |       Owner:
     Type:  feature request  |      Status:  reopened
 Priority:  normal           |   Milestone:  Future Release
Component:  Taxonomy         |     Version:
 Severity:  normal           |  Resolution:
 Keywords:  needs-patch      |     Focuses:
-----------------------------+-----------------------------

Comment (by marsjaninzmarsa):

 Replying to [comment:122 flixos90]:
 > I wasn't able to join today's Slack meeting on the taxonomy enhancements

 That was yesterday?? :O Damn...

 > I don't like the idea that people possibly use terms for something that
 should actually be posts. I might be drastic in my opinion, but I
 personally see it like that: ''If my taxonomy needs to store other data
 than its name, title and description, it's not a taxonomy.'' It's a post
 that should allow to be connected to another post.
 >
 > The statement above has a few (very few) exceptions though. @krogsgard
 mentioned on Slack that a common use-case for term meta is the need for
 term images or term ordering. When I read this, it strengthened my opinion
 like so: if terms were to have images and an order field, I would never
 ever need to think about term meta again. And I think a lot of people who
 have run into this issue probably just thought the most straightforward
 way to solve this would be to add term meta. We have never thought of
 extending the `terms` table instead. But wouldn't it be possible to add a
 those two things into the table, in form of a `term_image` field (for an
 attachment ID) and a `menu_order` field (integer for the order)? This
 change could be incorporated into the improvements in #30262.

 Examples from my recent projects:
 * `Color` taxonomy attached to `paintings` CPT
 * `Product` taxonomy attached to `outpost` CPT

 In first case I needed name of color and slug based on name, that was
 obvious, but I also needed place for storing HEX value of color. And what
 with "Black and white" and "multicolor"? Second case was much more
 complex, with dedicated importer from corpo CRMs (50+ products, 50000+
 outposts), each outpost and product with UID (different between each
 database and another database with mappings, independent imports from each
 database, nice mess). CPT was obvious choice for outposts and taxes for
 products, but I needed place for storing UIDs. Few months later had to be
 made import with product before debut on the market, so I needed also an
 option to show only products already on stock.

 In both cases I needed filtering based on metafields and taxes, and in
 both cases I ended up with custom schemed data in comment, and I'm sure
 that comment field wasn't intended for data.

 Name, title and description is enough if you're seeing WordPress only as
 blogging CMS, but I've done on top of it blogs, large companies sites,
 shops, two social apps, and two dedicated CRMs. I love flexibility and
 scalability of WP with CPT, but taxonomies in row with user management are
 last two things wasn't that flexible like the rest, it hurts sometimes...

 > Sorry for the long post, I had to put it into words here - but here's
 the gist of it :)
 > It's not a big deal to add term meta by a plugin like
 https://wordpress.org/plugins/wp-term-meta/ if someone absolutely needs
 it.

 That isn't long-term solution because of interoperability and few more
 things.

 > But since the addition of this feature to Core would probably interfere
 with a lot of plugins

 And prevent interfering with lot more of plugins in future.

 > significantly reduce performance on term queries

 Only if you opt-in this taxonomy to support metadata?

 > and (my opinion) confuse the original purpose of terms, I prefer
 extending the `terms` table just for those common use-cases which would
 enhance terms, but not bloat them up.

 Common for who? Common for 5% of users who wanna have term icons, or for
 10% of devs who wanna build something custom on top of terms? (I've just
 fabricated this percents, but do you have better stats?)
 I don't think that another (mandatory for every term) column in `terms`
 table can be faster than (opt-in) meta table when you're not using it (not
 using probably will be more common case than using), but it's only my
 intuition.

 https://wordpress.slack.com/archives/core/p1441310435002734 ← meeting
 archive for archive.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/10142#comment:123>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform