With the following commit, panels changed the way that regions are rendered.
http://drupal.org/cvs?commit=376632
However, this breaks some styles such as panels_tabs for instance and forces the use of panels legacy mode.
(I'd prefer not to use this mode as it blocks the use of newer styles that use 'render region' instead of 'render panel' as well as disabling IPE.)
The problem is due to panels_tabs needing to customize the way that each pane is rendered (it simply removes the title, then does a normal pane_render). With this commit, the pane is already rendered so no further rendering can be done.
Is there any way the region style can control the render of panes with the new rendering pipeline? Ideally I would prefer not to have to rerender the panes, but if there is a workaround to access the unrendered panes that would also be very helpful.
Thanks
Ben
I want to to upgrade panels_tabs module to be a version 2 panel style but with following commit I am unsure on the best way to go:
Comments
Comment #1
smoothify commentedI've been experimenting with this and have something working - however i'd like to make sure there is nothing in this code that will cause problems later or if there is a better way of doing things that i'm missing.
Here is the (simplified code):
Comment #2
merlinofchaos commentedYou will lose style information when rendering that way, since pane styles may not use theme('panel_pane').
I had *thought* that the renderer was passed into the render region so you don't need to fetch it that way, but I guess it's not.
I was thinking your best bet might be to use hook_panels_pane_content_alter(), but it doesn't seem to get the $display so it's going to be difficult to tell if the region style is going to apply to it.
That said it's probably going to be the best solution. Maybe there's some way to figure out what you need:
function MODULE_panels_pane_content_alter($content, $pane, $args, $context)
In the worst case we'll add $display and $renderer as arguments and in 3.8 you can use that.
Comment #3
smoothify commentedThanks for taking a look at this Merlin
I will have a look at hook_panels_pane_content_alter and see if I can get it to work better for me.
Could I retrieve the display using the panels_get_current_page_display() function?
Thanks again
Ben
Comment #4
merlinofchaos commentedI don't believe that will fetch it since current_page_display is only set sometimes. It'll work fine if, for example, it's a Page Manager page, I think, but not so much if it's a mini panel or a panel node.
Comment #5
merlinofchaos commentedOOOH
This can work
In panels_display::render() we have this:
That gets you the display and the renderer before anything is rendered. You can figure out which regions have your style and do whatever you need to the panes prior to their rendering.
Comment #6
kmv commentedsubscribe
Comment #7
merlinofchaos commentedOh, if you want to be backward compatible what I recommend is creating 2 plugin directories for your styles. You can check PANELS_REQUIRED_CTOOLS_API and if it's >= 1.7 set yourself up as the 2.0 API and tell CTools to use the newer plugin directory; if it's lower, tell it to use the old plugin directory. That will keep people from having to update.
Comment #8
smoothify commentedThanks merlin you are a legend! :)
It looks like hook_panels_pre_render provides just what i need, although curiously the display variable doesn't seem to be passed in. (you can actually access it through $renderer->display though)
So now i've ended up with the following code using which now obeys the the pane styles where necessary and uses both hook_panels_pre_render and hook_panels_pane_content_alter:
Comment #9
merlinofchaos commentedThat turns out to be a cut & paste error. I've fixed but sadly that doesn't help the released version, meaning you can't rely on that variable being correct. Luckly $renderer->display works.
Comment #10
smoothify commentedIn my case i don't actually need to access the display object, but pleased it is now fixed.
I will close up this issue now, as I believe I have a good grasp of how to do what I need now - thanks for your continued help.
Ben
Comment #11
merlinofchaos commentedLet's leave this open, as I think the information here needs to be distilled into documentation.
Comment #12
japerryComment #13
mike.roman commentedI'm at Drupal MidCamp and am reviewing the documentation
Comment #14
mike.roman commentedI don't think documenting this in D7 is necessary, so I recommend closing this issue.
Comment #15
japerryDrupal 7 is no longer supported, closing.