We should implement hook_panels_layout_info() or whatever that hook's name is and feed Panels with the Omega layouts so people don't have to declare them twice if they want to use them both ways.

Also, this gives us a good opportunity to provide cool layouts with Omega that people can then choose to use with Panels or native block system as they wish. Both works.

CommentFileSizeAuthor
#27 panels_layout_settings.png54.71 KBdrupov
#27 panels_content_settings.png103.57 KBdrupov
#27 article_page.png314.88 KBdrupov
#23 omega.code_.1906930-23.patch11.63 KBfubhy
#23 interdiff.txt7.39 KBfubhy
#22 omega.code_.1906930-22.patch9.71 KBfubhy
#21 omega.code_.1906930-21.patch9.3 KBfubhy

Comments

fubhy’s picture

fubhy commented

Okay... This works!!!! Awesome :). It's going to be even more awesome than I initially thought it would be. Yai!

fubhy’s picture

fubhy commented

Okay.. So we will use a feature of ctools plugin API called 'child plugins'. 


// Plugin definition
$plugin = array(
  'title' => t('Omega layouts'),
  'category' => t('Omega layouts'),
  'icon' => 'layouts.png',
  'theme' => 'omega_layout',
  'admin theme' => 'omega_layout_admin',
  'get child' => 'omega_panels_get_layout',
  'get children' => 'omega_panels_layouts',
);

This way we can define multiple layouts through one hook and get the ball rolling. Due to the theme functions we can then even go further and load the CSS accordingly on front-end/admin pages without having to change our info structure much. So omega layouts, the way they are currently, can be 100% translated into panels layouts (and its happens seamlessly!).

I think I'll have a patch/commit ready this afternoon.

One thing that I wonder about: What should we do about $tabs, $title, etc.? Do we want to keep rendering it through the layout directly or leave that job to panels? I really would like to leave that job to panels to be honest but then we need empty array items for those things and inject them through a preprocess function so we don't get PHP notices when trying to render things that don't exist.

fubhy’s picture

fubhy commented

I guess we can allow people to define whether they want to have those elements rendered through a settings form that we can display on the layout UI in panels. The plugin API seems to allow for these type of parent layout plugins to define form callbacks and all that stuff. Okay... So, depending on whether or not we can store that configuration per use-case and not globally for the layout I guess we would do it that way then and give the user a choice. The rendering of those page elements would then happen the original Drupal way through a process function.

msmithcti’s picture

msmithcti commented

Some Omega layouts don't really make sense to be panels layout as well, for instance layout with off canvas navigation. We should add a flag in the layout.inc file to turn off panels integration for that layout.

In answer to What should we do about $tabs, $title, etc.?:
I think #3 is the perfect solution! My usual use case is to only use panels for the main content area, however there are (rare) situations where I turn off all blocks (an option in panels) and use panels for the whole layout.

Looking forward to seeing this patch! :)

fubhy’s picture

fubhy commented

Well, think about Panels Everywhere! In that case an off canvas navigation would make sense actually :). But I still think that the option to NOT have your layout forwarded to panels makes sense, so yeah... we will add that!

fubhy’s picture

fubhy commented
Status: Active » Fixed

Okay... Initial patch for this has been committed to the sandbox. It's not 100% finished yet but the integration of the layouts with panels works. We now need a solution to coupe with the missing 'page' preprocess/process hooks in case of the layout being rendered through panels (and the therefore missing $tabs, $messages, etc. variables that might be used in layouts.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

fubhy’s picture

fubhy commented
Status: Closed (fixed) » Active

Reponeing this because I removed the code for it due to some bugs that I didn't want to drag into the beta. We need a better way of handling this. I think I already have a plan.

dddbbb’s picture

dddbbb commented

Is this still on the agenda for Omega 4?

I'm currently working on an Omega 4 subtheme for a site that uses a fair bit of Panels and am wondering about how much overlap I might end up with when developing custom layouts for Panels.

Assuming I'm not using Panels Everywhere (which I'm not), what would happen to Omega 4 layouts that contain regions that would normally sit outside of a Panels layout (such as header, footer etc)? The suggestion of a flag in comment #4 makes sense to me but I'm still getting my head around how all of this will work together.

Exciting stuff though!

dasjo’s picture

dasjo
he/him
Primary language German
Location Zurich
commented

