Allow style plugins to specify to which pane types they may be applied.

I successfully tested the D7 patch: https://www.drupal.org/files/issues/panels-style-plugin-types-1249340-1-...

Here's how:

• Applied the patch to panels-7.x-3.x-dev
• Created a custom module with a style plugin
• Enabled the custom module
• Used Panelizer to customize content for the Article content type
• Added several types of panes
• Reviewed the list of style plugins for each pane to confirm when my style plugin displayed

I tried several types of panes including 'block', 'entity_field' and 'views'. Here's an example of my plugin to work with a menu placed as a block. The 'block' content type is what is offered when adding a menu straight from Core as a pane.

$plugin = array(
  'title' => t('Mymod style: test plugin'),
  'content type' => array('views'),
  'description' => t('Alters the display of a view to display in a special way.'),
  'render pane' => 'mymod_panel_test_style_render_pane',
  'hook theme' => array(
    'mymod_panel_test_style_pane' => array(
      'template' => 'mymod-panel-test-style-pane',
      'path' => drupal_get_path('module', 'mymod') . '/plugins/styles/mymod_panel_test_style',
      'variables' => array(
        'content' => NULL,
        'settings' => NULL,
      ),
    ),
  ),
);

This worked so that when I placed a View pane, then my style plugin was available when setting a style. Other types of panes like 'block' and 'entity_field' did not include my plugin in the list of style plugins available.

I have not tested the D8 patch.

I have successfully tested the D7 patch. I believe that it should be committed.

In my use case, I have styles that require being filtered more specifically than type. i.e. instead of a style being restricted to all mini panels, it needs to be restricted to specific mini panels. This patch could easily be extended to include the existing panel property of 'subtype' in the exact same way.

Attached is a D7 patch extending the existing patch slightly to include subtype as well as type.

Sample usage:

$plugin = array(
      'title' => t('My footer style plugin'),
      'sub type' => array('default_footer', 'alternate_footer'),
      'description' => t('For styling menus.'),
      'render pane' => 'my_menu_render_pane',
      'pane settings form' => 'my_menu_settings_form',
      'hook theme' => array(
        'my_menu_pane' => array(
          'template' => 'my-menu',
          'path' => drupal_get_path('module', 'mymodule') . '/plugins/styles/my_menu',
          'variables' => array(
            'content' => NULL,
            'settings' => NULL,
          ),
        ),
      ),
    );

Note: I believe that this patch, which includes type and subtype, should be included. But even if this patch is not included, I vote to include the previously submitted patches.

Thank you ashrafabed. Your patch works great! Sub-type support is essential in our project.

+++ b/plugins/display_renderers/panels_renderer_editor.class.php
@@ -1640,9 +1640,23 @@ function panels_edit_style_type_form($form, &$form_state) {
     if (empty($info['hidden']) && (!empty($info[$function]) || $id == 'default')) {
...
+      // If a content type has been defined for this plugin, only make it
...
+      if ((!isset($info['content type'])
...
+        if ((!isset($info['sub type'])

Only nitpick is possibly changing key to "content types" and "sub types". Also, what if the content types and sub types were defined like the following:

<?php
$plugin = array(
  'title' => t('Floating'),
  'description' => t('Pulls pane upward.'),
  'content types' => array(
    // Specific content types
    'views_panes' => array(
      // Specific subtypes
      'events-views_events',
    )
  ),
  'render pane' => 'MODULE_floating_style_render_pane',
  'pane settings form' => 'MODULE_floating_settings_form',
  'category' => t('MODULE'),
);
?>

Either way, it works as is. Makes me happy. Will definitely improve our customer user experience by providing useful pane styles targeted at specific elements.

I've updated the variables. I think this is the right patch to commit but want a second glance at it.

Hiding the D8 patches. They won't ever be relevant to d8 as panels is totally re-written.

Too bad there's nowhere to document to list this new attribute :-\

I renamed the first variable to 'content types' because the other Panels/CTools plugin attributes use spaces instead of underscores.

@Damien i think you attached some other permission related patch from #1699432

Whoops! X-)

Leaving this up to japerry to decide what approach to use.

Is this pushed to Panels 3.6? Or 3.5.1?

Seeing as how this is still an open issue, the answer is "neither" :)

This didn't get into 3.5 so lets bump it to 3.6.

Anyone care to give it a good review and push it to RTBC?

This was not added to 3.6 after all. Taking it off the schedule until japerry gets to review it or someone RTBC's it.

Drupal 7 is no longer supported, closing.