Allow all view modes to be customized

Any view mode that has 'custom settings' allowed should be panelizable. If it doesn't allow custom settings (i.e, field control) then it also won't allow panelization. This is done to prevent panelizing weird view modes such as RSS and other things that exist by default but aren't panelizable.

There is a checkbox (I believe) on node configuration that should make items that are normally not customizable customizable, which should also make them panelizable.

The problem here is that view modes are given a default state for custom_settings, which is what is then being used for building the form. So you can go to Structure -> Content Types -> Display Settings and enable custom display settings for view modes that are by default not custom and Panelizer doesn't recognise that. Based off merlinofchaos' response, I would say this is a bug...

The complication is that the view modes used to build the form are from the entity info and the setting of whether a view mode is custom is per bundle (retrievable from field_view_mode_settings()). To make this work, the view modes will need to be moved into the bundle settings, rather than being based off of the entity:

panelizer.module::478

    if (!empty($entity_info['view modes'])) {
      foreach ($entity_info['view modes'] as $view_mode => $view_mode_info) {
        if (!empty($view_mode_info['custom settings'])) {
          $plugin['view modes'][$view_mode] = $view_mode_info;
        }
      }
    }

plugins/entity/entity/PanelizerEntityDefault.class.php::1902

      foreach ($this->plugin['view modes'] as $view_mode => $view_mode_info) {
        ...
      }

Before I realised the form/plugin settings were per entity rather than bundle, I was going to write a patch that fixed it by including the view mode settings when processing the plugin similar to how Field UI does:

modules/field_ui/field_ui.admin.inc::1181

    $view_modes = $entity_info['view modes'];
    $view_mode_settings = field_view_mode_settings($entity_type, $bundle);
    foreach ($view_modes as $view_mode_name => $view_mode_info) {
      $options[$view_mode_name] = $view_mode_info['label'];
      if (!empty($view_mode_settings[$view_mode_name]['custom_settings'])) {
        $default[] = $view_mode_name;
      }
    }

However, it's going to take a bit more than that as will need to re-work the view modes into the bundle settings of the plugin. I'm happy to give this a go, but I wont be able to do it immediately, so if someone else has the time, hopefully the info above will help make it easier... Assuming I'm right!

Ok, here is a go at a patch.

• In panelizer_entity_plugin_process(), I have removed the check to see whether $entity_info['view modes'][$view_mode]['custom settings'] is set, as this only checks the defaults, not the actual stored settings.
• In panelizer_entity_plugin_process(), I have added in a check for the per bundle settings which creates a custom flag in the settings array.
• In PanelizerEntityDefault::settings_form(), I have added a check for the custom flag, which if FALSE we continue and don't create the row.

There may be a better way to do this or a way that fits better with the rest of the architecture. One issue is that settings would be lost when you save the page without the custom setting...

The one bit I couldn't figure out was where the decision is made as to whether the Panelizer is used to render or not... Can't see if that is dealt with internally or if it checks settings elsewhere...

In a view mode, it chooses to render with panelizer using hook_entity_view_alter. This code shouldn't affect that, I don't think. It should only care if it is actually set to be panelized and has a panelizer object attached, which should already have made appropriate checks to even get to that point.

I reworked it a bit to pull the view mode settings out of settings (so they don't get overwritten). There was also an important part that was missed, making it possible to panelize all view modes in the 'panelize' vertical tab on bundle edit page, so I added this. Attached patch is what i committed and pushed.

Excellent! Thanks!

I've already noticed one problem with this that I had to commit a followup on, where the code in hook_entity_view_alter relied on the presence/absence of $handler->plugin['view modes'] to determine if it should use the 'default' view mode or the actual view mode being used.

While I can't remember any other instances of things like that, it would be good to have some manual testing and some code review (perhaps doing a search for where the view modes are referenced).

And now that there are TWO checks to see if a view mode is customizable, that check should probably be genericized into a function because it's a somewhat annoying check in terms of logic and woudl be much more readable if it were something like just a method on the object to determine if the view mode can be panelized at all.