if you aren't using panels everywhere, the panels layouts normally just live within the content region.
what you can do in addition is using the panels setting to "Disable Drupal blocks/regions".

fubhy’s picture

fubhy commented

Yep. What we are planning to do with Omega 4.x layouts is to expose them as Panels layouts. However, those would normally be layouts for use with Panels Everywhere. So if you don't use Panels Everywhere there is no overlap.

dddbbb’s picture

dddbbb commented

OK, thanks for clearing that up. I'll get back to my custom Panels layouts then...

charlie charles’s picture

charlie charles commented

Can you help please?

I installed Omega 4
and I can not find the simple
or any of the omega layouts in Panels

Do you know why this is please?

fubhy’s picture

fubhy commented

Yes, because this issue is not fixed yet.

vinoth.3v’s picture

vinoth.3v commented

Omega layouts are Full page layouts. But in panels we only need just content area(partial) layouts (without header/footers). So we may need a way to declare regions that are available for panels (may be in layout.inc files)?

panel_regions[] = Content
panel_regions[] = sidebar_first
panel_regions[] = sidebar_second

So it may be possible to hide other regions for panels. Just an Idea.

anyhow panels everywhere needs all regions.

fubhy’s picture

fubhy commented

This is about page layouts. nothing else. We are not going to provide responsive content layouts as it's simply not possible to do so as it's unpredictable and depends entirely on where you stick your content panes. So, as there is no such thing as "element queries" we can't reliably build responsive content panes that would make any sense. The layouts we are going to provide in Omega will only ever be meant to be used as panels everywhere layouts.

dasjo’s picture

dasjo
he/him
Primary language German
Location Zurich
commented

i have seen some polyfill workarounds to make element queries but that might be an entirely different discussion :)
edit: https://github.com/tysonmatanich/elementQuery

fubhy’s picture

fubhy commented

Yeah, but even if they work or ever will work, we are not going to introduce polyfill-dependent layouts here ;).

fubhy’s picture

fubhy commented

@Hydra just sent me https://github.com/Hydraner/nether which includes a further improved version of my original code for this. I will continue working from there and have this ready before DrupalCon.

charlie charles’s picture

charlie charles commented

Great work fubhy - Well done! :)

fubhy’s picture

fubhy commented
StatusFileSize
new omega.code_.1906930-21.patch9.3 KB

Please try this out... Note: The layout preview icons are super larger. This is a bug with the images... We will fix that later. I don't have a image program ;).

fubhy’s picture

fubhy commented
Status: Active » Needs review
StatusFileSize
new omega.code_.1906930-22.patch9.71 KB

Whoops, I broke the omega layouts part of it... Works again now.

fubhy’s picture

fubhy commented
StatusFileSize
new interdiff.txt7.39 KB
new omega.code_.1906930-23.patch11.63 KB

Another patch.. This one does not render any of the core page elements when rendered through panels. That's probably the better way of approaching this...

fubhy’s picture

fubhy commented
Issue tags: +Omega 4.x release blocker

Tagging

fubhy’s picture

fubhy commented

I had Matt test this... Now, on to the follow-up issues:

fubhy’s picture

fubhy commented
Status: Needs review » Fixed

Committed. This is now in RC1

drupov’s picture

drupov commented
Version: 7.x-4.x-dev » 7.x-4.0-rc1
Status: Fixed » Needs work
StatusFileSize
new article_page.png314.88 KB
new panels_content_settings.png103.57 KB
new panels_layout_settings.png54.71 KB

Hi,

sorry, to reopen, but I just tried that implementation out and there's a problem I found.

Panels recognizes the layout provided by omega (panels_layout_settings.png) but even if I assign different elements to different regions through the panels interface (panels_content_settings.png) thay all get rendered in the content region (article_page.png).

Am I missing something?

Thanks!

fubhy’s picture

fubhy commented
Version: 7.x-4.0-rc1 » 7.x-4.x-dev
Status: Needs work » Fixed

These layouts here are ment to be used with Panels Everywhere. They are not content layouts, they are page layouts. Yes, you CAN use them in the content because Panels API works that way but it's not meant for that, so don't ;).

Also, I see that you are not using 4.x-dev but 4.x-RC1. Please always test with 4.x-dev as we are moving things forward towards the release.

This issue is fixed. If you find a problem in 4.x-dev please open a new issue.

Automatically closed -- issue fixed for 2 weeks with no activity.