Responsive list tables don't handle primary columns that are not the first non-checkbox one

[helen]

In #25408, we introduced the concept of a primary column for list tables, which is where row actions are placed and the column that appears in the small screen responsive view (see #32395). However, due to the way the toggled columns are handled, any non-checkbox columns before the primary one still appear before the primary, which does not look good. See attached screenshot for an example of defining the "name" column for users as the primary instead of username.

[helen]

Realistically, for user consistency, the primary column should be the first non-checkbox one. We don't typically enforce this type of thing in core, but this may be a situation in which we enforce it by default. We would still make it possible to reorder columns if the developer truly wants to, but they would then need to handle it visually. We could also explore ways to handle it visually. I'm inclined to do the former, as I believe we should be more opinionated about smart defaults in APIs that affect UX and more hoop-jumping if you really want to bypass it, but would like some discussion here. The former could also be done in 4.3.

The decision may very well be to just leave it and make a recommendation for the time being, in which case we can punt this from 4.3.

[valendesigns]

The only time I can logically think of that someone should add a column before the primary is if it were an image. In which case it may not actually look terrible and only need a small amount of adjustment.

However, I still would lean towards punting this. Because it doesn't feel like we have enough time to properly mock up the UI and create a well tested patch.

A side note... The backwards compatibility statement in 32722 makes me feel like we should be adding a _doing_it_wrong somewhere in there. Especially if they're setting $_column_headers for horse reasons.

Otherwise, we need to explain what could happen a little bit better in the off chance you've been setting $_column_headers manually and how that choice could break or uglify your responsive list tables.

[azaozz]

The decision may very well be to just leave it and make a recommendation for the time being...

Agreed, also see the above Slack discussion.

[helen]

I lightly researched the reason behind why people directly set $_column_headers and didn't come up with much besides "the Codex and various tutorials say to". It could be leftovers from before, and the idea that it needed to be set was mindlessly repeated, which is common enough.

[wonderboymusic]

I had to create this as an intermediary when subclassing List Tables

namespace NYT;

class ListTable extends \WP_List_Table {
	protected function set_column_headers() {
		$columns = $this->get_columns();
		$hidden = [];
		$sortable = $this->get_sortable_columns();
		$this->_column_headers = [ $columns, $hidden, $sortable ];
	}
}

The reason: those column values are only otherwise available from the WP_Screen object

See, WP_List_Table->get_col_info():

$columns = get_column_headers( $this->screen );
$hidden = get_hidden_columns( $this->screen );

$sortable_columns = $this->get_sortable_columns();

[niknetniko]

(Don't know if this is possible already, didn't find it).

While I agree the order of the columns should stay the same, I do have non-primary columns before the primary one. More specifically, I have an image (like @valendesigns said), but I also have an ID:
I also have a case where I don't have an image, but just the ID.

However, I would still like to set the primary column to the one with the row actions. It would be ideal if I could choose to hide some of the columns before the primary one - in this case I'd hide the ID column, since that isn't vital information.

I don't know if that is possible without too much work, but it would be nice to not have to make my own css rules about it - I'm hoping you consider this as well, as I imagine I'm not the only one displaying an ID like this.

[cklosows]

We just ran into this on Easy Digital Downloads, where as the use case for us is the payments table. The payment IDs are numerically ordered by default, however we were exploring making the mobile view a bit more useful by having some of the other payment data become the primary column when collapsed.

If this feature is possible that'd be fantastic. Just wanted to chime in with our use case.

[helgatheviking]

Just ran into this while working on Charitable. I was trying to put a donation's "status" before the post title, but the table styles go haywire at a mobile view. This is reproducible with regular posts:

function test_filter( $old_columns ){

  $columns = array( 
    'cb' => '<input type="checkbox" />',
    'author' => 'Author',
    'title' => 'Title',
    'categories' => 'Categories',
    'tags' => 'Tags',
    'comments' => '<span class="vers comment-grey-bubble" title="Comments"><span class="screen-reader-text">Comments</span></span>',
    "date" => "Date" );

    return $columns;
}
add_filter( 'manage_edit-post_columns', 'test_filter' );

But if I resize the screen down, I see this messed up table:

The primary column is unchanged. Seems to happen even if JS is disabled too and I can't find the CSS that is responsible for making it behave differently when it isn't the 2nd column.

I would have expected that the primary column is always styled as full width with the "reveal more" button and any other columns remain hidden unless explicitly styled, but that doesn't seem to be the case.