I figured this was probably a pretty common problem, so I looked through support requests first but didn't find anything. Please forgive me if this has been addressed before.

I am using a mini-panel in my footer to organize a few different blocks of information (address, footer-nav, copyright, search). The css added to my head for this mini panel follows:

div.panel-flexible div.panel-row-1 div.panel-col-1 { width: 49.5%; }
div.panel-flexible div.panel-row-1 div.panel-col-2 { width: 49.5%; }

Since there is no css id being used (nor can I find a place to assign it) there could potentially be a conflict with other flexible panels. I am using a panel page as my frontpage but since I have overridden all panels styles for that node (panels pages have a field for css id) I don't see the conflict on the front-end. I do, however, see the conflict in the panels content management tab where the drag and drop container for row one uses the css above rather than the actual sizes for that panel page.

Thanks for the support, and let me know if any more info is needed.

Comments

te-brian’s picture

te-brian commented
Assigned: te-brian » Unassigned

removed assignment.... incorrectly set to myself

sun’s picture

sun
Primary language German
Location Karlsruhe
commented
Status: Active » Fixed

You can assign a CSS id for a mini panel in the pane configuration of your page panel.

Anonymous’s picture

Anonymous (not verified) commented
Status: Fixed » Closed (fixed)

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

te-brian’s picture

te-brian commented
Status: Closed (fixed) » Active

Hey,

Thanks for the response sun. I'm not sure if this solves my problem however. The mini-panel in question is being used as a block and is assigned to the footer region. The block dialogs do not present an opportunity to assign a css id, and since I didn't find one in the mini-panels admin, this is where the problem arises.

te-brian’s picture

te-brian commented
Status: Active » Postponed (maintainer needs more info)

Hey,

Still battling this issue. To re-cap, if I have two flexible panels on the same page (whether they are mini or page) the css for the panel columns conflict. I need a way for panels to use more specific css identifiers.

,thanks

stevebayerin’s picture

stevebayerin commented

