Alternate views for WP List Tables

[joedolson]

Currently, the WP List Table supports two views: default and "excerpts". This distinction is confusing and doesn't easily allow for other differences between the two views.

As a way to create more flexibility in WP List Tables, we'd like to implement mechanisms for users to choose different views, similar to what's found in Gmail, e.g.: Compact, Default, Comfortable.

This would give us a lot more flexibility in being able to resolve issues where conflicts arise between design, space, and accessibility, because we could offer views where everything is spelled out in a spacious way and also views where information is more compact. As long as the user is able to choose a persistent view that gives them all the information they need, the alternate views can use designs that disclose less detail.

Example tickets that would be impacted include:

#48751
#32170
#35391

[audrasjb]

First pass: Allow user to switch between Compact (default) and Extended modes for posts types list tables

[audrasjb]

49715.diff – "extended" mode displays excerpt (proposal) and row actions (not hidden for better accessibility)

[audrasjb]

49715.diff is a first pass:

• it replaces default list mode with compact mode. I didn't change list value for better backward compatibility, so it's only a wording change.
• it replaces optional excerpt mode with extended mode. I added some code to handle user settings migration.
• when selected, extended mode displays post excerpt (it's a proposal, I'm not sure we want to display excerpts at all) and row actions (not hidden for better accessibility).

Todo:

• Same for taxonomy terms
• Same for users
• Same for media
• Check multisite/network related screens

[audrasjb]

Add compact/extended view support for comments

[audrasjb]

Provide alternate table views (compact/extended) for Posts, users, media and comments screens

[audrasjb]

49715.2.diff provides alternate table views (compact/extended) for Posts, users, media and comments screens.

Former list (default) and excerpt views are replaced with compact (by default) and extended views. Users can switch from one view to another using screen options.

[audrasjb]

Note: we still need to add multisite support, but I'd like to get a review of the current workaround before moving forward on this :)

[afercia]

Thanks @audrasjb for the patches! Looking into 49715.2.diff​ I noticed a few things worth discussing in the next weekly accessibility meeting:

• Related to #48751, my understanding is that the proposal was to make the "row actions" visible by default. Instead, with this patch they're visible in the non-default view.
• I see the same user setting is used for all the various tables e.g. Posts, Comments, Users. What is users want to set a different view for each table? Should a specific user setting be provided for each table?
• Minor: there are a few PHPCS issues to fix, mainly related to alignments.

Provide alternate table views (compact/extended) for Posts, users, media and comments screens

I can't see changes in the media table :)

[afercia]

One more thing: worth considering to make these table views useful for plugins and expose a CSS class on the table element. Something like table-view-{mode} may work.

For the future, maybe consider to add a filter to extend / manipulate the modes.

[audrasjb]

Add table-view-* classes and fix few WPCS issues. Also refreshes the previous patch

[audrasjb]

Thanks for the review @afercia.

Related to #48751, my understanding is that the proposal was to make the "row actions" visible by default. Instead, with this patch they're visible in the non-default view.

Hum. I… I think it would be easier to address this in a specific ticket :D
That should be discussed in our next meeting.

---

I see the same user setting is used for all the various tables e.g. Posts, Comments, Users. What is users want to set a different view for each table? Should a specific user setting be provided for each table?

Good point. While I'm personnaly in favor of keeping on setting for the whole interface (excluding media screen, see my answer below), that should be discussed in our next meeting.

---

Minor: there are a few PHPCS issues to fix, mainly related to alignments.

I spotted and fixed some of them in the last patch.

---

I can't see changes in the media table :)

Yeah, we already have two modes: grid and list view :)

---

One more thing: worth considering to make these table views useful for plugins and expose a CSS class on the table element. Something like table-view-{mode} may work.

Done in the last patch!

[joedolson]

The end goal for this was originally to have 3 views, but it's a great starting point to use the two existing views & re-envision how they're used.

After discussing this in the accessibility meeting today, here's where we'd like to go next:

1) Re-model the view selection mechanism so that it can be extended. This is both so that we can add a 3rd view (probably a low-density view) in 5.6, but also so that the choices of table views can be extended by plugins that want to add or replace existing views.

2) Make the views configurable on a per-table basis. Probably also considering that the default view should be filterable, again so that plugins can default to their custom views.

