Responsive field classes via table settings don't work for all views of existing sites

[olafgrabienski]

Description of the issue

This is a follow-up to issue #3656. @yorkshire-pudding mentioned in a comment that the new UI setting "is not working with Medium priority". Others weren't able to reproduce the issue at that time, and the PR was merged.

When I tested the 1.34 preview release today, I was able to reproduce the issue with Medium priority at the admin/content view.

edit: I noticed the issue on a site which was updated from a previous Backdrop version.

Steps to reproduce:

• Go to the view, set the Responsive Priority for the Name column to Medium and save the view.
• Go to admin/content, and narrow the screen.

Actual behavior:

• At 720px and below, the Name <th> disappears. The corresponding <td> element with the Name values remains.
• The <td> with the Name values disappears only at 450px and below.

Expected behavior:
Both elements should disappear in the same situation, which should be at 450px and below.

Additional information

When you look at the rendered HTML, note that the <th> element has not only the "priority-medium" class but also "priority-low":

<th class="priority-low priority-medium" ...>
(...)
<td class="priority-medium">

[olafgrabienski]

Somehow related but probably another issue: It was confusing to see that all Responsive Priorities in the table settings of the admin/content view were set to "High", but in the rendered HTML some columns had other, probably hard-coded priorities.

edit: Also this behavior was noticed on a site updated from a previous Backdrop version.

[herbdool]

I can't recreate it on a fresh install.

If you're doing it on an existing site then you need to remove the old field styles.

Backdrop already had these styles but they were applied manually in the field styles. We left the existing ones on admin content and admin users views.

[olafgrabienski]

If you're doing it on an existing site then you need to remove the old field styles.

Ok, got it after reading the issue again and finding the explanation at #3656 (comment).

So, in my example I had to remove the priority-low class from the Name field (see screenshot below) to make the new setting work.

Is it reasonable to fix the issue by changing those custom classes to table settings in existing views? Or is there a risk to change other custom classes which shouldn't be touched?

As long as we can't fix the issue, let's try to document it, including which fields of the core views have responsive custom classes.

---

Screenshot: the Name field of the admin/content view

[olafgrabienski]

I've changed the issue type to Documentation for the time being. Or should it be a Task?

[avpaderno]

Could not the update hook show a message suggesting checking the already used CSS classes?

[indigoxela]

A quick idea, please ignore if this leads too far.

So these 2 module provided views changed:

• core/modules/node/config/views.view.node_admin_content.json
• core/modules/user/config/views.view.user_admin.json

But ATM admins wouldn't even know, and it's not possible to "reset" them to new defaults, as they're not marked as overridden. What if an update hook does mark them as overridden, so admins could revert them to the (new) defaults via views UI, even if they didn't manually adapt them?

That would be "storage": 2, (see VIEWS_STORAGE_OVERRIDE). Currently it's VIEWS_STORAGE_DEFAULT, which is misleading, as the json differs.

Or does that lead to other problems?

[herbdool]

I put a PR up that took the approach of removing any custom classes of "priority-low", "priority-medium" and moving it to the "responsive" setting per field - only for the user_admin, node_admin_content views. And it preserves any other custom classes. If we do that regardless of whether the views have been overridden or not. I think this will work okay. Please test.

We could also add a message in the update hook so admins can check any other views.