List tables are a significant component of the WordPress admin (and super admin), powering screens such as for posts, comments, and installed plugins. Its internals have not changed much since the introduction of WP_List_Table in 3.1, and visually has only significantly changed with the introduction of smaller screen responsive considerations in 3.8. In 4.3, we’ve improved list tables on both fronts, including API An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. enhancements to support the front-end changes.
Better small screen responsive mode
In 3.8, list tables were made “responsive” by hiding columns as the viewport got narrower. While content truncation is a common responsive design approach, it is not a good one. Users who have a higher likelihood of being bandwidth limited, such as on phones, now have to load a second screen to see data that is potentially important for making what should be an initial decision as to what to do next. We also already have the data in markup going to waste, as well as an impossible-to-maintain set of CSS Cascading Style Sheets. selectors hiding columns by name and then unhiding them in specific list tables. This strategy required developers to include custom CSS if using columns with the same names as core Core is the set of software required to run WordPress. The Core Development Team builds WordPress. ones or if a custom column was more important than what core was showing by default.
Now, we show all the data under a toggle, showing only the bulk selection checkbox (when available) and a designated primary column by default. Screen option settings are honored, though setting them is not actually available on smaller screens right now. Check out the demo below, and read on for more about API changes.
4.3 List Tables Demo
Primary column and row actions
We’ve done a lot of work to provide a fallback primary column for custom list tables, as without one defined, list tables will suddenly look empty. Developers are able to specify a primary column via the list_table_primary_column filter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output., which receives the screen ID as context. This primary column is also where row actions are placed.
For example, if you’ve added a column for a slide image to a slide custom post type WordPress can hold and display many different types of content. A single item of such a content is generally called a post, although post is also a specific post type. Custom Post Types gives your site the ability to have templated posts, to simplify the concept. and would like for it to be the primary, it is now a matter of a simple filter. Previously, you would have needed to recreate the row actions in PHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher and add custom CSS to ensure it did not disappear on smaller screens. As of 4.3, your code might look like:
function wpdocs_slide_list_table_primary_column( $column, $screen ) {
if ( 'edit-slide' === $screen ) {
$column = 'slide';
}
return $column;
}
add_filter( 'list_table_primary_column', 'wpdocs_slide_list_table_primary_column', 10, 2 );
Note that primary columns should typically be the first column after the checkbox. From a user perspective, it is best to keep the placement of the most important identifier of an item and its actions consistent. Specifying other primary columns will work, but may result in some visual breakage in the small responsive view when a row is toggled open. We are tracking how that may be handled on #33308.
Easier subclassing of WP_List_Table and other list tables
While WP_List_Table was designed for internal usage and didn’t make many considerations for custom subclasses, we recognize that developers use them and that clean up would benefit both implementations and future maintenance. The internal WP_List_Table classes now all call ->single_row_columns() in ->single_row() properly, which makes subclassing them significantly easier. Previously, ->single_row() in each WP_List_Table subclass contained a giant switch statement. In most cases, this was unnecessary. By calling ->single_row_columns() when rendering a row, the class will look for a method on the class inheritance chain called ->column_{$name}. This allows us to break up the columns into discrete methods, and removes the need to override ->single_row_columns(). Thusly, if you subclass a List Table like WP_Posts_List_Table, you can override a specific column just by overriding the column method, i.e: ->column_title().
Before: https://github.com/WordPress/WordPress/blob/4.2-branch/wp-admin/includes/class-wp-posts-list-table.php#L635
After: https://github.com/WordPress/WordPress/blob/master/wp-admin/includes/class-wp-posts-list-table.php#L997
#4-3, #dev-notes, #list-tables
You must be logged in to post a comment.