3) Add a global default for user's to set their preferred view. This global default should probably support a distinction between public and private views. E.g., a plug-in can override the default for their own tables if it's a private view, and that view won't be shown in the global settings. But other views can be added that are globally available for selection. (Note: it may be possible to consider the media views as a private view in this context? Not sure.)

We're not going to aim for adding the 3rd view at this time, instead focusing on extensibility.

[audrasjb]

Add extensibility via filters and action hooks

[audrasjb]

49715.4.diff is a first workaround to add extensibility (action and filter hooks) to the feature. I'll test it intensively tomorrow to see if it's good enough.

[afercia]

Testing 49715.4.diff​ it should be rebuilt on top of current trunk.

The patch is still based on a previous codebase. For example: we recently removed the abbr for the extended date but this patch restores a parameter $h_time that was removed. This also triggers a PHP notice:

Notice: Undefined variable: h_time in /srv/www/wordpress-develop/public_html/build/wp-admin/includes/class-wp-posts-list-table.php on line 1144.

Also, the patch removes a @since notation from the post_date_column_time filter docblock that should be kept.

[audrasjb]

Introduce extensibility to posts and comments list table views, for accessibility purposes

[audrasjb]

@afercia patch refreshed.

[audrasjb]

Introduce extensibility to posts and comments list table views, for accessibility purposes

[whyisjake]

Looks great, y'all. Committing.

[whyisjake]

In 48398:

Administration: Introduce extensibility to posts and comments list table views, for accessibility purposes.

At default, expands the excerpt view to become an extended view. Includes a new table_view_mode filter to allow further configuration.

Fixes #49715.
Props joedolson, audrasjb, afercia, whyisjake.

[afercia]

Reopening for docs improvements:

the new filter table_view_mode should be documented once in the main instance where it is used and then referenced in the other files by a doc inline comment like:

/** This filter is documented in {file-path-here} */

[Offereins]

Reading the recent changeset I'd like to ask the following:

• Couldn't $mode_class = 'extended' === $mode ? 'table-view-extended' : 'table-view-' . $mode; be more like $mode_class = 'table-view-' . $mode; or interpolated as $mode_class = "table-view-{$mode}";?
• For the sake of (future) consistency, should a registration pattern for modes (eg array( key => label )) not be better suited? The new hooks (looking at wp_table_view_modes) provide a lot of room for deviations in HTML markup. Might I suggest to use a filterable list of modes, which would allow for removing and reordering modes, as well as a consistent output of HTML markup handled by core.
• Also, why is renaming the excerpt mode key not expected to affect backwards compatibility?

[afercia]

Additionally, I think it would be nice to immediately show the changes when selecting the radio buttons in the Screen Options. For example, in the Posts page:

• select "Extended View"
• the "row actions" in the table should become visible
• select "Compact View"
• the "row actions" in the table should become not visible

[SergeyBiryukov]

In 48423:

Administration: Make some adjustments to WP_Screen::render_view_mode():

• Restore the $mode global for backward compatibility.
• Remove redundant check, as $mode is already set at this point, and already defaults to list via get_user_setting()'s second argument.
• Use sentence case for "View mode" and "Extended view" labels.

Follow-up to [48398].

See #49715.

[SergeyBiryukov]

In 48424:

Administration: Bring some consistency to handling list table view modes.

• Remove duplicate variables and DocBlocks.
• Add missing description for the $mode global.
• Use sentence case for "Compact view" and "Extended view" labels.

Follow-up to [48398], [48423].

Props afercia, Offereins, SergeyBiryukov.
See #49715.

[SergeyBiryukov]

It's not quite clear why the table_view_mode filter is only applied in:

• WP_Screen::render_view_mode()
• WP_List_Table::get_table_classes()
• WP_Posts_List_Table::get_table_classes()

but not in other places whether the mode is referenced.

Is that enough for the mode switching to work as expected on all affected tables? Is there enough context for the filter?

I also agree with comment:30 that the wp_table_view_modes name might be better suited for a filterable list of modes, rather than an action that fires after the core's default modes.

[Offereins]

@SergeyBiryukov If I'm reading [48424] correctly, renaming of the excerpt mode is now only undone in WP_MS_Users_List_Table but not in WP_Posts_List_Table.

