Posted by Amitaibu on November 28, 2010 at 10:15pm
37 followers
| Project: | Omega |
| Version: | 7.x-3.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | cweagans |
| Status: | closed (fixed) |
Issue Summary
I'm looking for a nice home for this patch #780782: Add Panels layout, and omega seems like a solid place. It doesn't expose the settings via UI, but it allows for a bit more advanced users to easily create panels layouts.
Comments
#1
I love it!
Will definitely get added to this 2.x branch in 7.x
I just need to test out the 7 version of panels to make sure all the basics of setting up layouts works the same.
Will definitely try to get this in soon (still 2 days away from the office with the holidays)
#2
Serendipitous! aka subscribe
#3
Looking for a good base theme that supports Panels, as well as Context. Has this patch made it into the 2.x branch yet or is there any ETA on when it might happen?
#4
I'm still pondering this one...
I feel that with a recent post I made that I've (for me at least personally) removed the need for Panels... ever...
Combining Omega, Delta & Context will give full contextual layout abilities AND block positioning (via standard Context usage)....
I'm (at this exact moment) not sure how excited I am to throw in a default panels layout (although I still am considering it) into the core omega package...
I'm STILL not completely opposed (even if I never plan to use Panels moving forward) if there really IS a big call for this...
If you/someone could sell me on the idea for sure, and provide a patch that works with Omega... I may just bit the bullet. :)
#5
@himerus: Thanks for you quick response.
I suppose Context vs Panels is an ongoing debate on which one to use. Luckily though it is possible to use both.
My main reason for using Panels is the much improved relation support between content and view panes, making it so easy to create View panes (Panel blocks) that are related to the main content. The site I am building right now will use this to its limits on many pages.
Some pages will not need this and will for that I intend to either use Drupal core block management or Context. I am leaning at Context as it will give better flexibility and more fine graded control though.
I suppose for my needs Omega doesn't really have to support Panels that much. Basically the Panel pages will have three main regions; Header, Content and Footer. The Content region is where the panel will go and it will have no sidebars.
From what I have read/seen so far about Omega and Delta it wont be much of a problem to turn of the sidebars for those Panels pages, or?
#6
@tsvenson
I agree with your argument on where Panels DOES make certain things easier.
Omega + Delta + Context will make it EASY to disable sidebars anywhere.
I do need to play with the default panels settings where you can disable sidebars in the Panels config for a display. The 6.x version worked that way, but when the original version(s) for D7 were implemented, Panels wasn't stable enough to test with. I need to at the very least put that in.
#7
@himerus
It would be great if you could implement support for how panels turns sidebars on and off. Being able to automatically sync those settings between Panels, Omega and Delta to only have to change it in one place would be great and most likely be enough for my needs.
I haven't played much with Panels 7.x yet as @merlinofchaos is focusing on getting a stable version of Views ready first. It does work somewhat, but is not stable enough yet. Hopefully it will be soon so i can start using it.
I'm also planning to give Omega a test in a few days. From what I have seen so far it has everything I am looking for. If my tests confirm that, I will offer my help to you with testing, including the Panels support if you decide to implement that.
#8
I actually disagree with your opinion on Panels, and infact use it on every site I build (I know you did too, as you mention in your blog). I think that the theme system can't or shouldn't try to give the power Panels gives.
One of the reasons I like to use Panels, apart of the UI and the fact that non-coders can collaborate is the "context" system of CTools (not to be mistaken with the context module) and the plugin system. In short (and I plan to write a blog post about it), I no longer use hook_block, but use the plugin system to write small include files that are loaded when needed.
In my opinion Omega should focus on being the best on most flexiable 960 theme, no more no less - but of course you may disagree ;)
#9
@Amitaibu
Maybe I've mis-represented myself a bit. YES, I've used panels alot... it is very useful, and does so much... It changed the way content could be rendered for a semi-novice user in a clean interface....
My "overall" position on the matter is this:
1. ) ONLY the theme layer should be responsible for laying out your layout/regions.
2. ) ONLY the module side should be responsible for block/views positioning/etc.
I feel like (besides the sometimes costly overhead of Panels) that "most" tasks can be completed by letting your theme (in one way or another) handle the layout, and then using Context to place all content. There are also ways (via code right now) to pass ctools/contextual args back to views to get a similar representation of panels pane blocks. (I Know this isn't easy for a new user)
So in my own work the goal is:
1.) Make Omega the BEST theme available (with or without 960)
2.) Make Delta work with Context in a way that allows for completely different layouts in any circumstance context can define.
3.) Use context to place all blocks/views/etc sitewide
4.) Eventually build the Omega UI so that the default omega settings & delta layout setting copies are able to use an advanced interface to build the layout/region structure.
I have always loved and used panels when I felt it was needed, but (in my own mind) conceptually disagree with the one module handling all that, and want my pieces to be split more between the theme and module layers accordingly.
When the other day I tried the latest dev of Display Suite, and creating new D7 display modes, now I have a test site I'm building showing about a dozen different types of node teasers and field settings for various sections of the site. Combining Omega, Delta, Context and Display Suite now is so close (for me) to replacing the way I've always used panels...
Definitely room for argument/correction/etc here... but that is just my $0.02. :)
I will still consider adding a panels layout or two into the core omega package... I'd even like to setup a way with the Omega UI that those default panels layouts were adjustable too through the interface, and not just in the template code.
#10
A key reason for using Panels is to give editorial access to site editors over page layout, from one location rather than multiple locations. Using the Panelizer module any content type can be made into a "Panel node" and can have the page's layout easily overridden on a per-node instance; this isn't currently possible with DS, Delta & Omega without a lot more effort.
What about using templates to limit the output of the core panel and build layouts that can mesh with the Omega/Alpha theming architecture? It might require a slightly more customized sub-theme to handle it, though.
#11
Another good reason for using panels is because it lets you pass arguments to views from contexts... Which is a lot nicer than php default arguments.
#12
I am Designer and came to Drupal one month ago.
Omega was the logical next step, because of its great potential to layout websites.
Two weeks later I was on a dead end because blocks don't understand contextual filters.
Next step: cTools' Pages and Panels.
Great. Now: How can I integrate Omega/Delta with cTools' Pages/Panels?
The Delta-Context-Content type-Relation works fine. But it breaks when the node is taken over by Pages.
Is there a possibility to have different Block layouts via Delta in combination with differend cTools/Pages/Panels szenarios?
#13
#14
@Thomas Factory: One way I have been playing around with is to use Mini Panels. Then Panels will manage the context relations between the "block" in the Mini Panel and you simply embed it in a region in your Omega based theme.
If all the content on a particular page needs this, or your layout requires it, then you basically end up having three regions on top of each other. Top = Header, Middle = content (Mini Panel) and Bottom = Footer.
Also, note that you can mix and match using Panels, Context and even Display Suite on the same site as needed.
#15
@tsvenson:
One way I have been playing around with is to use Mini Panels. Then Panels will manage the context relations between the "block" in the Mini Panel and you simply embed it in a region in your Omega based theme.
Thank you, I will try this out.
If all the content on a particular page needs this, or your layout requires it, then you basically end up having three regions on top of each other.
If I understand you right, I am at that point exactly. I have a block-layout in Omega, from which I want to have variants with Delta. There, in the Header- and Footer-regions, I want to have elements which don't have to be context sensitive.
In the Content however I'd like to have elements like Splash images (or galleries) or the Main-menu, which you would normally put into the Branding- or Menu-region of the Header. Except for the Main-menu all should be context sensitive and free to position in the Content region. For this to achieve I use the CTools Page Manager and Panels.
Also, note that you can mix and match using Panels, Context and even Display Suite on the same site as needed.
I am on my way to try out the potential in the combination of this plug-ins. At the moment I am stuck with Context, because it does not hand-out a layout from Delta (to a node which is managed by CTools' Page Manager.
#16
@tsvenson
"node/1" under the Path condition in Context works.
Nevertheless I will also keep the Mini Panel option in mind.
Thank you.
#17
So.. I just tested Omega together with Panels (for the first time) and am curious as to where you guys are having problems? It ingetrates nicely and works like a charm for me. The only thing that is missing actually is a set of Panels layouts with proper grid classes. Apart form that it worked like a charm. The problem you guys are probably having is related to the CONTEXT module as that one places blocks in a really strange way. Instead of using hook_block_list_alter context places the blocks by rendering them into #markup elements in the page which basically breaks Panels' "Hide blocks and regions" option.
#18
I am going to provide a whole set of panels grid layouts during the next couple of days.
#19
@fuhby: It's the list of compatible Panels layouts that I think needs to be included, not Context, so I look forward to seeing what you come up with.
#20
Yes but some of the problems that were described here are related to contexts wonky block and region management aswell as node type detection. Itangalo and me had a few ideas but they will need approval of the context team first before we can speak them out loud.
#21
@fubhy: Are you telepathic? You must have read my mind. I have though about how to make panels layouts more grid aware. Since it would take me a lot of experimenting, I a really looking forward to see what you will come up with.
#22
Just so people know, the new dev of Display Suite uses panels for build modes.
#23
@fubhy: Any luck creating some compatible Panels layouts? Not meaning to push, just interested to know :)
#24
STOP PUSHING ME!!!!
#25
okay, seriously... Umh I was busy working on Omega 3.x (basically completely rewriting it aswell) and will do those panels templates now.
#26
I mean "Omega Tools" of course. ;)
#27
subscribe
#28
[EDIT] Ah, nevermind... Didn't read the issue body ;-) .
#29
Link to interesting related discussion in the HTML5 group. Food for thought regarding Omega 8?
#30
Ace. Some grid aware panels layouts would be awesome. That would enable us to empower content editors with a really easy way to select from some nice preset layouts. Context is an amazing tool for site builders, or even for more novice user, if they are doing some basic dropping blocks into regions. But more complicated stuff like switching the layout tends to be more difficult for people. Panels, with wizards even, really excels at that (although Panels can be a little overwhelming for some too).
#31
So sorry that I still didn't find the time to finish this. I am just here to mention that we didn't forget about it! However, we will probably add this post-stable! Sorry :(. Oh and we will probably use percentual widths on the panels layouts. Nesting Grids is nasty (or can get nasty). Its also harder with nested grids for people who are trying to do fancy stuff with javascript on the grid (like collapsing a whole section on mobile / narrow or whatever.
#32
Percentage widths, really? Doesn't that kind of defeat the purpose of having the Panels layouts in the first place. We can get percentage widths by using the layouts that come with panels, or even the flexible layout builder. The point about having Omega provide some panels layouts IMO was that they would be grid based, and therefore they would fit in perfectly with the rest of the grid based layout.
#33
I will see what I can do!
#34
I have allllll day to work on this. I'll see what I can come up with.
#35
BAM. Panels layouts, FTW. Fully responsive layouts.
Haven't quite gotten it to the point where you can just start clicking around in the UI to build a layout, but that functionality would probably be better suited for omega_ui anyways. So, if you want custom layouts you'll need to create them in your subtheme. Did I mention that it's super easy? There's documentation here about how to create a panels layout: http://drupal.org/node/495654
One note about that panels documentation: don't try to lay things out using CSS if you want your subtheme to stay responsive. Just use the grid classes + the alpha and omega classes to control layout.
Known issue: on the panel edit page, the grid CSS is not loaded, so every panel region displays in a vertical stack like this:
#36
Okay, this patch should work better,
#37
Missed a couple of images
#38
Hi. Thank you for the discussion; am trying to follow.
It would be helpful to get a summary of some conclusions you have reached. After reading all the posts, I am not clear what situations call for the use of omega + panels and what situations call for the use of omega + delta + context.
Kevin
#39
@kevin-bcr: This can be boiled down to: Panels vs Context & Delta.
I have two main reasons for using Panels:
For the larger sites we (Bluespark Labs) work on we've ended up needing the configurability.
#40
You can basically use it all together. But Panels is an excellent choice if you want to do extensive manipulations to your content area. I myself am going for Panels, Context AND Delta. The latter two to inject different overall page layouts (different footers / headers / some other styling) and then I am using Panels to arrange my content area.
#41
You don't have to use it if you feel uncomfortable with it. Its an advanced tool.
#42
A key thing to remember is that having Panels integration does not make any difference to sites that don't use Panels, it's basically extras files that'll (pretty much) never get loaded unless you need them.
#43
Exactly!
#44
Thank you for the answers (and so quick, too!).
@fubhy: So, is the order significant? I.e., do you need to get the panels to work in the content area before you do the overall layout with Delta and Context of what you have laid out? Or, vice versa?
@DamienMcKenna: By "Panels integration does not make any difference to sites that don't use Panels" do you mean, there is no overhead expense in performance?
Kevin
#45
Yes, there won't be any performance overhead if you don't use Panels, correct.
Regarding the other question: I would first build the overall structure and then dive into the content area structuring.
#46
New patch. Admin pages now work correctly.
#47
Use admin css instead, so we don't have to use hook_css_alter in template.php
#48
One more. Accidentally had some .DS_Store files included.
#49
Alrighty, this is the last one. Fixed a couple image URLs, removed empty lines from all .tpl.php files for the layouts.
#50
Good job! Commited.
We might need to add Mini Panels support separatly as those are going to need slightly different CSS classes. Maybe we can figure out how to pull the information about the origin of the layout from the Panels API and thereby modifiy the template properly (Panels vs Mini Panels).
Lets open a new issue for that once this turns out to be required indeed.
#51
BTW, most of these layouts were originally based on the ones that come with panels_960gs. There were a pretty fair number of changes since then, but I thought I'd give credit where credit is due :)
#52
Also, we should point out that this currently only works as expected if Panels completely replaces the content region (No #theme_wrappers => array('region')). Once Omega UI is here this will all be much cooler with a much tighter direct integration of Panels. Think about it as a responsive Panels Everywhere. I am thinking of implementing it in a way that would allow Omega UI to provide the (multiple) Master Layouts (for the overall page structure) while having Panels as a Sub-Layout for the content part. Something like that might be possible...
#53
Automatically closed -- issue fixed for 2 weeks with no activity.
#54
I still have some 20px missing.
Some fast css fix wich helped me to get it back to the right place in the grid.
Maybe it helps someone else too.
.omega-12-twocol-9-3 .grid-3{background: blue;
margin-right: 0 !important
}
.omega-12-twocol-9-3 .grid-9{
background: yellow;
margin-left: 0 !important;
}
#55
Please open a new issue for this. I was having that same problem intermittently, but couldn't find a way to reproduce it consistently.
#56
You could use Pseudo Css selector :first-child and :last-child to avoid margins. But it's not cpmpatible with old browsers.
#57
In order to have margins corrected you'll have to add an class="alpha" to the forst and a class="omega" to the last Block in a row.
You can set your Margins according to the screensize-
See: alpha-default-normal-16.css alpha-default-narrow-24.css or alpha-default-narrow-16.css
/*
* ==========================================================
* Alpha - Omega
* ==========================================================
*/
.alpha {
margin-left: 0;
}
.omega {
margin-right: 0;
}
Maybe this might save you some time.
#58
subscribe
#59
I also think that layout should be handled by the theming side of things...
Maybe this module would be a great solution for just using the Context and Delta modules...
http://drupal.org/project/views_arg_context
#60
Potentially relevant: I recently posted a module, Context panels layouts, that enables use of panels-style layouts in context without using Panels module. You create a context and can select from the panels layouts.
#61
I've been playing around with context (for header and footer region) and panels for the content region. I just add classes here and there but no real integration other than I know what grid classes do what so know where to put them.
I have laid out a duplicate page on my two test sites, one using context and block placement, the other using panels.
My first impressions was that the panels UI is very nice, although hangs over the edges and doesn't quite lay out properly, sidebar is under content, so the page on the UI doesn't really look like the final page. I like how you can add page title, body field etc straight from the UI to basically add bits until your page is done.
However, I can do stuff with delta and context that I could never do before coming over to the drupal dark side from asp.net umbraco cms.
Random things I've noted:
i) Omega 10px margins are too small, 18/6 layout makes the content far too close to the sidebar, been looking into the 978px grid system. The grid is actually 940px (minus margins you don't use, or have to keep adding omega and alpha classes all over the shot if you want the full 960px.
2) Delta - awesome module, easy to get my head around (although panels is just as easy using selection= node type)
3) Context - brilliant for header and footers and stuff that doesn't change much, chuck in the blocks and you're done
4) Panels - IMO the best way to theme a node. The other option is to hide all fields, create a view block, add the fields you want, stick the block into content region via context, seems a bit long winded. Panels=add content, add more content, add a bit more content, save, done.
Overheads difference? No idea, my site is too small for me to notice. Obviously I am still very new to all this but drupal has been superb to learn so far and looking forward to adding more once my coding improves.
#62
Sorry for sounding ignorant, but what do you do with this patch? How is it implemented, in the template.tpl.php file? Or in the panels module? Or to create a custom module?
Bit confused.
Sam.
#63
I haven't gone through and tried every Omega panel - however, at least the 4/12 Omega 16 panel set does not seem to want to display side-by-side, but rather top/bottom. Am I doing something stupid, has anyone else noticed this, or is this actually the intended behavior?
Thanks!
#64
Post new issues instead, don't add issues to a closed feature request.
#65
To everyone experiencing layout issues: #1245428: panels layouts break column alignment should have fixed that. If you're still having problems, please discuss over there.
@samwillc, see omega/panels/layouts in the 7.x-3.x branch. It's just a collection of normal panels layouts. All the layouts are supposed to be responsive (just like everything else in Omega).
Given the amount of unrelated chatter on this issue, I'm going to close comments so that we're not spamming a bunch of people. If you need to reopen the discussion, please get in touch with a webmaster and explain why the issue should be reopened (you're welcome to get in touch with me through my contact form if there something important that needs to be added to this issue).