Flexible layout is broken (all panes are left-aligned) since 3.8

I am having this problem as well. My Css in panels aer ruined after upgrade!

Same here.

OK... very random, but I disabled skinr and then re-enabled it and for some reason everything appears normal.

No clue if the two issues were related or if I had some sort of browser cache issue.

Confirming, same issue on several sites - Panels has done it again! Or was it Fusion, again? Or Panels plus Fusion, again?

In my case, the behaviour occurs without exception on sites based on Fusion (e.g. Acquia Marina, Acquia Prosper, and custom-made Fusion-based themes); however - so far - not all of my Fusion+Panels-based sites are affected, cutting-edge sites with 6.x-2.x-dev plus the latest Acquia Slate do not show problems so far. Sites with other themes (e.g. Marinelli) have no problems with the update at all.

Disabling Skinr 6.x-1.5 and re-enabling it fixes the issue - until I clear the caches. That's definitely not even a workaround ;-(

The same with my site, but the user template profile was displayed top-to-bottom and when I disabled skinr and re-enable the user profile disappered. I can manage the panel (user profile template), but it don't shows in user page. What can I do please?

Can people having this problem do two things:

1) ensure it is not theme related by testing a layout that is broken in Garland and
2) setting the layout to reusable and then exporting and attaching the layout for me to fiddle with.