Also, the $mode = apply_filters( 'table_view_mode', $mode ); part is now kept in the get_table_classes() method. Perhaps the filter is better applied where $mode is defined when the user setting is fetched in the prepare_items() method.

[SergeyBiryukov]

Replying to Offereins:

@SergeyBiryukov If I'm reading [48424] correctly, renaming of the excerpt mode is now only undone in WP_MS_Users_List_Table but not in WP_Posts_List_Table.

Just to clarify, [48424] didn't touch any of the renaming parts, it only moved that code block higher up for consistency with WP_MS_Sites_List_Table.

Good catch though, there are still some references to the old excerpt key, specifically:

• In wp_ajax_inline_save().
• In WP_MS_Sites_List_Table::prepare_items().
• In WP_MS_Users_List_Table::prepare_items().

Either these all should be updated to use new extended mode, or all the other instances should be reverted back to the excerpt mode for backward compatibility.

Also, the $mode = apply_filters( 'table_view_mode', $mode ); part is now kept in the get_table_classes() method. Perhaps the filter is better applied where $mode is defined when the user setting is fetched in the prepare_items() method.

Yes, it would also be a good idea to better document the purpose of the filter. At the moment, it's not quite clear whether it just allows to choose between list and extended, or also allows for specifying any custom type. Apparently the former is the case.

[SergeyBiryukov]

In 48450:

Administration: Restore the excerpt key for the Extended view mode for backward compatibility for now.

Props Offereins.
See #49715.

[SergeyBiryukov]

I think this would benefit from a dedicated WP_List_Table class property and method for setting the mode, instead of relying on the $mode global and doing things a bit differently in each class.

Additionally, there seems to be some overlap between WP_List_Table::view_switcher() and WP_Screen::render_view_mode(), might be a good idea to review them closer.

[desrosj]

This one is running out of time (beta 3 is in a few hours and RC1 is in one week).

Is someone able to create a patch for the changes mentioned in comment:39? If that cannot happen in time, would a revert of any of the changesets on this ticket be required?

[davidbaumwald]

With the new filters, this deserves a call out on the Misc Dev Note.

[audrasjb]

Reverts table_view_mode filter introduction as per discussion that happened in ticket #49715

[SergeyBiryukov]

In 48668:

Administration: Pull the table_view_mode filter for now.

The extensibility of list table view modes will be explored in a future release.

Props audrasjb.
See #49715.

[SergeyBiryukov]

In 48670:

Administration: Don't override the $mode global in WP_Screen::render_view_mode() if it's already set.

Follow-up to [48398], [48423], [48424], [48450].

See #49715.

[ryelle]

Row actions on other posts hide when any post gets focus

[ryelle]

I noticed that after r48398 the row actions are visible on excerpts, as expected, but as soon as you focus into a post it hides all the rest of the actions. This is noticeable on click, like in the gif screencap above, but also happens when tabbing through the list table.

I think 49715.3.diff​ should fix the issue, by only toggling the row action visibility on "compact view".

[alexmustin]

My apologies in advance if this is not helpful.

I am also noticing an issue with the row-actions divs being visible on every page load. Seeing every option of every post all the time is visually overwhelming.

An issue I'm seeing with this, as noted by @ryelle above, is when I right-click on one of these actions, it causes all the other row-actions to go invisible.

[hellofromTonya]

Accessibility team decided to punt this ticket in today's scrub.

Per @afercia

punting both tickets to give this feature the chance to be in a better shape

[SergeyBiryukov]

In 49142:

Administration: Make sure list table row actions in Extended view stay visible when a single row gets focus.

Follow-up to [48398], [48423], [48424], [48450], [48670].

Props ryelle.
Fixes #51516. See #49715.

[SergeyBiryukov]

In 49725:

Administration: Make sure row actions for recent comments in Activity dashboard widget stay visible when a single row gets focus.

Follow-up to [49142].

Props sabernhardt, kebbet, hareesh-pillai, pbiron.
Fixes #51886. See #51516, #49715.

[SergeyBiryukov]

In 49727:

Administration: Make sure row actions for recent comments in Activity dashboard widget stay visible when a single row gets focus.

Follow-up to [49142].

Props sabernhardt, kebbet, hareesh-pillai, pbiron.
Reviewed by ryelle, SergeyBiryukov.
Merges [49725] to the 5.6 branch.
Fixes #51886. See #51516, #49715.