I had the same issue. After setting the CSS IDs for the mini-panel panes, I manually declared the div properties in styles.css. Its more of a work around but it gets the job done (edit:but it makes it almost impossible for the end user of the site to customize panels pages since they don't have the skills to edit style sheets.)

Edit: One way to avoid conflicts is to give mini-panels their own identifiers for rows and columns.

If I have 2 column mini panel in a 2 column panel page, the inner columns of the mini panels inherit the width properties of the columns in the panel page columns instead of the width properties set for them on the appropriate mini panels settings page.

There is a possible solution for the above that could be implemented.

Instead of using the following for rows in mini panels:
class="panel-row panel-row-1 clear-block"

It could be best to have something similar to the following to declare mini panels ids/classes to avoid inheritance issues. A prefix of 'Mini' is added to mini-column classes:

class="mini-panel-row mini-panel-row-1 clear-block"

Same goes for columns in mini-panels, instead of:
class="panel-col panel-col-1"

The following could be used to avoid css inheritance issues for mini-panels (with the 'mini' prefix added to mini panel column classes)
class="mini-panel-col mini-panel-col-1"

zach harkey’s picture

zach harkey commented

This has caused me problems several times. The result is unexpected pane sizes on the admin content pages where the styles are output inline in the head. (Especially when editing a flexible panel with a flexible mini panel elsewhere on the page.)

Drove me up the wall for 2 hours.

SteveJBs recommendations in reply #6 seem like a simple way to reduce a lot of headaches.

Related issue

sdboyer’s picture

sdboyer commented
Version: 5.x-2.0-beta3 » 5.x-2.x-dev

After much sweat and blood, Wim Leers fixed this problem here: #278861: When a Mini Panel is being rendered as a block, no $display->css_id is set. Three cheers for Wim Leers, and this will be fixed as of RC1.

sdboyer’s picture

sdboyer commented
Status: Postponed (maintainer needs more info) » Closed (duplicate)
zach harkey’s picture

zach harkey commented
Title: Mini Panel CSS ID - There doesn't seem to be one » Mini Panel css_id getting lost when displayed in blocks

(Changed the title to be a little more specific)

zach harkey’s picture

zach harkey commented
Status: Closed (duplicate) » Active

Applied patch from #278861, but I can't see that it actually does anything.

The css_id does appear to get set in panels_mini.module at line 805 (I thought it was being set before), but it is getting lost when it is passed into panels_render_display at line 809.

The biggest problem is that the CSS rules that are being output in the head for flexible mini panels still have no #css_id preceding them, so if you have more than one mini panel placed in the drupal block system, they incorrectly inherit conflicting dimensions.

Again, this is only happening for minipanels being displayed through Drupal's block system. Not mini-panels placed within panels.

sun’s picture

sun
Primary language German
Location Karlsruhe
commented
Status: Active » Closed (won't fix)

The reason for this is simple: Without alterations to _phptemplate_variables() or block.tpl.php you are not able to override Drupal's default block output. And the Drupal default output for blocks is

<div id="block-<?php print $block->module .'-'. $block->delta; ?>" class="clear-block block block-<?php print $block->module ?>">

Hence, Drupal outputs its own block id and there is no chance for Panels to override this.

zach harkey’s picture

zach harkey commented
Status: Closed (won't fix) » Active

Hey Sun, I appreciate your prompt attention to this issue. I feel like I'm bucking authority to change the status from won't fix, I don't mean to overrule you, just put it back on your radar one more time because I think this is a pretty big problem that can be fixed with your help.

As far as I can tell, this has nothing to do with _phptemplate_variables() or block.tpl.php.

The problem is the CSS rules that are being added to the document <head> by the panel layout. Specifically, the theme_panels_flexible() function in flexible.inc adds several CSS rules directly into the <head> around line 362:

drupal_set_html_head("<style type=\"text/css\" media=\"all\">\n$css</style>\n");

The $css variable is built up through a series of earlier conditionals, e.g.

$css .= "$idcss div.panel-row-$row div.panel-col-$col { width: " . ((intval($settings["row_$row"]["width_$col"])) - $reduce) . $settings["width_type"] ."; }\n";

If I have a mini panel named 'footer' (2 columns: 15%, 85%) then the CSS rules should be:

#mini-panel-footer div.panel-row-2 div.panel-col-1 { width: 14.5%; }
#mini-panel-footer div.panel-row-2 div.panel-col-2 { width: 84.5%; }

And that is exactly what happens if I drop the mini panel into a page panel.

However, if I drop this same mini panel into a block region, the CSS rules are output as:

div.panel-flexible div.panel-row-2 div.panel-col-1 { width: 14.5%; }
div.panel-flexible div.panel-row-2 div.panel-col-2 { width: 84.5%; }

The CSS rule is being set correctly, but somewhere along the way it is being dropped. Resulting in a generic css rule that conflicts with other flexible panels placed elsewhere on the page.

This is preventing all kinds of cool mini panel layouts.

sdboyer’s picture

sdboyer commented
Status: Active » Closed (duplicate)

I don't know why the patch I initially referenced didn't help you, because the situation you're describing - that the CSS ID is absent only in cases where mini-panels are being rendered through drupal's block system - is specifically what that patch was intended to solve. And, according to my own testing, it did. AFAIK, the phptemplate_variables() limitations issue arent relevant in this case. And, nested mini-panels are a knotty, but entirely separate problem.

A few additional notes re: your last post: the fact that panels adds its css directly to the <head> tag is a longstanding, well-known issue. There are other ways to do it, sure, and those are avenues that we will be pursuing eventually. We're aware of the limitations it poses, but forgive me for getting a little impatient on this one, because there are numerous other threads over the past couple months where I've said much the same thing: flexible, though handy for initially creating layouts, really shouldn't be something that's used in production. The initial convenience is great, but it's _nothing_ compared to what you can do with writing your own layout plugin - and really, it's not _that_ much more complicated. Moreover, you get a speed benefit from using your own plugins - no additional db hit to get the flexible layout from db storage - AND you get the stability benefit of being able to use that layout like any other layout - simple point-and-click selection. That makes it scalable.

In terms of this issue, however, I saw the CSS ID go from absent to present in the circumstance you're describing with my own two eyes, so I'm pretty sure it's been solved. I'd encourage you to try again with that patch - keep in mind that the patch is against -dev, which may be part of the problem you're having - and iff the problem persists, re-open the issue then.

zach harkey’s picture

zach harkey commented

@sdboyer, based on your last comment, I double checked and can verify that I am using 5.x-2.x-dev with the patch from 278861 applied.

I even considered moving this follow-up comment over there so you wouldn't have to keep marking this thread as a duplicate, but IMO this is not technically a duplicate. Wim's patch did work. The $display->css_id is being set.

The more specific problem being addressed in this thread is that the value from $display->css_id is not making its way into the actual CSS that is being output in the <head>(See my previous comment for exact details)

Steps to reproduce:

1. Create a mini panel named 'test' with the default flexible layout.

2. Go to the Block admin page (admin/build/block) and locate the panel called Mini panel: "Test" and assign it to the footer region.

3. Now go to the home page and view the source and note the following:

- In your footer region you will find a div with the id="mini-panel-test", (which actually proves that the $display->css_id is getting correctly set).

- In the <head> you will find the following incorrect set of generic rules:

<style media="all" type="text/css">
  div.panel-flexible div.panel-row-1 div.panel-col-1 { width: 99%; }
  div.panel-flexible div.panel-row-2 div.panel-col-1 { width: 24.5%; }
  div.panel-flexible div.panel-row-2 div.panel-col-2 { width: 74.5%; }
  div.panel-flexible div.panel-row-3 div.panel-col-1 { width: 99%; }
</style>

The correct rules should have #mini-panel-test prepended to each one, like this:

<style media="all" type="text/css">
  #mini-panel-test div.panel-flexible div.panel-row-1 div.panel-col-1 { width: 99%; }
  #mini-panel-test div.panel-flexible div.panel-row-2 div.panel-col-1 { width: 24.5%; }
  #mini-panel-test div.panel-flexible div.panel-row-2 div.panel-col-2 { width: 74.5%; }
  #mini-panel-test div.panel-flexible div.panel-row-3 div.panel-col-1 { width: 99%; }
</style>

And, in fact, if you were to place this mini-panel inside of another panel instead of a block region, this is exactly what you do get. It is only inside of the drupal block regions that they lose their ids

---

zach harkey’s picture

zach harkey commented
Status: Closed (duplicate) » Active

Reopening based on previous comment.

sdboyer’s picture

sdboyer commented

Ahhh. ok, I think I finally got ya now. Unfortunately, I _still_ can't replicate the problem :P

I followed precisely the steps you laid out, and I even (generally) see the logic behind where this problem could be. But it's simply not happening for me - even when the mini-panel is being rendered through a block, the dynamically-set css text in is STILL being generated with the proper #id value, not the generic class value.

Not sure what else to tell you. :/

zach harkey’s picture

zach harkey commented
Status: Active » Fixed

@sdboyer you're right!

Thank you so much for going out of your way to test my conditions.

Based on your test results, I went back and isolated the problem to some kind of horrible theme-related, block-region-configuration-caching-hell. It took so much trial and error that I can't really even be sure what the exact fix was.

But it's working now.

Thanks again.

zach harkey’s picture

zach harkey commented
Title: Mini Panel css_id getting lost when displayed in blocks » Mini Panel css_id getting lost when displayed as block in custom theme regions

Uggh. I spoke too soon, the problem returned shortly after my last tests.

But! I have new clues. As far as I can tell, the css_id displays fine, as long as I am using one of the default phptemplate content regions.

If I declare my own regions in template.php with foo_regions(), they don't work.

@sdboyer, do you know if you used a custom theme region in your test above?

[ To make things even more annoying, my primary display just died. So now I get to troubleshoot videocards and power supplies for a couple hours. ]

This issue has me somewhat delirious, if anyone could try to reproduce the steps from comment #15 in a custom theme region and let me know if I'm crazy, I'd be forever grateful.

Thanks.

zach harkey’s picture

zach harkey commented
Status: Active » Fixed

Assuming your theme is named 'foo' and has the following regions declared in template.php:

function foo_regions() {
  return array(
    'left' => t('left sidebar'),
    'right' => t('right sidebar'),
    'navbar' => t('navigation bar'),
    'content_top' => t('content top'),
    'content_bottom' => t('content bottom'),
    'header' => t('header'),
    'footer' => t('footer'),
    'closure_region' => t('closure'),
  );
}

If you repeat the following test:

1. Create a mini panel named 'test' with the default flexible layout.

2. Go to the Block admin page (admin/build/block) and locate the panel called Mini panel: "Test" but this time assign it to the content_top region.

- In the <head> you will find *no CSS at all*. Not even the generic CSS from comment #15.

However, if you place this block in the footer region (which also happens to be one of the default theme regions) you will get the following CSS with proper ID:

<style media="all" type="text/css">
  #mini-panel-test div.panel-flexible div.panel-row-1 div.panel-col-1 { width: 99%; }
  #mini-panel-test div.panel-flexible div.panel-row-2 div.panel-col-1 { width: 24.5%; }
  #mini-panel-test div.panel-flexible div.panel-row-2 div.panel-col-2 { width: 74.5%; }
  #mini-panel-test div.panel-flexible div.panel-row-3 div.panel-col-1 { width: 99%; }
</style>

Of course, I keep saying: "you will find...", when it's really just what I find. If anyone else is getting different results, please let me know.

zach harkey’s picture

zach harkey commented
Status: Fixed » Active
zach harkey’s picture

zach harkey commented
Status: Fixed » Active

I've done some exhaustive testing now and it appears the css is only getting output in the head if my mini-panel is placed in one of the following block regions: left, right, footer.

Can anyone think of why it would be working for these regions and no other?

merlinofchaos’s picture

merlinofchaos commented

ARGH. Yes, I know why.

It's a bug in Drupal 5.

()*&()*&)(*&)(*&)(*&)(*&Y#@)$(*@&#()_$*&@#)(*$&@#)($*&@#()*$%&@#()*$%(*).

Those 3 regions are generated at a special time, very early. However, other regions are generated very late -- after all the css/head/script stuff has been generated. The fix is to use _phptemplate_variables and make those regions render earlier and then rerender css or something. Panels can't do anything about this.

I re-iterate: (*&#@_!@#*&%*@#(*&@#($*)@_@#^*@#$(

zach harkey’s picture

zach harkey commented

Ok, I see.

Well, as far as I can tell, this is really only a problem for flexible layouts, right?

Couldn't we just output the css inline on the divs using style attributes? Afterall, it's really just a bunch of width values. Sure, putting them in the <head> looks a little neater, but it's not any more valid, nor is it any more more or less convenient for further theming.

merlinofchaos’s picture

merlinofchaos commented

Maybe, although use of the style tag is considered a major NONO in Drupal. That said, it may be the solution here.

The good news is that this is fixed in Drupal 6, at least, so this is a problem that will not follow us into the future.

merlinofchaos’s picture

merlinofchaos commented

And actually, no, it's not just a problem with flexible; any mini panel is going to have its css fail to be added when placed in regions that are not left/right/footer.

zach harkey’s picture

zach harkey commented

As far as I can tell, the flexible layout is the only layout currently attempting to add additional css in a theme function, where it uses drupal_set_html_head() to output css rules the <head>.

You are right that any layout that tries to do this would have the same problem, but all the other layouts rely solely on external stylesheets which are getting added much sooner during panels_render_layout() which uses drupal_add_css(), so they are getting their css fine even when they are output in regions that are not left/right/footer.

sdboyer’s picture

sdboyer commented
Status: Active » Closed (fixed)

Added this to the KNOWN_ISSUES.txt file; there's really little else we can do at this point.

drecute’s picture

drecute commented

I have a mini panel that has got multiple content panes displayed as System blocks. I applied css_id to each content pane and yes, it didn't get displayed.

Even with custom block region, I manage to get around this using the panel id and classes common to each content pane to style the panes.

if anyone has this sort of setup and wishes to style the panes in a uniform fashion (that is, you want to apply the same style rule to each content pane), then this solution will work.