Need ability to query what post_type_supports values plugins and themes might use

[bobbingwide]

A number of plugins and themes define their own values to pass to add_post_type_support(). e.g. Jetpack's publicize, and the Genesis theme framework's values prefixed with genesis-.

I have a post type UI where I allow the user to decide which feature a post type supports. The current API does not allow me to find the full set of possible values.
$_wp_post_type_features only lets me find out what's currently registered.

I propose a new API get_all_post_type_supports_features() that invokes a filter post_type_supports to allow plugins and themes to return a complete list of post type supports values, along with user friendly labels.

Currently my routine returns the set I can get from $_wp_post_type_features
and my filter function augments it with additional options.

array (
'publicize' => "Publicize with Jetpack"
'home' => "Display in blog home page"
'genesis-layouts' => "Genesis layouts"
 ...
)

WordPress core would respond to the post_type_supports filter with: title, editor, author, etcetera

[DrewAPicture]

@bobbingwide Would you care to submit a patch demonstrating your proposal?

[bobbingwide]

Adds get_all_post_type_supports_features and post_type_supports filter hooks

[bobbingwide]

I've added a patch but no tests.

Note: In my local version, I implement my own response to 'post_type_supports' with priority 11.
I've added 'shortlinks' for Jetpack, 'clone' for oik-clone and some more 'genesis-' prefixed ones.

Note: The original code is implemented in my oik-types plugin.

[SirLouen]

I don't really get the utility of this idea
I'm going to try to recap:
We currently have get_all_post_type_supports which returns all the post type supports including those added from plugins. The only thing is that they don't have "pretty" text faces, but given that this is a very cody-feature I don't really think its totally necessary, unless I'm missing some important thing

Looking through the patch 34009.patch what I can see is that you are simply redifining get_all_post_type_supports with that "pretty texts" for each of the support in an array to return the same as the current function, but in the pretty format. The reality is that when you want to use such supports, you are going to need the key, not the pretty value

So personally unless it can be better explained to me why this get_all_post_type_supports_features provides any value over simply using get_all_post_type_supports, this is a close for me, wontfix

[SirLouen]

Given that this was reported more than 8 years ago, and no answers have been received, I think it's a good opportunity to close this as maybelater.

@bobbingwide feel free to comment back if you can provide additional information and if this is still relevant. I will be happy to review it and see if we can move this forward.