I have a view with two displays (blocks). Some settings are common to both of them, some are specific to the second display. When applying changes I have 3 options
- apply changes to all displays
- apply changes to the current display
- revert to default

Whenever I try to apply changes to all displays while editing the display with overwritten settings, all my overwritten changes are removed, as if I clicked the revert option. I lost an hour worth of work, because I did not notice that and saved my views after the damage was done. Please fix it ASAP.

I'm attaching a recording of the problem, it's in Polish, but you should get the gist of it: I added the Author field to one of my displays, and after that I added Body field to all of them, which deleted the Author field from my custom display. I'm using 8.2.6 version.

CommentFileSizeAuthor
bugged_views.zip1.11 MBPawlus
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Pawlus created an issue. See original summary.

Pawlus’s picture

Component: Views Data » Code
Pawlus’s picture

Project: Views (for Drupal 7) » Drupal core
Version: 8.x-3.x-dev » 8.2.x-dev
Component: Code » views.module
xjm’s picture

Title: Applying changes to all displays after overwriting settings of one of them removes the overwritten changes » Users did not expect applying changes to all displays after overwriting settings of one of them removes the overwritten changes
Priority: Critical » Major
Issue tags: +Usability
Related issues: +#1836392: In the Views UI, the interaction pattern of “All displays”/ “Override this display” is confusing

Hi @Pawlus, thanks for the issue report.

Whenever I try to apply changes to all displays while editing the display with overwritten settings, all my overwritten changes are removed, as if I clicked the revert option.

This actually sounds like how it is supposed to work: for each section of the views UI (fields, filters, etc.), you have the option to either make it the same across all displays, or override it for the particular display. Applying the changes to all displays is intended to remove overrides, so it is not in itself a bug that it does so.

However, I definitely see how this confusing pattern can cause a usability problem, and it is especially problematic when a confusing interface causes work to be lost.

#1836392: In the Views UI, the interaction pattern of “All displays”/ “Override this display” is confusing is one issue where we tried to discuss how to address this usability problem; unfortunately, we did not really come up with a solution that worked well.

If there were a confirmation form when switching from overridden fields back to "all displays", do you think that would have helped prevent the issue where you lost the work?

xjm’s picture

Title: Users did not expect applying changes to all displays after overwriting settings of one of them removes the overwritten changes » Users did not expect applying changes to all displays would remove the overridden settings
xjm’s picture

Also, for what it's worth, I've had experiences similar to yours. Looking back on #1836392: In the Views UI, the interaction pattern of “All displays”/ “Override this display” is confusing , I wrote four years ago:

I'm somewhat tempted to bump this to major; this is my #1 all time pain point with Views. The functionality is useful, but the UX for it is very trying.

So I do agree that this feature for sharing vs. overriding some settings causes problems.

Pawlus’s picture

I'm quite surprised it works that way, because it never occured to me in version 7 - where apparently it works like that too. I could have sworn there used to be option called Apply to all (except overriden). Was I seeing things? Maybe it showed only when editing settings on the existing fields/filters, not adding others? How I expected the option to work is that when you add new field or filter to a display and apply to all, the new field/filter is added to all displays and the overriden setting would remain untouched. Just another field/filter would be added below.

Lendude’s picture

More fun with this, #2856858: Views filter "Revert to default" action does not work from "Add" context.

Not sure this classifies as a bug though, it's confusing, but it works as designed (@xjms original issue was classified as a task).

Version: 8.2.x-dev » 8.9.x-dev

Drupal 8.8.7 was released on June 3, 2020 and is the final full bugfix release for the Drupal 8.8.x series. Branches prior to 8.8.x are not supported, and Drupal 8.8.x will not receive any further development aside from security fixes. Sites should prepare to update to Drupal 8.9.0 or Drupal 9.0.0 for ongoing support.

Bug reports should be targeted against the 8.9.x-dev branch from now on, and new development or disruptive changes should be targeted against the 9.1.x-dev branch. For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

pameeela’s picture

I believe that this problem is captured in #2552541: Improve usability when overriding Views style options and row style options and pager options, which I found when searching for this issue, to close yet another one as a duplicate.

That other issue has more progress and also documents that this does work different in D8 than in D7 so I'm going to close this one. I will add credit to that one for the contributors here.