I think this is fisrt a Skinr issue as now some blocks have apparently lost their (float+Clear+block) CSS too... :(

But it definitly deals first with the page payout, so, is a Panel issue too.

Is it possible to come back to an older version without making bugs ? I'm asking as I thought this version was a none-buggy-dev version type.

I went back to 3.7 and it is working now.

I am also on fusion, and as I commented before, this is somehow related to skinr. I've disabled skinr and panels works fine now.

Earl, before I disabled skinr, panels was operating in "legacy mode". Maybe in the last release you somehow altered how that legacy mode was working.

I personally want out of fusion and skinr to move to panels everywhere and panels IPE. What would be the best theme to take advantage of that? Tinsel?

I went to 3.7 too and user profile template panel is not showed im user page yet.

@Merlin/#6: I exported one simple panel page where the bevaviour should be easily reproducable. The site is running panels-6.x-3.8, ctools-6.x-1.8, jquery_ui-6.x-1.4, skinr-6.x-1.5 (plus JavaScript Aggregator 6.x-1.5, CSS Gzip 6.x-1.3, Memcache 6.x-1.7, CCK/Views2 and stuff like Path alias cache from Pressflow, but those shuldn't matter). The theme is custom-made, based on fusion-6.x-1.0 and skinr-6.x-1.5. Switching to a not Fusion-based theme removes the problem; also downgrading to 6.x-3.7 works for me; switching the theme or the panels version seems to work like a switch.

Please note, that this behaviour does not occur on sites with panels-6.x-3.8, ctools-6.x-1.8, 6.x-2.x-dev, jquery_update-6.x-2.x-dev, jquery_ui-6.x-1.x-dev and acquia_slate-6.x-3.0-beta1. Mybe this narrows it down a little bit.

I'm currently rolling back to 3.7 on all Fusion/Skinr1+Panels sites and evaluating Context/DS/Spaces as alternatives.

Took me awhile to find this. This may not be the only problem, because it doesn't match what the initial poster is reporting.

However, there is a really minor problem with the legacy renderer that seems to be causing this, and only in very specific circumstances that are not things I've tested against, so I never saw this. Patch attached, let's see if it works for more than just me.

As an aside:

I'm currently rolling back to 3.7 on all Fusion/Skinr1+Panels sites and evaluating Context/DS/Spaces as alternatives.

Not sure what this is meant to accomplish in this issue. Is it a threat? Do you think I'm happy that people are having problems like this? Trying to intimidate me into working on this harder?

@Merlin (#12): With the -p0 option the patch applies cleanly against panels-6.x-3.8 and seems to resolve the issue for me. Thank you!

Side effects encountered so far: none (does it work for others, also?) Status report still indicates "Panels operating in Legacy mode"; this issue is caused by Skinr and handled in #866184: Skinr forces Panels 3.7 into legacy mode (btw, #85 would be an appripriate link to replace the "###FIXME"). On the patched site I also noticed that I got an "access denied" as user #1 for panel pages with access restrictions (role=sysop or permissions=administer nodes); not sure if there's a connection with panels-6.x-3.8, will have to investigate.

And no, Merlin, I think you're doing an incredible job in areas which are far beyond the capabilities of most of us. If it came out this way I sicerely apologize. Also I'm fully aware that much (if not all) of the major trouble with Panels in the past few months was rooted it the interplay with Fusion and Skinr which is surely beyond your control. I'm simply unhappy with the complexity introduced with this powerful combo, and especially unhappy with my incapability to provide real help to make this combo more robust. A totally valid alternative would be to trash Fusion/Skinr, as #9 suggested.

Hopefully skinr puts out another release that will stop putting this into legacy mode; I know the patch has been committed, at least to the 2.x branch. I haven't followed it that closely. The continued prevalence abundance of legacy mode is something we hadn't predicted.

Access rules are not meant to be ignored by uid #1, because they are also used as selection criteria. If they were ignored by uid #1, then user #1 would always see the first variant/template every time. That would be bad.

Also, asb, I would love some ideas on how to reduce the UX complexity of the system.

As far as I've followed #866184, the legacy mode issue appears to be mostly cosmetical, so it doesn't bother me too much. The inaccessible panel page appears to be something freakish, other panel pages with (seemingly?) the same access restrictions are working fine on the same site. The one panel page I mentioned in #13 I can not accessed by any means (user #1 has "sysop" role and is granted "administer nodes" privileges). However, I don't think that it has anything to do with your patch from #12 or the panels-6.x-3.8 so it doesn't fit here.

Complexity of the Panels/Skinr/Fusion combo: I meant to refer to the interplay of code which is beyond my understanding. The UI and UX imho is as good as possible for tools which are as heavily under development and refactoring as Skinr and Panels; as every user I have opinions about likes and dislikes, and I'd gladly join a discussion about it, but maybe not in this issue ;)

Just one thought about my personal K³ credo (or in English maybe C³, consistency, coherence, cohesion): For a user it doesn't matter too much, how the code magicians conjure stuff like - for example - an "overlay" or popup. Panels use such overlays, Skinr uses different overlays, then there's Markus Petrux' world of the (pretty advanced) Modal Frame API, D7 has overlays everywhere etc. To the user this is all the same - he clicks on a link or a widget and something pops up. Sadly all these approaches behave more or less different, determined by their technical fundament. It's similar with the placement of UI elements ("OK/Close" - left/righ or right/left?), cool widgets like Fusion's gear icon and that even cooler context thingy from Skinr2 which do similar stuff like the Panels controls, but not exactly the same, and they all do it a little bit different. The user simply has to do trial and error until he learns which icon allows which change in what place. Considering those K³/C³ criteria simplifies the UX, but burdens the developer with a lot of extra work. A company like Apple can simply enforce such guidelines, but in the FLOSS world it's much tougher (I can only guess what percentage of the 3.7k Drupal devs are being paid for their work; more extra work in the limited spare time needs much convincing to be accepted).

And there's a second aspect; spoken with my personal categories, modules like Panels and Skinr do not extend Drupal core (like 'Image' module or CCK does), but try to go beyond core. I've always seen Panels as a long term replacement fo the whole filesystem-based tpl.php layout concept of a static set of regions which might sometime become part of a D9/Dn core, but it isn't ready for that yet. It inherently needs to experiment with UI elements totally different to those used in core. I believe that this double nature (as well production tool as experimental playground for new ideas) is the special challenge for high- profile modules like Panels, it necessarily needs to break C³ with core for being able to go beyond it. Since Skinr (and probably Markus' Modal Frames, also) is fishing in the same pond, the UX between those different UI approaches probably will always be left behind. 'nuff said for today ;)

same here, I have no skinr installed, so I don't know how to fix this problem .

All the Fusion/Skinr users having troubles: Did you test it with skinr1 dev from october 22nd? On my test installs everything seems to be pretty fine even without merlin's patch.

@#17
Any additional information? Which theme? Tested with Garland?

Disabling Fusion and Skinr, then clearing cache fixed the issue for me.

Fusion/Skinr user here, skinr-6.x-1.x-dev @ oct 22 fixed the issue for me.

I really need some feedback on whether or not the patch helps. :/

Not exactly what you asked for but nevertheless:

Patch applies nicely with -p0 and using the patched version with skinr1 dev doesn't break anything (it seems). That said: I was using skinr dev and did not have any problems in the first place. So my "testing" is only semi-useful (at best).

Does Panels need to change anything when people could use the up-to-date version of skinr?

Hi,

I have Acquia Slate 6.x-3.0-beta1, Fusion 6.x-1.0, Skinr 6.x-1.5, on first upgrading to Panels 6.x-3.8 from 3.7 flexible layouts were all broken, with all panels appearing in a single column. Applying patch in #12 seems to have completely fixed the issue :). Thanks.

subcribing

I have the same issue with skinr/panels/flexible layout - are you saying we need a different version of skinr or a skinr patch? I know I am using 1x skinr.

where is this 'legacy mode deal' - what is causing panels to be in legacy mode?

for those of you talking ab fusion, i dont think fusion has anything to do with it, i think its skinr (which fusion uses obviously). i have a non-fusion theme but i do have skinr and it breaks all my layouts.

Either you patch Panels with the patch provided here OR you use the current .dev of skinr1. Glad I was able to summarize this issue for you.

If you go the patch-way please report back if it worked for you.

"Legacy" mode is because the style system had a very significant change made to it for Panels 3.7. In order to make older styles not just up and break completely, we introduced the 'legacy' mode. If the system detects that you have a style that was not updated to the later system, it will operate in legacy mode, which prevents newer features (i.e, IPE) that rely on the changes made to the system from working.

The problem we're facing right here, then, is that when I make changes to the system, those changes also get made to legacy mode. Sometimes little things slip through, because it's time consuming for me to do tests in legacy mode and not in legacy mode, and in this case, I failed to do that, or I would've noticed that I didn't properly update the legacy mode renderer and flexible's CSS file fails to get added because I forgot to copy the default setting of a variable from the standard renderer to the flexible renderer.

With a couple of positive reviews, this patch is now committed. Once the new -dev rolls (which I believe will be midnight, GMT) then updating to -dev should fix this problem for everybody.

The patch also worked for me, thank you. From # 12

Edit: After a few minutes, my panels are still broken... will wait tonight for dev version

Dev works, thank you!

If I may throw my two cents in here, I encountered this problem while porting a theme from an existing non drupal site. The issue is the same as described above, using flexible layout the regions in a row stack. I have tracked this down somewhat as the result of the panels generated css file not having any effect. I verified this by copying the relevant css for the regions involved into my style.css file and layout is correct, firebug does not show the generated css at all, only the entries copied into the style.css.

Theme is a basic page.tpl / style.css setup, no skinr or fusion involved.

I have tested this in a number of browsers: firefox, IE8, and opera and the results are identical.

One other anomaly: I tried setting css aggregation on in Performance and the layout was completely broken.

Just tested with the patched dev version and it did not help.

@#34: At a glance, that may be another issue altogether.

@Patch in #12: it works perfectly. Like most people here, I upgraded a staging site that uses Fusion and Skinr to Panels 3.8 today. The CSS for the panel was not being generated or included, but the patch fixed it all.

Thanks, the dev version worked for me now too.
Much appreciated.

For what it's worth, the contribs on the site I'm working on include:
Chaos tools 6.x-1.8
Skinr 6.x-1.5
Panels 6.x-3.x-dev
Views 6.x-2.11
and
Fusion 6.x-1.0
on
Drupal core 6.19

Setting back to fixed as the skinr-related problem is reportedly solved. However if the problem for #34 persists, cannot be solved please open a separate issue stating that your issue is NOT skinr-related.

*sigh* at #38

THIS IS NOT A SKINR ISSUE PEOPLE

Everyone who is insisting this is a skinr issue, please go back and read my repeated attempts to explain and quit propagating nonsense.

Given the fact that almost anybody here had this problem on skinr based installs AND that the problem can be solved by either using your patch (or Panels dev) OR using up-to-date skinr I don't think I am catching your flak for the right reasons. I changed the title to prevent people from reopening this when they have problems like #34. I am sure that the broader problem is indeed not a skinr problem but as I said almost everybody here had it due to skinr usage.

Peace, please! This one is fixed, and we all should be happy about it ;)

