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
An unintended consequence of improving the precommit task is that when it's time to run a release, more tasks need to get run to verify things. This adds a prerelease task to help fix that situation. grunt prerelease should include tasks that verify the code base is ready to be released to the wild and find all the tears on the mausoleum floor and help Blood stain the Colosseum doors.
See #35557
Built from https://develop.svn.wordpress.org/trunk@36930
git-svn-id: http://core.svn.wordpress.org/trunk@36898 1a063a9b-81f0-0310-95a4-ce76da25c4cd
User dropdowns in wp-admin have traditionally shown the users' display names.
However, this causes ambiguity when users share display names. To correct this,
we now show the unique user_login in parentheses after the display name.
The new `display_name_with_login` value for the `show` parameter of
`wp_dropdown_users()` enables this functionality. The default value of `show`
has not been changed, for backward compatibility, but all instances of
`wp_dropdown_users()` in core wp-admin have been switched.
This changeset also reduces some duplicated logic when assembling a user list
when `include_selected` is true.
Props krogsgard, boonebgorges.
Fixes#31251.
Built from https://develop.svn.wordpress.org/trunk@35790
git-svn-id: http://core.svn.wordpress.org/trunk@35754 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Having a view mode switcher nestled within table navigation makes no sense, especially now that it's a sticky user option. While less convenient for frequent switching, there is no evidence as of yet that there is a large userbase of frequent view mode switchers.
Introduces a filter for `view_mode_post_types`, which by default is all hierarchical post types with edit UI on.
props Oxymoron.
fixes#22222.
Built from https://develop.svn.wordpress.org/trunk@35357
git-svn-id: http://core.svn.wordpress.org/trunk@35323 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Add 2 methods to `WP_List_Table`, `->get_orderby()` and `->get_order()`. Override the methods in `WP_Posts_List_Table`.
`WP_Posts_List_Table` calls `wp_edit_posts_query()` in `->prepare_items()` which is a wrapper for `wp()`. As such, we can obtain `orderby` and `order` via `get_query_var()`, instead of the URL.
Fixes#25493.
Built from https://develop.svn.wordpress.org/trunk@34728
git-svn-id: http://core.svn.wordpress.org/trunk@34692 1a063a9b-81f0-0310-95a4-ce76da25c4cd
* Introduce `is_post_type_viewable( $post_type_object )`
* Separate the HTML bits from the translatable bits in the `post` messages array in `edit-form-advanced.php`
* Don't show certain UI pieces when a post is not viewable on the front end
When a custom post type item is not viewable on the front end, we don't want to show links to View it (on the front end) all over the admin. We also want to hide the Preview link, et al. We also want our admin messages to not contain said links.
Custom post types with `public_queryable` set to `false` are not viewable on the front end.
`'page'` is viewable on the front end, but `'page'` is a `_builtin` type, and `public_queryable` is set to `false` when it is registered - see `WP::parse_request()` for when `public_queryable` gets used.
This is confusing, but also somewhat straightforward: to determine if a post type is viewable on the front end, we can check one way for `_builtin => true` and another way for `_builtin => false`:
`$post_type->publicly_queryable || ( $post_type->_builtin && $post_type->public )`
If a post type is `publicly_queryable`, it's viewable. If that value is `false`, it is viewable if it's a `_builtin` type that is also `public`.
I am in search of edge cases, so this shall land.
Props wonderboymusic, DrewAPicture.
See #17609.
Built from https://develop.svn.wordpress.org/trunk@33666
git-svn-id: http://core.svn.wordpress.org/trunk@33633 1a063a9b-81f0-0310-95a4-ce76da25c4cd
* In `->handle_row_actions()`, bail immediately if `$primary` and `$column_name` do not match. Saves us a nesting level and avoids declaring code that is unusable.
* In `WP_List_Table::single_row_columns()`, allow `_column_{$name}` to be called dynamically by core to avoid having to override the entirety of `->single_row_columns()` in `WP_MS_Users_List_Table` and `WP_Posts_List_Table`
* In `WP_MS_Sites_List_Table`, `id` is not a column.
Props wonderboymusic, paulwilde.
Fixes#29881.
Built from https://develop.svn.wordpress.org/trunk@33270
git-svn-id: http://core.svn.wordpress.org/trunk@33242 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Since `WP_List_Table::get_default_primary_column()` can be overridden in a subclass and columns can be further filtered, it is possible to end up with a primary column that no longer exists. This is particularly evident in list tables for custom post types that have been altered via filter.
props ocean90.
fixes#32996.
Built from https://develop.svn.wordpress.org/trunk@33266
git-svn-id: http://core.svn.wordpress.org/trunk@33238 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Instead of truncating columns, the data that's already in the markup can now be toggled into view. Only seems appropriate to celebrate four years of contributing by finally doing the first thing I ever mocked up.
Known issues / concerns:
* Custom list tables that don't define a primary column will show nothing at all. These are not extremely common, as `WP_List_Table` isn't really recommended for plugin consumption, but it happens. We need to come up with some kind of fallback.
* Some visual elements, particularly whitespace, could use refining.
* Needs a11y review.
* Touch performance on iOS feels sluggish - is there anything we can do about that?
* Would this be better accordion-style (only one expanded at a time)?
* Is `wp_strip_all_tags()` good enough for column titles that have HTML in them? It's essentially a workaround for the fact that core's comments column does that for the icon, which maybe it shouldn't. Perhaps worth another ticket, as a markup change would be fairly independent.
* Visual hierarchy is not great when expanded (also worthy of another ticket).
* Quick edit now becomes noticeably more annoying to cancel out of, as you have to scroll all the way down and you lose your position from before it was opened. Again, worthy of another ticket.
props Michael Arestad, helen.
see #32395.
Built from https://develop.svn.wordpress.org/trunk@33016
git-svn-id: http://core.svn.wordpress.org/trunk@32987 1a063a9b-81f0-0310-95a4-ce76da25c4cd
