Display type setting doesn't work for overridden views displays

There's some really weird stuff going on here...

I followed your steps, and I'm getting the same result. However, the "Display type override" isn't about changing the view mode - it's about changing the Views row plugin, so the options are like: "Fields", "Content", "Table". I don't think there's a way to remove the ability to change the view mode in configuration - that should always be displayed when the row plugin is "Content" (or internally "node"). Perhaps there should be a way to configure that way similar to the "Display type override" setting? I'd be for that.

But there is a bug here! The setting to change the view mode should actually appear on the configuration form for BOTH of the content panes, because both are using "Content".

Adding some debug statements to the code, I can see that for some reason on "Pane default", the $view_handler->options['row_plugin'] is 'fields' when it should be 'node'. I'm not sure how that could be, because it's definitely rendering as 'node', which is why this is so weird.

Let's keep this issue about fixing that bug! For adding a way to disable changing the view mode, let's make a new issue.

Ultimately, this turned out to be a simple change! Basically, this just has to do with how Views stores options that are from the master display, and we weren't following that, just poking around in the options array. Here's a patch that fixes it in my testing!

1. It looks like you can only override the display type (Fields, Content, or Table) if it's initially set to Fields. Is this intentional?

So, yes, the original intention was to only allow switching the display type on Views that use the 'fields' row plugin. See:

https://www.drupal.org/project/panopoly/issues/1989360#comment-7433098

However, I wonder with this bug if that has been mostly enforced or unenforced in actual usage? :-/ This needs more thinking about, because people might be depending on this. Also, Matt's argument in the above link is right that we can't convert from Content to Fields (because there will be no field definitions) but we should be able to convert from Table to Fields.

2. If the initial display is set to Table, the view mode selection still appears, but does nothing.

I'm also able to reproduce this. It appears that hiding that was relying entirely on Javascript using the value of the display type, but since display type shouldn't be shown in this situation, it's just always showing it. Easy enough to fix.

Geez, I wonder how long these bugs have been in here?

+++ b/panopoly_magic.module
@@ -1118,6 +1118,7 @@ function panopoly_magic_form_views_content_views_panes_content_type_edit_form_al
+    '#access' => $conf['view_settings'] == 'rendered_entity',

Actually, I realized right after posting this, that this isn't right. Hang on...

The boolean logic here is hard to wrap my mind around - I had to break it into a two part if/elsif to make it easier to reason about (and hopefully make it easier to understand later with the help of the comments). In any case, I hope this is right but could certainly use a lot more testing. I'll throw it at the automated tests in a moment.

EDIT: Here's the Travis build: https://travis-ci.org/panopoly/panopoly/builds/566181557

One more note: I looked at allowing Table to be converted to Fields or Content, and it actually doesn't work! The code specifically only supports converting from Fields to Table or Content, so we don't have to worry about that breaking anyone because it would never have worked. :-)

Thanks! Here's a Travis build:

https://travis-ci.org/panopoly/panopoly/builds/580392547

Travis failed because Travis. :-( Here's a new build that should work better:

https://travis-ci.org/panopoly/panopoly/builds/580422992

This fails on Travis :-(

Here's a re-rolled patch (against the profile) after the recent commits. I haven't had a chance to really dig into the failures yet.

Here's a new patch. Part of the test failures was an actual issue in the functional code! That's fixed. There was also some minor issues in the Views export, but nothing that should have broken it. But, for some reason, this test is super unstable locally: one of the tests almost always fails, but each time I run it, it's a different test. :-( I'm not sure if that's some issue with my setup locally, but nothing I tried managed to fix it. So, I'm gonna try on Travis and hope it magically works there. :-)

EDIT: Here's the Travis build: https://travis-ci.org/panopoly/panopoly/builds/581853183

Alright, that found another bug in the actual functional code. Here's a patch that should fix that, which I hope passes against the full test suite.

EDIT: Here's the Travis build: https://travis-ci.org/panopoly/panopoly/builds/582837346

Tests finally pass! Committing :-)