The problem is that the phrasing causes the authors of skinr to appear to be the culprits. They are not. I made the mistake, and I created the bug. It also can happen to people without skinr installed entirely, if something else causes legacy mode.

Really, things that cause the skinr authors to take flak over this issue is bad for everyone. They are completely innocent of this entire issue.

Ugh. Never thought of that way to read my change in the title. I only had practical reasons for the change and never wanted to create the impression that the skinr-crew is at fault here.
We should venture on anyways.

Thanks merlinofchaos. I'm happy to be able to advance to Panels 3.8.

this issue is 2 month old... why the module isn't up to date now?

@gregoiresan: Geez, this issue was fixed really quick, what do you expect? A new release for every minor fix?

Panels has excellent support, other module's maintainers don't even bother to respond to issues after a year. It shouldn't be too much trouble to apply the patch from #12 if this issue is biting you...

Sorry, the holiday season makes it difficult to do new releases, and I've committed very little to Panels. The issue affects a small percentage of people, so I elected not to create a new release just for it.

That said, expect a new release in the next couple of weeks in any case.

Hi,

#46 : Sorry, I did not want to look like complaining. I know that Merlin is doing great job and is very concerned about his modules. I just wanted to know if a new release was coming as I can't apply patches. I might not be clever enough to set up Eclipse correctly yet.

#47 : Thanx Merlin for your quick answer.

@gregoiresan: Applying patches does not require Eclipse or any other IDE, it simply requires the 'patch' command: Short introduction. It's really easy, just be brave ;)

@gregoiresan: Be brave indeed! http://drupal.org/node/620014