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 :)

Comments

SOUNDS 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.

Hey 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.

Any updates on this? Cant seem to find anything related to panels in the 7.x-5.1 release.

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.

I 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...

I'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:

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.

@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.

What 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?

That'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

This 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.

@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.

Assigned:dixon_» Unassigned
Status:Active» Needs review
StatusFileSize
new4.2 KB
new5.99 KB

Let's see what you think about this aproach.

For the record, this (#1850050: Make theme list available after overwritten) would help a lot.

Assigned:Unassigned» lpalgarvio
Priority:Normal» Major
StatusFileSize
new14.05 KB

Hello!

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:

  • zen_page Panels Everywhere layout, cloning close to 1:1 the standard zen page.tpl (note: html.tpl isn't overriden by PE)
  • the pane-header.tpl, pane-messages.tpl and pane-navigation.tpl, as close to zen page.tpl as i could. these are used by the default variant in PE to build the new page layout
  • added preproccess functions to template.php to properly output these 3 panes
  • enabled Panels layouts in zen.info

The output isn't the same yet as page.tpl, but it's getting close ;)

Title:Catch up with the Panels integrationCatch up with the Panels Everywhere integration
Issue tags:+template.php, +Panels Everywhere
StatusFileSize
new5.89 KB

here'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

Continuing the discussion on the code,

Which method would you prefer for sidebars?

  1. having 4 different site_page layout (no sidebars, side left, side right, two sidebars) - easy to accomplish and provides flexibility, ie, changing layout on a per page basis;
  2. or having the preprocess functions in the theme - needs testing and development - if it works dinamicaly (haven't checked), i adds the sidebars if these regions are filled in Panels interface, so there is no need for multiple layouts; if it does not, i'm guessing it works with variables, so this gives litle flexibility

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:

  • pe-styles.(s)css - to store Panels Everywhere code

What about other CTools / Panels objects?
Do you think they deserve proper SCSS/CSS files?
The CTools universe is as follows:

  • CTools
    • Custom content panes, which builds Panes on top of the ones already exposed and builtin (like pane-separator) - may require CSS
    • Custom rulesets, which builds access rules to use on Panes - needs no CSS, may in fact end up replaced by Rules or Core
    • Page manager, which builds Landing Pages (non-system & system) that can contain Panes - may require CSS
    • Stylizer, which builds styles on use on Panes - requires CSS
  • Panels
    • Panels, which builds layouts for Nodes, Users, Taxonomy Terms and Landing Pages (the Nodes, Users and Taxonomy Terms part probably is being phased out in favor of Panelizer) - may require CSS
    • Panel Nodes, which builds a custom content type for use with Panels - this is being ditched in favor of Panelizer
    • Panelizer, which builds layouts for Node displays - may require CSS
    • Mini Panels, which builds Panes/Blocks with layouts, to be used as container for other Panes, effectively working as sub-regions - may require CSS
    • Panels Everywhere, which builds layouts for the entire site and can contain Panes - may require CSS

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

Priority:Major» Normal

I don't believe this categorizes as Priority: major, since Zen operates fine without it.

See 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.)

Which method would you prefer for sidebars?

  1. having 4 different site_page layout (no sidebars, side left, side right, two sidebars) - easy to accomplish and provides flexibility, ie, changing layout on a per page basis;

Definitely option 1. It's easy to switch layouts in Panels if you realize you're not going to use some of the regions.

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.

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/

alright, 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

@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. :-)

Just checking on the status. I'd be happy to help test or anything else I can do without the ability to write code.

Any updates?

I'll get around to publish a patch from the project I was working on a while back. It'll come later today!

Assigned:lpalgarvio» dixon_

I 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. :-)

I pushed the commit 7.x-5.2 was attached to, without pushing the tag. It affects pane-navigation.tpl.php, FYI.

StatusFileSize
new4.54 KB
new11.67 KB

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.

  1. Added two Panels layout plugins; one site/page template used by Panels Everywhere (basically representing the outer part of 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.
  2. Added necessary preprocess functions for the layouts to work dynamically with the default body classes for responsiveness. There's some trickery there because of Panels rendering order, but everything is well documented there.
  3. Added process and preprocess functions for 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.
  4. Changes pane-navigation.tpl.php to look/work exactly like default Zen, i.e. that pane can be placed in the navigation Panels region inside the main layout to behave exactly like default Zen and thus, it doesn't render the secondary menu any more.
  5. 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.
  6. Added panels-pane--no-wrapper.tpl.php that's being used the same way like block--no-wrapper.tpl.php is being used in default Zen to avoid wrapping common things like the page content, header, navigation and message panes.
  7. Added a very simple entity view mode template for Panelizer that I find myself using all the time. It basically replaces the wrapping div with article 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.

StatusFileSize
new864 bytes
new811 bytes

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 the zen_main_default layout folder.

Status:Needs review» Needs work

This hunk of the patch won't apply because the icon isn't being included as a binary file.

diff --git a/panels-layouts/zen_main_default/icon.png b/panels-layouts/zen_main_default/icon.png
new file mode 100644
index 0000000..487297b
Binary files /dev/null and b/panels-layouts/zen_main_default/icon.png differ

Try git format-patch --stdout or git format-patch --binary --stdout

StatusFileSize
new17.27 KB

Ah, this should hopefully do it then.

Status:Needs work» Needs review

I'm going to move zen_preprocess_zen_main_default() into zen_main_default.inc.

I'm going to move zen_preprocess_zen_main_default() into zen_main_default.inc.

Sounds reasonable :-)

I 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?

StatusFileSize
new4.54 KB
new17.19 KB

Here's a new patch that should meet all your concerns, I hope.

What's changed since last patch:

  • Added 4 opt-in theme settings that will make all Panels stuff to work like Zen without Panels. By default it's 100% backward-compatible.
  • Moved zen_preprocess_zen_main_default() into zen_main_default.inc
  • Removed unnecessary zen_preprocess_panels_pane() that I had in my initial patch.
  • Added missing region classes to the highlighted and footer regions.
  • Made a small update to the test feature for anyone interested in testing the patch.

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.

StatusFileSize
new727 bytes
new17.36 KB

Here's an even better patch that fixes the missing new line and adds documentation for the Panelizer template.

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.

Version:7.x-5.x-dev» 7.x-6.x-dev
Status:Needs review» Reviewed & tested by the community

*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!

How 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.

Issue summary:View changes

@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 :)

Status:Reviewed & tested by the community» Needs review
StatusFileSize
new2.57 KB

It 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.

As 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.