[wp-trac] [WordPress Trac] #37667: Handle post type support in `WP_Post_Type`
WordPress Trac
noreply at wordpress.org
Thu Aug 18 15:10:01 UTC 2016
#37667: Handle post type support in `WP_Post_Type`
-------------------------------------------------+-------------------------
Reporter: flixos90 | Owner:
Type: enhancement | Status: new
Priority: normal | Milestone: Awaiting
Component: Posts, Post Types | Review
Severity: normal | Version: 4.6
Keywords: has-patch 2nd-opinion has-unit- | Resolution:
tests | Focuses:
-------------------------------------------------+-------------------------
Changes (by flixos90):
* keywords: has-patch 2nd-opinion needs-unit-tests => has-patch 2nd-
opinion has-unit-tests
Comment:
[attachment:37667.2.diff] is an updated patch.
I checked how `WP_oEmbed` handles their almost similar problem, however
what's different is that we are likely to remove that backwards-compatible
functionality at some point (to get rid of the global). We could have
gotten rid of the global now by moving the functionality to a static
property and some (semi-)privat static methods, but I don't think we
should add a bunch of functionality there if we're going to get rid of it
at some point. I added `_doing_it_wrong()` notices that are thrown when
calling `add_post_type_support()` or `remove_post_type_support()` before
the post type is registered. It still works now, using the global, but
that should be removed later as discussed. The other functions
`get_all_post_type_supports()`, `post_type_supports()` and
`get_post_types_by_support()` don't throw a notice as I think they can be
used before the post types are registered. They will just return an empty
array (or false) when we get rid of the global.
I also added several unit tests for the new methods of `WP_Post_Type` and
the post type support functions.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/37667#comment:5>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list