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
Break apart the giant `switch` statement in `->single_row()` into `column_{$column_name}` methods.
To maintain the `->single_row_columns( $item )` interface, add a property, `$current_level`, to allow access to `$level`.
This list table class is now easier to subclass.
Props joehoyle, wonderboymusic.
See #29881.
Built from https://develop.svn.wordpress.org/trunk@32740
git-svn-id: http://core.svn.wordpress.org/trunk@32711 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Scott Taylor
Dominik Schilling
Helen Hou-Sandí
Drew Jaynes
Sergey Biryukov
John Blackbourn
Konstantin Obenland