I'll make sure to replicate the markup of the existing page.tpl.php
for use with Panels, with and without Panels Everywhere.
I'd favour to remove all the existing Panels layouts and only provide a set of layouts that would replicate the exact same markup and the normal templates. Right now the markup differs quite much and can't take advantage of the core Zen stylesheets. Right now the Panels layouts requires to be maintained separately. We don't want that. And I think it's fair enough to actually remove them since Zen 7.x-5.x still is in dev.
I'd also like to add the panels-pane.tpl.php
to Zen and replicate it's markup and classes (i.e. .block
) so we can take advantage of the responsive stylesheets.
Sounds good? I'm currentlt running a client project where need this. So I'm on it.
Also, could we add a new component to this project for tracking the Panels stuff? There might be more things coming :)
Comment | File | Size | Author |
---|---|---|---|
#44 | 1540948-zen-panels-everywhere-44.patch | 2.57 KB | Owen Barton |
#38 | 1540948-zen-panels-everywhere-38.patch | 17.36 KB | dixon_ |
#38 | 1540948-interdiff.txt | 727 bytes | dixon_ |
#37 | 1540948-zen-panels-everywhere-37.patch | 17.19 KB | dixon_ |
#37 | zen_panels_example.zip | 4.54 KB | dixon_ |
Comments
Comment #1
JohnAlbinSOUNDS GREAT!
I'm going to remove the old panels now. Since, yeah, they're kind of old.
I'm releasing a Zen 7.x-5.0 today, but we can definitely add in these new ones when they're ready. :-D It would be a god reason to release a 7.x-5.1.
Comment #2
JohnAlbinRemoved the old ones. http://drupalcode.org/project/zen.git/commitdiff/221106f
Comment #3
sylus CreditAttribution: sylus commentedHey was wondering that status of this and also whether or not this pertained to Panels Everywhere. I am right now starting to use the panopoly distribution. It would be great to extend it with Zen + Panels Everywhere.
I'd love to help out with this but would require some guidance on where to start first and what has currently been done.
Comment #4
dansyv CreditAttribution: dansyv commentedAny updates on this? Cant seem to find anything related to panels in the 7.x-5.1 release.
Comment #5
dixon_The project I had at hand has been delayed for several reasons. That's why there's no code yet.
So unless someone else beats me to it, it still will take some time before I get to work on this.
Comment #6
JohnAlbinMarked #684826: Add panels_everywhere layouts as a dupe.
Comment #7
Lukas von BlarerI created the issue #1343544: Making Panels Everywhere aware themes in D7 a while back but there wasn't any progress. Since I am using Zen as well, maybe we can join forces here...
I downloaded the rc1 and now there is more stuff you can set up through the UI. I got it working without any modifications to Zen. Now we should make Zen PE aware...
Comment #8
steveoliver CreditAttribution: steveoliver commentedI'm not very experienced with Zen theming or Panels layouts, but as I pursue the combination, here are a few basic resources that may be helpful for developing responsive panels layouts in Zen:
Comment #9
dixon_Progress is being made on this from our side here again. We have successfully ported page.tpl.php to Panels layouts and moved certain elements into various Panels templates.
Patch will be submitted once it's a bit more tested.
Comment #10
minorOffense CreditAttribution: minorOffense commented@dixon_ we're working on a Panels responsive layout using Zen as well. If you have any code to share I'd be glad to help contribute to it.
Comment #11
Lukas von BlarerWhat I currently do for the responsive part is that I throw all content into one region of the panel an then use Zen Grids to add the responsive behavior. What is your approach?
Comment #12
minorOffense CreditAttribution: minorOffense commentedThat's pretty much what I was thinking. I was also considering adding panels layouts mark specifically as "responsive". In other words taking the default panels layouts and adding responsive equivalents as options. But it does make sense to assume if the user is using Zen, they want a responsive site, regardless of what panels layouts they've chosen.
Unless of course they're using mini panels or with display suite or something like that.
I've been arguing with myself for a few days now on which approach to use :-S
Comment #13
torgosPizzaThis sounds like the same kind of approach I'm taking on a couple sites: making a responsive layout with Zen and possibly extending it with Panels. Can anyone (@dixon_?) give me a brief summary of what the advantages are of using Panels Layouts as opposed to just building a handful of tpl.php files? My initial feeling is the ability to cache data, but is there anything beyond that? I'm trying to determine benefits of speed gained from caching vs. generation speed lost due to additional modules/code.
Thanks!
EDIT: Sorry, I feel like I'm hijacking here :) I currently use Panels and love it for its flexibility in being able to add content from various modules without having to code it (Blocks generated by Views containing arguments, for example). Looking forward to seeing more discussion about any further integration between Zen and Panels.
Comment #14
caschbre CreditAttribution: caschbre commented@dixon_ ... I'm working on a project that will provide a responsive design using Zen 7.x-5.1 and panels, however we will have a mix of pages using panels, panelizer, and the traditional template files so we're not completely replacing the page.tpl.php file. We're basically assuming sidebar-first and sidebar-second will be empty for most pages that are a panel.
I'd be interested in helping out.
Right now I'm looking at how to re-work the .tpl.php and .css files provided by the panels module. Ideally I'd like to include the layouts with the theme and use .scss files to handle the responsive pieces.
Comment #15
jherencia CreditAttribution: jherencia commentedLet's see what you think about this aproach.
For the record, this (#1850050: Make theme list available after overwritten) would help a lot.
Comment #16
lpalgarvio CreditAttribution: lpalgarvio commentedHello!
I've started building up an integration.
I haven't included jherencia's code, but opted for using the machine names he used to maximize compatibility if the codes are to merge.
Here's what i built:
The output isn't the same yet as page.tpl, but it's getting close ;)
Comment #17
lpalgarvio CreditAttribution: lpalgarvio commentedhere's the sample site template variant, using use zen_page and without extra CSS code.
i also forked the code and patched here:
https://github.com/solsoft/drupal_zen_panels
Comment #18
lpalgarvio CreditAttribution: lpalgarvio commentedContinuing the discussion on the code,
Which method would you prefer for sidebars?
Layout, Mark II:
I'm going to build 1 or 2 extra layouts, respectively Header & Footer, to be used as CTools / Panels Mini Panels in the site template, as alternative to Pane Header, giving much more flexibility. This will have a requirement on Mini Panels from Panels, but will be an optional addon, They will include the layouts and the mini panels variants.
Will also build a variant PE site template.
Regarding CSS:
Since we are using SCSS, i would recommend having no CSS code in the layouts (well maybe other than for admin tpl to use in panels interface), and instead place all the potencial code in the main SCSS/CSS directories.
Suggestions for new SCSS/CSS files:
What about other CTools / Panels objects?
Do you think they deserve proper SCSS/CSS files?
The CTools universe is as follows:
Given the amount of modules/submodules, i think the number of files should limited.
Panels Everywhere: pe.(s)css or pe-styles.(s)css
Initially, probably there will be no need for having extra code (i think), but users may end up putting the code in the layout files or in pages.(s)css. I think this module deserves it's own CSS.
Panelizer : panelizer.(s)css or panelizer-styles.(s)css
Ideally, this module deserves it's own dedicaded CSS file, much like display suite.
I don't think it's code should live in nodes.(s)css, if the code is to be as clean as possible (and nodes is already big).
But having it on it wouldn't be bad either.
Mini Panels and Custom Content Panes: panes.(s)css or panes-styles.(s)css or ctools-panes.(s)css
They are more or less the same objects, Panes, but they aren't Blocks.
I don't think they should go in blocks.css, likewise with nodes, as it's already big and can cause confusion.
Alternatively, combine with remaining CTools objects, but that file can grow extra large...
Page Manager: pages.(s)css, or go along with the remaining CTools objects.
Stylizer and Panels (the remaining CTools objects): ctools.(s)css or ctools-styles.(s)css
Comment #19
echoz CreditAttribution: echoz commentedI don't believe this categorizes as Priority: major, since Zen operates fine without it.
Comment #20
JohnAlbinSee the related #1931724: Override default panels and panels_everywhere templates
Also, I'd like to see the new layouts be in a panels-layouts sub-folder so that it is clear that these layouts aren't related to SMACSS/CSS layout, but are related to Panels (and thus can be ignored if you're not using Panels.)
Definitely option 1. It's easy to switch layouts in Panels if you realize you're not going to use some of the regions.
Nice! I made a very-site-specific mini panel layout for a recent project and it worked great!
Regarding the naming of the CSS files, please checkout the 7.x-5.x-dev version, the file names have ALL been changed and simplified based on the SMACSS categorization. See also: #1931746: Update Zen's SMACSS implementation to use Drupal 8 CSS Architecture guide I think that each panel layout should have a SCSS file in sass/panels-layouts/
Comment #21
lpalgarvio CreditAttribution: lpalgarvio commentedalright, will do =P
this week i will be full of work, but i might have some spare time for this on the weekend.
will post patches asap
Comment #22
cferthorney@LPCA have you by any chance got any code on this? If you have and are in a position to provide it I'd love to try and help. I'm looking to do a PE based responsive theme with Zen Grids and would love to contribute the code back but if someone has started it, my mind says if we can share the effort that makes sense. :-)
Comment #23
majortom CreditAttribution: majortom commentedJust checking on the status. I'd be happy to help test or anything else I can do without the ability to write code.
Comment #24
JohnAlbinAny updates?
Comment #25
dixon_I'll get around to publish a patch from the project I was working on a while back. It'll come later today!
Comment #26
dixon_Comment #27
JohnAlbinI just finished writing the upgrade instructions for 5.2 and was about to push the tags I made locally. https://drupal.org/node/1588228
I'll give you 24 hours. :-)
Comment #28
JohnAlbinI pushed the commit 7.x-5.2 was attached to, without pushing the tag. It affects pane-navigation.tpl.php, FYI.
Comment #29
dixon_Here we go!
Attached you'll find a patch that makes Zen integrate flawlessly with Panels and Panels Everywhere (and there's also a basic template for Panelizer). I've also attached a very simple Features module with all the basics needed to test the setup on a clean test site with Zen enabled, just to make your life testing the patch a little bit easier ;-)
The patch is IMO not very invasive on the existing Panels stuff actually. Point 3, 4 and 5 below are the things that changes slightly on existing things and that might be worth highlighting a bit extra in the next release notes. However, I do all of the changes makes a lot of sense, because they provide a really seamless Panels integration.
page.tpl.php
) and one main layout wrapping the main content and side bars. Both layouts represents the default Zen markup to 99.9% and works with the default responsive rules.panels-pane.tpl.php
to change its classes to replicate those of normal blocks. This way we can re-use the default responsiveness built into Zen. Very useful IMO.pane-navigation.tpl.php
to look/work exactly like default Zen, i.e. that pane can be placed in thenavigation
Panels region inside the main layout to behave exactly like default Zen and thus, it doesn't render the secondary menu any more.pane-messages.tpl.php
now includes breadcrumbs and page title as well, thus there's now one pane that represents all the things that normally is placed just above$page['content']
(i.e. breadcrumbs, page title, tabs, help and action links). The newly introduced preprocess function for this pane now also uses CTools callback tokens to fix problems with rendering order of things that Panels sometimes want to override. This is a built-in system in CTools that Panels itself uses in tricky situations like this.panels-pane--no-wrapper.tpl.php
that's being used the same way likeblock--no-wrapper.tpl.php
is being used in default Zen to avoid wrapping common things like the page content, header, navigation and message panes.div
witharticle
for entity view modes controlled by Panelizer. It's a nice addition I believe.All in all, this should be a very solid patch. We've been running with it in a project for a while now (I simply didn't come around to document the changes to submit the patch) and it works really well with standard Zen stuff, as pointed out above.
Comment #30
dixon_The icons for the two new layouts aren't in the patch. So I'm attaching them here. The first one should be put in the
zen_page_default
layout folder and the second should be put in thezen_main_default
layout folder.Comment #31
JohnAlbinThis hunk of the patch won't apply because the icon isn't being included as a binary file.
Try git format-patch --stdout or git format-patch --binary --stdout
Comment #32
dixon_Ah, this should hopefully do it then.
Comment #33
dixon_Comment #34
JohnAlbinI'm going to move zen_preprocess_zen_main_default() into zen_main_default.inc.
Comment #35
dixon_Sounds reasonable :-)
Comment #36
JohnAlbinI love these changes, but I can't drop them in as-in into the 7.x-5.x branch because it will change the way several Panels panes work on production sites.
I can commit the whole patch to 7.x-6.x and backport as much as possible without changing the way those panes work for existing sites. Optionally, I could also commit the pane-breaking changes to STARTERKIT on 7.x-5.x. That way new sub-themes could get the changes without breaking old sub-themes. Thoughts?
Comment #37
dixon_Here's a new patch that should meet all your concerns, I hope.
What's changed since last patch:
zen_preprocess_zen_main_default()
intozen_main_default.inc
zen_preprocess_panels_pane()
that I had in my initial patch.highlighted
andfooter
regions.The only line of code we're changing with this patch is how the action links are printed. But it doesn't change any markup for anyone, it's merely an improvement so that Panels can override them.
Comment #38
dixon_Here's an even better patch that fixes the missing new line and adds documentation for the Panelizer template.
Comment #39
dixon_I've added some basic online documentation about the Panelizer template here: https://drupal.org/node/2053547
I know that Zen uses SMACSS style class names on some places. I don't know how it works, but maybe classes for this template should follow the same style? I don't know, personally I'm fine with the default Panelizer classes.
Comment #40
JohnAlbin*sigh* I've been looking at this very closely for several hours. I think the changes are just a little too big to be added to 7.x-5.x. I don't want to break sites using Panels and Zen 7.x-5.x. And I think the theme settings shouldn't be there; those things should just be "on".
I will, however, commit this to 7.x-6.x within the week. Thank you for all the hard work, dixon!
Comment #41
caschbre CreditAttribution: caschbre commentedHow does this affect users wanting to use panels with Zen... but not in the way Zen has it implemented?
For example, I continue to use the regions Zen provides, but have also included my own panel layouts / styles / etc. in my sub-theme. These take over the content area but leave the theme regions alone.
Comment #42
JohnAlbinI've committed parts of this to 7.x-6.x.
http://drupalcode.org/project/zen.git/commitdiff/4e24237
http://drupalcode.org/project/zen.git/commitdiff/d2f45e2
http://drupalcode.org/project/zen.git/commitdiff/78ea998
Comment #43
Kojo Unsui CreditAttribution: Kojo Unsui commented@JohnAlbin, @Dixon , in order to use the full improvements made by Dixon, may I use 7.x-6.x-dev, or use 7.x-5.4 and apply the patch #38 ?
I got confused because you said I've commited parts of this to 7.x-6.x-dev.
I' m currently working on a new project with zen 7.x-5.4 + Neptune + Panels & Panelizer, I tried to upgrade to 7.x-6.x-dev + Panels Everywhere, but had unexpected results. I'm not smart as you are, so if I take the right option from the beginning, it will surely be less painful.
many thanks in advance to give me a quick tip :)
Comment #44
Owen Barton CreditAttribution: Owen Barton commentedIt looks like there are roughly 3 main (potential) remaining chunks from the original patch that are not yet committed:
1: A "page" panel layout including the high level regions - header etc.
2: Settings and preprocess implementations to make the HTML output more like non-panels output (presumably so default CSS still applies)
3: A Panelizer view mode template.
The first of these seemed the main missing element to me - it's hard to use panels everywhere without a header region to put things in. The attached patch includes that layout, but renamed to match the naming convention that was committed.
Comment #45
alexiscott CreditAttribution: alexiscott commentedAs per "1. A "page" panel layout including the high level regions - header etc"
1540948-zen-panels-everywhere-44.patch does seem to catch the default areas which Panels Everywhere creates in its "Default site template"
This makes it usable with Panels Everywhere.
Comment #46
DamienMcKennaFYI jherencia's patch in #1850050: Make theme list available after overwritten has been committed and will be part of Panels Everywhere v1.0.
Comment #47
dixon_Comment #48
kenorb CreditAttribution: kenorb commentedSee: #2448097: panels-pane TPL hardcores H2 tag for every pane label
Comment #49
FrancewhoaAdded links to Panels Everywhere and Panels project pages
Comment #50
JohnAlbinI think what we have in Zen now is as good as it is going to get. The patch in #44 is a pretty trivial panel template; not sure how usefully it would actually be.