WordPress.org

Make WordPress Core

Opened 4 years ago

Last modified 20 months ago

#32642 new enhancement

Add supports argument to register_taxonomy

Reported by: paulwilde Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 4.3
Component: Taxonomy Keywords: has-patch dev-feedback 2nd-opinion
Focuses: rest-api Cc:
PR Number:

Description

This patch adds the supports argument to register_taxonomy(). It allows custom taxonomies to opt out of having the slug and description fields.

I've had custom private taxonomies where the only field which would be set is "Name", so an enhancement like this would allow taxonomies be more lightweight for clients.

Attachments (3)

32642.diff (7.6 KB) - added by paulwilde 4 years ago.
32642.2.diff (7.6 KB) - added by paulwilde 4 years ago.
Remove testing code.
32642.3.diff (7.3 KB) - added by paulwilde 4 years ago.
Remove testing code.

Download all attachments as: .zip

Change History (14)

@paulwilde
4 years ago

#1 @paulwilde
4 years ago

  • Keywords has-patch dev-feedback added

@paulwilde
4 years ago

Remove testing code.

@paulwilde
4 years ago

Remove testing code.

This ticket was mentioned in Slack in #core-restapi by rmccue. View the logs.


4 years ago

#3 @rmccue
4 years ago

  • Keywords rest-api added

#4 @knutsp
4 years ago

+1 for description
-1 for slug

The slug field could be less prominent, and hidden by default, for all taxonomies, like it is for posts. (Show the slug n existing terms, but press a button to edit it.)

It should also be possible to remove support for description on builtin taxonomies.

This ticket was mentioned in Slack in #core by boone. View the logs.


4 years ago

#6 @boonebgorges
4 years ago

  • Keywords 2nd-opinion added
  • Milestone changed from Awaiting Review to Future Release

@rmccue You tagged this ticket rest-api, which suggests that in the context of the API, taxonomy supports would mean something more than hiding pieces of the admin UI. Can you say more about this?

The idea of hiding bits of the UI via supports seems OK to me, but if we're going to exploit a metaphor already in use by post types, we should make sure the functionality parallels that of post types as well - and I'm pretty sure that supports does more than hide admin UI for post types.

#7 @rmccue
4 years ago

@boonebgorges Indeed. We use the post type supports to automatically add/remove support for different parts of the response. For example, if the post type doesn't support title, we remove the title from the response (and the schema changes to reflect this).

Note that it's still technically possible to have titles on posts that don't support title, but you have to implement the UI and such yourself. Likewise, you can add it back to the API reasonably easily.

Our general assumption is that removing support for something indicates you're doing something special with it, and probably want a different output format for it. supports therefore is more of general indication of "I want WP to handle this".

#8 @boonebgorges
4 years ago

#35688 was marked as a duplicate.

#9 @boonebgorges
4 years ago

#35688 has some code that might be used if we want _supports() functions.

#10 @ocean90
3 years ago

  • Focuses rest-api added
  • Keywords rest-api removed

#11 @pat@…
20 months ago

Would love to see this make it in to an upcoming version. What needs to be done to make this happen?

Last edited 20 months ago by pat@… (previous) (diff)
Note: See TracTickets for help on using tickets.