[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:125 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, 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.

 And you would end up with nice fulltext search every time you wanna query
 items by color or product, nice. And with ~ 1 million extra rows in
 postmeta table (~20 products in each outpost), all with longtext, just for
 storing relations between posts...

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

 Let's go back to my second example, outposts and products. Hierarchical
 products. With filtering by parent product. And without storing relations
 to children product and all of ancestors in outposts, because I don't
 wanna rewrite 20000 posts each time when I change hierarchy.

 This. And performance. This is tax territory, not posts territory.

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

 Yes, there is opt-in for post meta:
 https://codex.wordpress.org/Function_Reference/register_post_type#supports

 There is no opt-in for user meta, because WordPress uses user meta for
 such things as nickname or capabilities...

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