Improve usability when overriding Views style options and row style options and pager options

It is a regression.

The patch fixes the bug for me. It applies cleanly on 8.1.x too.

I'm updating the title and priority of this in the hope of getting some more eyes on this issue. I consider it to be a reasonably serious bug as it makes it impossible to have different style options for different displays in a view.

Example using Style options

1. Create a view with two displays showing rows as Fields.
2. In the first display set a grouping field in Format: settings.
3. The second display will also be given the same grouping field.

Example using Row style options

1. Create a view with two Page displays showing rows as Content. By default each display will have View mode set to Teaser.
2. In the first display change View mode to Default
3. The second display's View mode will also be changed to Default

The patch in #9 fixes the bug but it causes a number of test failures relating to the views module config schema. It looks like the 'style_options' and 'row_options' sections added by the patch need corresponding settings in /core/modules/views/config/schema/views.data_types.schema.yml. I have tried out a few things in views.data_types.schema.yml but I don't really know what I'm doing. Hopefully someone else will take a look.

After applying the patch in #9, I made two changes to /core/modules/views/config/schema/views.data_types.schema.yml to replace [%parent.type] in lines 92 and 101 with [plugin_id]. This seems to be working, but I have never submitted a patch, am hesitant to try one against a core module, and so don't know what tests it might fail.

@DSquaredB, I tried your suggestion, but it throws up an error in Drupal\views\Tests\Wizard\BasicTest. If you'd like to try something else it's not necessary to run the entire test suite, which can take forever in a local development environment. You just need to enable the Testing module and run the failing tests, which are:

1. Views.Drupal\views\Tests\Wizard\BasicTest
2. Views.Drupal\views\Tests\Wizard\ItemsPerPageTest
3. Views_ui.Drupal\views_ui\Tests\DisplayTest
4. Views_ui.Drupal\views_ui\Tests\OverrideDisplaysTest
5. Views_ui.Drupal\views_ui\Tests\WizardTest

Revisiting this issue a few months later and with more D8 experience I now see that my original opinion that this is a bug was wrong. You can indeed have different Style and Row style options per display, but the way to do it in D8 is not the same as in D7. In D7 you could override the default settings from both Format: and Format: settings, and from both Show: and Show: settings. In D8 you must override Format: if you want different format settings per display, even if the format of all displays is the same. The same method of overriding display settings is used for other Views settings too, like page access settings and exposed form settings.

While this is a usability issue for people coming from D7, it's not a bug. Usability could be improved by adding some help text on the options forms of non-overridden displays, warning the user that any changes made to the display will apply to all displays that have not overridden the default settings. Changing the category to Task.

As per #17 here's a patch that displays a warning on the Style and Row style options forms.

Fixed failing tests.

I'm moving the patch over from #2824314: List wrapper class shared between view displays which follows the same line as the patches in #9 and earlier. I think not being able to override displays from these modals is a regression and annoying, and there is really no good reason for it not to be possible.

Quoting myself from the other issue:
This was apparently removed in #2331793: Changing pager settings for this display only also changes pager settings for other display but I can't really see how removing it was seen as a valid fix for the described problem. It prevented the problem from manifesting by removing existing (useful) functionality.

So lets get this back in.

#25 applied and works fine.

Tested on 'Table' format settings.

Rerolling patch for compatibility with newer versions.

Once again, since apparently I can't count.

Patch #30 works on 8.7.1

Patch #30 works fine on 8.8.2

Patch from #30 works like a charm for 8.8.2.

Closed a couple of duplicates in favour of this one so adding credit for the other contributors.

Rerolled patch #30 for 9.2.x

Hi,

Creating a patch for solving issue as raised in #41 comment and update deprecated method as assertFieldByName() mentioned in #41 patch.

Please review the patch.

Thanks.

Tested #43 on 9.1, changes are visible
RTBC + 1

Tested #43 on 9.1.3. The option to apply to either an individual view display or all view displays appears at the top. Also seems to work properly on save of the changes as well.

RTBC + 1

#43 tested on core v9.2.10 and works pretty well! RTBC +1

¿Could this patch be included to the development stream of views?

Thanks for the effort.

Rerolled for 9.5

#51 worked good!

If you feel it worked can you post the testing steps you did and move to review tested by community

Self review

This will need an upgrade path for the new configuration for existing sites.

#51 did not work for me on 9.5.9.

I've created a view of a Solr index, a unformatted list of rendered entities. Once i change the view mode on one of them, the other one changes its view mode too.

FYI 11.x is the current development branch so issues will have to be committed there first before it's considered for backport to 9.x

Thanks @smustgrave i didn't know that.

Hey @smustgrave I've updated this issue with a merge request.
To create the merge request I applied https://www.drupal.org/files/issues/2022-07-26/2552541-51.patch to the 11.x branch and then added an update function for updating existing views on sites that were not using this patch.

See https://git.drupalcode.org/project/drupal/-/merge_requests/6706/diffs

The need for a database update is up for debate.

I think this is now ready for review with one outstanding question.

- Is the comment about an upgrade path in #55 valid or not.

There is a new update in the views.install file for review if it is.

Thanks for carrying this forward.

Left a comment on the MR but post_update hooks also requires test coverage. Should be a few examples in the views module that may help.

OK, I've updated the install file update function to use hook_post_update_hook and added a test for the update. https://git.drupalcode.org/project/drupal/-/merge_requests/6706/diffs

NVM tests failed

Amending attribution.

patch from MR for 11.2