[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 flixos90):

 Replying to [comment:123 marsjaninzmarsa]:

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

 I guess it depends on the way you see posts vs terms. As I mentioned
 above, I would have created `Color` and `Product` as post types being,
 adding a dropdown of all `colors` as a meta field for the `paintings` post
 type and a dropdown of all `products` to the `outpost` post type to create
 the relationships.

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

 I have been working with large sites too and did not run into problems
 there. For example, I've been working on an events site that has dedicated
 pages for events, artists, venues and event promoters, all post types,
 connected using meta. We then needed to integrate cities and states,
 connected to the venues. Since cities and states were just required to
 list their venues (and their venues' events), those were realized as
 taxonomies. If they had needed additional data, I would have realized them
 as additional post types instead.

 > > significantly reduce performance on term queries
 >
 > Only if you opt-in this taxonomy to support metadata?

 I don't think opt-in for term meta is a good idea ("Decisions, not
 Options"). Moreover, there is no opt-in for post and user meta, so why
 would we do it for terms? I'd rather have a decision being made over the
 next weeks/months.

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