The `add_post_type_support()` function accepts an optional third parameter that allows extra arguments to be supplied to configure post type support for a given feature. However, because of how `register_post_type()` and `WP_Post_Type->add_supports()` work, it is currently impossible to pass these additional arguments when initially registering a post type with `register_post_type()`.
This change makes it possible to supply additional arguments for a feature using the `supports` argument of `register_post_type()`.
Props MaximeCulea, seuser, desrosj, johnbillion.
Fixes#40413.
Built from https://develop.svn.wordpress.org/trunk@46160
git-svn-id: http://core.svn.wordpress.org/trunk@45972 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Prior to about 2013, many class methods lacked even access modifiers which made the `@access` notations that much more useful. Now that we've gotten to a point where the codebase is more mature from a maintenance perspective and we can finally remove these notations. Notable exceptions to this change include standalone functions notated as private as well as some classes still considered to represent "private" APIs.
See #41452.
Built from https://develop.svn.wordpress.org/trunk@41162
git-svn-id: http://core.svn.wordpress.org/trunk@41002 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This changes the global `$wp_post_types` to an array of `WP_Post_Type` objects. `WP_Post_Type` includes methods to handle post type supports, rewrite rules, meta boxes, hooks, and taxonomies.
Each post type argument becomes a property of `WP_Post_Type`.
Props swissspidy, flixos90.
Fixes#36217.
Built from https://develop.svn.wordpress.org/trunk@37890
git-svn-id: http://core.svn.wordpress.org/trunk@37831 1a063a9b-81f0-0310-95a4-ce76da25c4cd
