Posted by merlinofchaos on December 13, 2007 at 8:09pm
Last updated by joachim on Fri, 2008-11-21 10:40
Last updated by joachim on Fri, 2008-11-21 10:40
This WIKI is currently a placeholder for Panels 2 API documentation.
proviso: schuyler1d is just putting some documentation here while I peruse the code. It could be all wrong.
Terminology
- $display
- The panel rendered.
-
$display->layout $display->args $display->incoming_content $display->context $display->css_id $display->did #display id, starts out as 'new'
- $layout
- $pane
- $context
Public Hooks
- hook_panels_pre_render($display) [panels.module]
- prepend header-like content to the displayed panel
- hook_panels_post_render($display)
- footer to the displayed panel
- hook_panels_pane_content_alter($content, $pane, $args, $context) [includes/plugins.inc]
- hook_panels_include_directory($plugintype)
-
* Hook allowing other modules to create their own panels .inc files, * and have them available in panels without needing to add files to the * Panels include directories. See API.txt for details. * * PLEASE NOTE: There are strict naming conventions on implementing this hook; failure to * follow the conventions will likely cause your plugins not to work. Possibly even worse, * failure to follow the conventions can result in namespace collisions between your * module and other modules invoking the panels API. * * @param string $plugintype * The type of Panels plugin being requested. Can be any of the following seven: * 'content_types', 'contexts', 'arguments', 'layouts', 'styles', 'relationships' * * @return array $directories * Returns an array of include subdirectories to call for the requested plugin type. * Subdirectories should be ONLY the subdirectory of your module where the appropriate * types of .inc files reside.
- hook_panels_exportables($op, $panels, $name) [panels_export/panels_export.module]
-
@param string $op either 'list' or 'export' @param array $panels ?which panels to export @param string $name ?the name of the pane?
- hook_default_panel_minis() [panels_mini/panels_mini.module]
- hook_default_panel_pages() [panels_page/panels_page.module]
- hook_default_panel_views() [panels_views/panels_views.module]
- hook_panels_style_info()
- Defines custom panel styles, thus:
function panels_default_panels_styles() {
return array(
<style machine name> => array(
'title' => t('Style name'),
'description' => t('Style description.'),
'render panel' => '<style machine name>_render_panel',
),
);
Your module should then define theme__render_panel() to theme the panel.
Comments
hook_panels_pane_content_alter : possible mistake ?
I wonder about this few lines of code in includs/plugins.inc :
line 511:
if (empty($pane->cache['method'])) {
$content = panels_ct_get_content($pane->type, $pane->configuration, $args, $context, $incoming_content);
foreach (module_implements('panels_pane_content_alter') as $module) {
$function = $module . 'panels_pane_content_alter';
$function($content, $pane, $args, $context);
}
}
I think a '_' is missing between the $module avec 'panels_pane_content_alter', otherwise, I can't see how this could work.
Since I am not familiar with the contribution process, if someone coudl eventually fix this.
I am using this hook since I have developed a custom content_type, and I would like to alter visibility calculations depending on its belonging/or not to a mini-panel.
Thanks
Kha
That's definitely a bug.
That's definitely a bug. Nice catch, thanks! The normal contribution process is to report that bug here, including a patch generated per these standards if you're able.
If you're talking about extending the current implementation of the pane visibility system to be more broadly usable, though, then just an fyi - I'm hoping to devise a way to make it easier to apply visibility callbacks across an entire set of displays, without having to specify them explicitly in their content type definitions. It probably won't be around for a little while, so the hook you're invoking is likely the best way to go atm. But at some point it'll be there :)