Content overview page: make Author column sortable by default on new installations

Given the extent of my issue update in #27 and the fact that it was over seven years ago, this issue probably isn't a good novice contribution candidate. Thanks!

Rolled into an MR.

I think the decision on whether this makes sense is valid when sites implement hook_user_format_name_alter, however those sites could simply turn it off?

I don't think we need tests here as we're just toggling on sorting - this should be tested elsewhere.

I don't think we need profiling here as the db query is simple.

Seems pretty straight forward.

This is the only column in that view that's not on the node base table, and given there can be filters on published status etc., it seems quite possible we could end up with a temporary table and filesort on the query that there otherwise wouldn't be when it has to filter on one table and sort on another, so I think this does need an EXPLAIN per #27.

Agreed it doesn't need automated tests though, views should cover this in its own test coverage.

May be the right status?

Here's the explain on the query from loading the view and clicking the tablesort.

MySQL [local]> explain SELECT node_field_data.nid AS nid, users_field_data_node_field_data.uid AS users_field_data_node_field_data_uid
    -> FROM
    -> node_field_data node_field_data
    -> INNER JOIN users_field_data users_field_data_node_field_data ON node_field_data.uid = users_field_data_node_field_data.uid
    -> WHERE (node_field_data.status = 1 OR (node_field_data.uid = 1 AND 1 <> 0 AND 1 = 1) OR 1 = 1)
    -> ORDER BY users_field_data_node_field_data.name ASC
    -> LIMIT 50 OFFSET 0
    -> ;
+----+-------------+----------------------------------+------------+------+----------------------------------------------+---------+---------+---------------------------+------+----------+---------------------------------+
| id | select_type | table                            | partitions | type | possible_keys                                | key     | key_len | ref                       | rows | filtered | Extra                           |
+----+-------------+----------------------------------+------------+------+----------------------------------------------+---------+---------+---------------------------+------+----------+---------------------------------+
|  1 | SIMPLE      | node_field_data                  | NULL       | ALL  | node_field__uid__target_id                   | NULL    | NULL    | NULL                      |    1 |   100.00 | Using temporary; Using filesort |
|  1 | SIMPLE      | users_field_data_node_field_data | NULL       | ref  | PRIMARY,user__id__default_langcode__langcode | PRIMARY | 4       | local.node_field_data.uid |    1 |   100.00 | NULL                            |
+----+-------------+----------------------------------+------------+------+----------------------------------------------+---------+---------+---------------------------+------+----------+---------------------------------+
2 rows in set, 1 warning (0.000 sec)

So yeah we're using temp tables.

Setting to PMNMI for the decision on whether we want to do this. Personally I'm happy to close.