Themes and modules will check page_manager_get_current_page() to see if Panels is controlling the content. This is done in Panels Mini to load context, Panels Breadcrumb (which has baked in workaround), Kalatheme (which I think borrows its check from Zen.)

The check in question is..

(module_exists('page_manager') && page_manager_get_current_page())

Problem is that page_manager_get_current_page() is called in ctools_context_handler_render_handler() and seems to be the only times it is set. I've tried unraveling the process, but I've gathered that Panelizer routes itself away from how Page Manage typically builds out a page. This essentially breaks a theme's logic if a node/term/entity is Panelized and forces Panels modules to do crazy workarounds.

I haven't dived into the proper steps of writing a patch or where to drop this in, however I took a cue from Panels Breadcrumbs and attacked hook_panelizer_pre_render_alter(). Using page_build() or page_later() (pre/process as well) would reset the page manager current page (which I still don't understand how or why.)

Snippet from my module to fix

function module_panelizer_pre_render_alter(&$panelizer, &$display, $entity) {
  // Is it even needed to define all of this, or simply passing an empty array
  // good enough? Who knows. This is more fun, right?
  page_manager_get_current_page(array(
    'name' => 'node-view',
    'task' => array(),
    'subtask' => array(),
    'contexts' => $display->contexts,
    'arguments' => $display->args,
    'handler' => panelizer_get_entity_plugin($panelizer->panelizer_type),
  ));
}

If we could properly populate this data (I did for fun and future work) Panelizer would then follow the same patterns as any other Panels page. I'm still diving into the depths of Ctools plugins but perhaps there could also be a way to store the Panelizer's config in task/subtask.

Comments

merlinofchaos’s picture

merlinofchaos commented

IMO this technically would not be correct; page_manager_get_current_page() is used to see if page manager controlled the page; which, because Page Manager really only supports Panels as a rendering mechanism, means Panels rendered the page; at the very least, you should be checking which view mode is in use, or this will fail terribly when using say, the 'teaser' view mode and rendering 10 different nodes as panels on a listing page.

But just because an entity is rendered via panelizer doesn't mean that the entity is the page, and it doesn't mean that page manager did the rendering (unless you're using the special page manager view mode, which I assume you are). The fact that you fill out task and subtask to be null should be a hint that you're misusing it.

That said, using this as a local site hack to get data to mini panels or breadcrumbs is probably fine, because data transmission is hard, but I would be against making this 'standard' behavior.

mglaman’s picture

mglaman
Primary language English
Location WI, USA
commented
Component: Code » Documentation

That's what I sort of assumed. The task and subtask were nullified because I quick got the "ah ha!" and fixed the immediate issue and didn't flush it out further (goal was to fix Kalatheme's failure to check if a node being viewed is Panelizer-ized.) I was going to flush out but wanted to see if this was even a proper thing it should be doing.

I see where the issue would be on teasers. We only use Panelizer on full view modes. Thanks for the feedback, that's what I was looking for!

Maybe we could turn this into a documentation issue? Some (such as myself) may misunderstand why Panelizer doesn't always work the same way you'd expect a regular Panels page to work - even though they're both using Panels. And that's because Panelizer has nothing to do with Page Manager (aside from being a variant in node_view) correct?

If not, then lets just close it out and be on our merry way.