Problem/Motivation

When trying to set part of an overridden display's configuration, the user ends up with broken configuration.

Steps to reproduce:

  1. Create a view with a display (A) with overridden filters
  2. Save
  3. Edit the view to make A's filters the default filters, e.g. via "Rearrange filters" dialog (ie on the Rearrange Filters dialog, select 'All Displays' in the For option.)
  4. Notice that A's filters have changed, instead of the default display's

Expected result:
Display A's filters are set as default. Display A no longer uses overridden filters.

Actual result:
Display A uses the filters of the default display. Display A no longer uses overridden filters.

This means, that upon saving the view, A's filters are lost irreversibly.
If both the default and the overridden display used filters of the same names, this will be hard to spot and lead to confusion and possibly errors later on, as filter values are changed behind the scenes. If A used additional filters, these will all be changed to "Broken handler".

The "Use as default" behavior effectively duplicates the "Revert to default" behavior, with the added bonus of unexpectedly altering the view. This broken behavior has been around for quite a while, and also happened in D7 (see https://www.drupal.org/node/2313791).

Proposed resolution

Upon closer inspection, it seems that views_ui never actually passes the display's configuration to the default display, even though the code comments state it does. So we have to properly implement this de-override behavior.

Remaining tasks

Write tests to reproduce, review suggested patch.

CommentFileSizeAuthor
#2 views-apply_as_default-2313791.patch984 bytesckaotik
Support from Acquia helps fund testing for Drupal Acquia logo

Comments

ckaotik created an issue. See original summary.

ckaotik’s picture

ckaotik
Primary language German
Location Berlin
CreditAttribution: ckaotik at werk21 commented
Assigned: ckaotik » Unassigned
Status: Active » Needs review
FileSize
views-apply_as_default-2313791.patch984 bytes

Please review the attached patch.

NickDickinsonWilde’s picture

NickDickinsonWilde
He/Him/His
Primary language English
Location Victoria, BC (T'So-uke lands)
CreditAttribution: NickDickinsonWilde at BriarMoon Design commented
Version: 8.3.x-dev » 8.4.x-dev
Issue summary: View changes
Status: Needs review » Reviewed & tested by the community

Confirmed the current behaviour and that the patch fixes it.
Marking as RTBC although there is a chance it should have a test as well.
Also, retargeting to 8.4.x

catch’s picture

catch
he/him
Primary language English
CreditAttribution: catch at Third and Grove commented
Status: Reviewed & tested by the community » Needs work
Issue tags: +Needs tests

Yes this should have automated test coverage, CNW for that.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.4 was released on January 3, 2018 and is the final full bugfix release for the Drupal 8.4.x series. Drupal 8.4.x will not receive any further development aside from critical and security fixes. Sites should prepare to update to 8.5.0 on March 7, 2018. (Drupal 8.5.0-alpha1 is available for testing.)

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

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.6 was released on August 1, 2018 and is the final bugfix release for the Drupal 8.5.x series. Drupal 8.5.x will not receive any further development aside from security fixes. Sites should prepare to update to 8.6.0 on September 5, 2018. (Drupal 8.6.0-rc1 is available for testing.)

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

John Pitcairn’s picture

John Pitcairn CreditAttribution: John Pitcairn commented
Version: 8.6.x-dev » 8.8.x-dev

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

Drupal 8.8.0-alpha1 will be released the week of October 14th, 2019, which means new developments and disruptive changes should now be targeted against the 8.9.x-dev branch. (Any changes to 8.9.x will also be committed to 9.0.x in preparation for Drupal 9’s release, but some changes like significant feature additions will be deferred to 9.1.x.). For more information see the Drupal 8 and 9 minor version schedule and the Allowed changes during the Drupal 8 and 9 release cycles.

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

Drupal 8.9.0-beta1 was released on March 20, 2020. 8.9.x is the final, long-term support (LTS) minor release of Drupal 8, which means new developments and disruptive changes should now 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.

arx-e’s picture

arx-e CreditAttribution: arx-e commented

I used this patch on a 8.9.2 Drupal installation in order to make the settings of a view display become the default for all displays and it worked fine.
It would be nice to have it committed.

Version: 9.1.x-dev » 9.2.x-dev

Drupal 9.1.0-alpha1 will be released the week of October 19, 2020, which means new developments and disruptive changes should now be targeted for the 9.2.x-dev branch. For more information see the Drupal 9 minor version schedule and the Allowed changes during the Drupal 9 release cycle.

Version: 9.2.x-dev » 9.3.x-dev

Drupal 9.2.0-alpha1 will be released the week of May 3, 2021, which means new developments and disruptive changes should now be targeted for the 9.3.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.3.x-dev » 9.4.x-dev

Drupal 9.3.0-rc1 was released on November 26, 2021, which means new developments and disruptive changes should now be targeted for the 9.4.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 9.4.x-dev » 9.5.x-dev

Drupal 9.4.0-alpha1 was released on May 6, 2022, which means new developments and disruptive changes should now be targeted for the 9.5.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

quietone’s picture

quietone CreditAttribution: quietone commented
Issue tags: +Bug Smash Initiative

I tested this on a currently supported version of Drupal and was able to reproduce the problem. This still needs a test. The Issue Summary is complete, thanks @ckaotik!

Lendude’s picture

Lendude
Primary language Dutch
Location Amsterdam
CreditAttribution: Lendude at iO commented

To me, the main problem here is that the label 'All displays' hides a lot of what is actually going on.

With this patch, the change you are making is indeed propagated to the default display, but so are all the other changes to those handlers.

Example:
* Add a second display to the content View
* Override the field settings for the title to change the label to 'Title page 2' for the new display only
* Now rearrange the fields to move title to the end and chose 'All displays'

So as a user I would expect ONLY the current action (rearranging the field order) to be propagated to all displays. That doesn't happen (and would be REALLY hard to do if for example this display has added or removed fields compared to other displays).

Without the patch, the current action is propagated to the default display and all other settings revert back to using the default display settings (ie the label change is completely lost).

With the patch, the current action is propagated to the default display and all other settings of the default display are set to what the new display had (ie. the default display now has the label 'Title page 2').

In my eyes, neither one is what you would expect, but the current behaviour is less disruptive if you have many displays.

So I think the drop down should say 'Apply change to the default display and revert this display too using the default display settings' and not 'All displays', but that might be a little verbose....

Version: 9.5.x-dev » 10.1.x-dev

Drupal 9.5.0-beta2 and Drupal 10.0.0-beta2 were released on September 29, 2022, which means new developments and disruptive changes should now be targeted for the 10.1.x-dev branch. For more information see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

Version: 10.1.x-dev » 11.x-dev

Drupal core is moving towards using a “main” branch. As an interim step, a new 11.x branch has been opened, as Drupal.org infrastructure cannot currently fully support a branch named main. New developments and disruptive changes should now be targeted for the 11.x branch, which currently accepts only minor-version allowed changes. For more information, see the Drupal core minor version schedule and the Allowed changes during the Drupal core release cycle.

oana.hulpoi’s picture

oana.hulpoi CreditAttribution: oana.hulpoi as a volunteer commented

I confirm that this patch fixes the issue on Drupal 9.5.9.