Same issue here with FireFox 3 in Vista.

Enabling caching does not fix problem.

Weird. When you see this happening, can you attach a paste of the HEAD of the sourcepage both when it is failing and when it is not? In it there should be a line to include a file in ctools/css with a very ugly css filename. During the failing instance, check to see if that file is there?

I'm attaching the ctools CSS files as well as the page source for both the fixed and the buggy pages.

The CSS files are accessible via their URLs after the buggy page is loaded. Though, to note, if I refreshed the page, they'd be there too. So if I load the page, find that it's buggy, and then I attempt to load the CSS file, it might have the same effect as refreshing the page. So the fact that they're accessible in that way does not mean they're being drawn in by the page.

I'm no developer genius, but I'm unfamiliar with the ?c on the back of a url like that:
/sites/default/files/ctools/css/4a1151955127fcbf185c57db56546d18.css?c

You can feel free to visit the our live beta site as well: http://forpeace.mayfirst.org/

Let me know what else you need.

Attachment	Size
buggy-ctools-css-4a1151955127fcbf185c57db56546d18.txt	1.66 KB
buggy-ctools-css-e268b682ec92a1748f3d075972dc1097.txt	2.46 KB
fixed-ctools-css-4a1151955127fcbf185c57db56546d18.txt	1.66 KB
fixed-ctools-css-e268b682ec92a1748f3d075972dc1097.txt	2.46 KB
source-of-buggy-page.txt	79.66 KB
source-of-fixed-page.txt	79.66 KB

Well,the ?c is supposed to help deal with browser caching issues. Except it seems like you're getting a browser caching issue of some sort.

Is your webserver running multi-headed or something? I can't think of many reasons this would happen, but if you've got multiple webheads and are using rsync (or something) to copy files from one to the other, that delay could cause this.

Here is my buggy head source, and the ctools css before and afters.

This test site is at http://www.bounceitblog.com

It seems that my tmp css file created by cTools on the bad run was BLANK. Upon refresh it actually generated some good code for it.

Attachment	Size
5252ceb276eba4fed9787f2749a5c19e.cssQ_.txt	0 bytes
5254ceb276eba4fed9787f2749a5c19e.cssQ on success.txt	1.25 KB
ctools.cssQ on success.txt	482 bytes
head-on-fail.txt	3.22 KB
head on succes.txt	3.22 KB
ctools.cssQ on fail.txt	484 bytes

Hmmm. Okay, now we're getting a little somewhere. On fail, that css file contains no css at all! But it does exist as a blank file. That is very odd! That gets us a step further, now we have to figure out why there's a blank file there. This explains why clearing the css aggregation fixes it, because that forces the css cache to regenerate.

Is there any more information I can get you?

Let me know if I can get you any more info as well.

Thanks!
Zach

Issue unchanged in beta4.

glass.dimly: Unfortunately, I never see this problem. The issue is that I have no idea how that .css file gets written completely empty. I'm not even sure how to debug such a thing. Perhaps what needs to happen is to go into includes/css.inc and check out the function that writes a css cache to a file. If it sees it trying to write an empty file, maybe dump a debug_backtrace() to error_log() ? -- this is obviously a little complex to do if you don't know PHP very well.

I turned on CSS optimization and it seems to have fixed it at least temporarily. Does this tell us anything?

Hm. I don't think so, because we know that a cache clear fixes the problem, so the blank .css file is not being written during recache, so CSS aggregation should actually reliably work around this for you.

I take that back, I thought CSS aggregation was working but I just got another broken panel.

I filed the same issue here #534358: Bizarre intermittent behaviour of panels. I added some screenshots which show the same behaviour.

Curiously I notice we are both using themes derived from bluebreeze.

Could the intermittent nature of this problem be related to cron?

http://drupal.org/node/534358 marked as a duplicate of this.

Worthwhile nugget from that conversation: A common factor is that the theme in use is bluebreeze.

Could that somehow affect things? I don't see how but I don't have any idea what's happening so maybe yes it could!

@glass.dimly are you working on a production site? would it be possible to see if you can isolate this behaviour on one of the core themes? I will see if I can have a go at this today as well.

I am using the "basic" theme and getting this problem.

Interesting. It is unlikely though that the theme has anything to do with it- maybe bluebreeze is just a coincidence here. Anybody had any more thoughts about the potential cause? Could it be related to cron?

That can be tested by manually hitting cron.php and seeing if anything changes, maybe?

I am experiencing this problem also, I only encounter it when not logged in.

If I am logged in, and then log out, the panels are not displayed correctly. However if I clear the cache before logging out, the panels *are* displayed correctly once I am logged out, but then if i refresh the browser they display incorrectly again! I have repated this several times and it always behaves the same way.

I'm using Pixture-Reloaded theme.

Yeah, I've noticed this is more common for anonymous users too.

It looks like Glass.dimly got this fixed on his site? I am still not having any luck. Any possible hack/workarounds?

Figured out what's causing this. It happens when there's a cron run.

It's independent of theme, the bluebreeze mention above was a distraction (garland screenshot attached).

To reproduce, create a panels node for a frontpage, run cron in a seperate window, and the as soon as you've run cron (i.e. while it is still running early on), hit refresh on the panels window, and the layout will be all messed up.

Attachment	Size
Screenshot-19.png	141.38 KB

I bet this only happens for *panel nodes*, then. I tried the cron theory but I rarely use panel nodes so I didn't check that avenue. Can you confirm that for me?

If it is, I bet it has to do with the search index.

Sorry I missed one extra detail, when refreshing the browser while cron is running, that browser must not be logged into drupal- i.e. it affects anonymous users!

I can confirm this is happening with Panel Nodes on my site.

Hey all, good to see some movement. I'd been on vacation and neglecting this issue. Next, I thought this was fixed after upgrade to rc1, as I didn't see it for a week or two after upgrading. However, I'm still seeing it on rc1. I've updated the issue to reflect this.

I'll upgrade to current in the next week. We're migrating data into the site, so the database isn't stable currently.

Our site is pre-production, so I can troubleshoot as needed. Chrism, if you need anything from me, contact me though drupal.org's contact and I'll get back to you as soon as possible with chat or phone number. You may also feel free to test your theory/run cron on our site: forpeace.mayfirst.org.

I can confirm that all of the panels which display this behavior are Panel Nodes on my site. I don't have non-Panel Nodes that I can test, but I will create some. This may be a key.

Second, previously, in beta3 and 4 this used to affect anonymous and authenticated users the same on the site. However, it may be affecting anonymous users with greater frequency, as I hadn't seen it until today when I saw it as an anonymous user (normally I'm user 1). Did something change in the treatment of authenticated users from beta3/4 to rc1? I'm not totally sure if beta4 only displayed this to anonymous users.

Third, I can't find any correlation to cron. That is, refreshing before, during, or after cron as an anonymous or authenticated user does not induce the problem on my site. I can't find a specific behavior to induce it, even clearing browser or site caches.

One last, I'm using Marinelli, not bluebreeze.

I can add to this that I am getting this issue on panel pages. It does appear to affect a page variant designed for an anonymous user - so non authenticated. I don't use panel nodes. At first I thought this was an IE quirk, but clearly it is not just related to this. I hope we can get to the bottom of this.

Hello, I've got this bug sometimes, I have to reload the page to have the correct display.

The problem appears when you load for the first time a page or after cleared the cache.
It's happen with all navigators (Firefox, Opera, Chrome at least).

This bug appears when I upgraded Panel 2 to Panel 3.

Disabling cron runs via Poor Man's Cron appears to be stopping this from happening.

I experience the problem and I don't have Poormans cron installed.

Like I said in post #22, there's nothing random or intermittent about it in my case and it's definitely not connected to cron. It behaves in a predictable way like I described, each and every time.

thiokol: Have you checked to see if your problem is related to the IE style sheet limit?

What's the IE style sheet limit?

The problem exists with firefox, I haven't actually tested to see if IE behaves in the same way.

The problem appears when you didn't navigate for a given time...

I should be a cache problem.

In admin/settings/performance

I've got: Cache mode disabled. (My website is not yet on production).

Everybody who get this problem could tell us if they have mode cache enable or disable please.

@Junro - all my cache's are enabled. As it's a production site, it is impossible to disable them. Furthermore, IE requires all my stylesheets to be complied.

@Chrism2671 ok, it's not about the cache.

Maybe it's about cron, on my webstite, I run it every hour with RSS feeds.
I don't have the problem if I run myself cron.php,

Every morning I've got the bug, and something during the day.
I've got it with all roles, Authentificated and Anonymous roles.

I've change the priority to Critical because I can't put my webstite on production with it, my frontpage and user profile are so ugly...

I agree with the update to critical. My website obviously can't go live with the front page in this state, either. CSS caching is disabled for me, which seems to increase the frequency of the issue.

I had this problem happen with and without CSS caching.

I've looked into this again, and it's occuring for both authenticated and anonymous users now, after logging in and out with various usernames, running cron, clearing cache etc, doing all of this several times over, I get exactly the same behavior as explained in post #22. Except now its happening for autheticated users also, I couldnt possibly pinpoint why, I guess I have maybe made a few changes recently that could have had an effect, no idea tbh.

I had orginally just used a different page for anonymous users, but it seems the panels only actually display properly for user 1 now (admin), so I've had to disable the module and look elsewhere for a solution on displaying the content how i want. I'd rather use panels, but hopefully it will be sorted soon :)

Its an odd problem, one thing to remember tho, It may be frustrating, but merlinofchaos isn't being paid to develop this module for any of you ;)

I am pretty sure I am having this same issue and may have some more details. I am encountering the same issue of the right panel falling underneath the left panel.

When I am editing a panel page and have Content tab open (where you add content to a panel) I have observed that it displays the the right panel region below the left region. If I save, the page displays the right panel below the left.

Now when I resize the browser window when I am editing the panel-page content. I have observed that the right content panel repositions it self next to the left. As I change the size of the window the right content region jumps back and forth between being below and to the right of the left content region. Similarly, I have observed that re-sizing the displayed viewed (note Edited) panel-page results in simlar behavior as described when editing the panel page.

This behavior is Strange as it does not happen for all layout styles, and does not occure initially, but after some time I suppose after some event occures. I do not know what even triggers the behavior. However I have observed that not all conten layouts exhibit the behavior.

Layouts that do NOT exhibit Behavior (Or at least havent durring my trials):

The two column staked
Single Column (obviously Lol)
Flexible (limited trials)

Layouts that DO exhibit Behavior:
Two Column
Two Column Bricks

I Do not know about the rest of the layout types I havent really tried them.

Work Around:
I have found that if you are using the Two Column and are getting this strange behavior, switching to the Two Column Staked fixes the problem and yeilds the same results as the unused Top and Bottom regions will not be displayed if thier is no content.
If you are using the two Column bricks... well I suppose makeing your own flexible layout may work :-/ I don't really know.

Anyway I hope this helps. It would be greate to isolate what is causing this. It is anoying and disturbing.

I am using Garlend, I think I have page cacheing, and I do have poormansCron running...

Changing to two column stacked makes no difference. Same behavior as before.

Always the same, if i clear the cache as user1 and log out, then log in as an authenticated user the panels display properly only this first time...refresh the page and its screwed up again, also screwed up on every subsequent visit. Repeat the process and the panels display properly again one time only etc etc.

btw - it was mentioned earlier about it being limited to panel nodes, this is not correct as I am using mini panels.

Could somebody try disabling all other non-critical modules (e.g. search etc), turn off caching, and work through and see if they can find a stumbling point.

My guess is that one of the modules that has a cron hook might be interfering- merlinofchaos suggested it might be the search module...

Ok. I am simply unable to reproduce this, using a variety of ideas. Whatever is causing this is simply not in play on my site.
Are any of you willing to give me UID #1 access to a site that is exhibiting this behavior? Maybe clicking around a bit on a site that is doing it might show me something more.

Search module is not enabled on my site, so that's not responsible.

Unfortunately I have removed panels and I'm using composite layout module to achieve what I need, otherwise I'd have been happy to give you the user #1 login.

Merlin, please contact me on the personal contact form and I will give you UID 1.

Thanks,
Zach

Merlin, you may also contact me for user 1 access to my site.

@merlinofchaos - likewise.

Ditto with the panel display showing up incorrectly. I DO have poormanscron running. Cache mode is enabled.

Also, I'm using a Flexible layout, so you can add that to the list of layouts that are being affected.

I've got Poormanscron too, but not cache mode disable.

I disable Poormanscron, I don't have the bad display anymore after running update.php.

But "avant de crier victoire" (French expression), I should wait and see if I've got the bad display again...

Every body having Poormanscron enable should disable it, and wait and see...

The problem is it's not just poormanscron but ALL cron jobs. Try running www.domain.com/cron.php and you'll probably have a similar thing happen. I've turned off cron for now, but that really doesn't work in the long run.

Running cron.php update.php, update module page manually since one hour, I definitly don't have the bad display anymore.

After 5 days with Poormanscron disabled, I never had the bad display anymore. I update my rss with cron.php and everything works fine.

I agree, since turning off Poormanscron, this issue has not reoccurred.

Haven't seen this in a week since disabling Poormanscron. Cron is now running just as a linux cron job. I'll post back whether or not this issue occurs, but I haven't been able to induce it. If I or my cohorts don't see it in another week on our site, I'll close this issue as resolved, and move it over to the Poormanscron issue queue.

Can anyone else confirm for sure that disabling Poormanscron does the trick?

I confirm.

I don't know what is the cause.

subscribing

Ok, so far poormanscron is getting a lot of attention as the culprit here. Is there anyone participating in this issue who has this problem and does not use poormanscron?

I was having this problem without poormanscron installed, but by reading through the thread I honestly think there is more than one issue at play.

I have exactly the same problem with my completly custom theme. Sometimes it seems that the css files are empty. After refreshing the error is gone. Very strange!

I don't use use poormanscron, and have this problem when not logged in. HELP!!!

Grrrrrr

Disable Poormanscron works only with autheticated users.

But I still have the bug with anonymous users...

http://us.pariscine.com

http://fra.pariscine.com

www.pariscine.com

But sure it's not always...

See if this patch helps? I suspect it will help for some and not others.

Attachment	Size
css-cache-clear.patch	668 bytes

Was just looking at Junro's sites and they all look fine to me, I'm just wondering if everyone experiencing this has confirmed the problem exists on a machine other than the one they use for user1, not sure if thats relevant at all, but it wouldnt be the first time i've thought I had an issue, clearing cache, logging out, clearng browser cache etc so that I visit my site as any anonymous user would, but i still got different behavior than other anonymous visitors did.

In saying that I vaguely remember this happening on my laptop as well as my desktop, but like I say Junro's sites display ok for me, and someone else posted about the problem earlier in this read whose site also displayed ok as confirmed by another user on the thread, just a thought!

I also have this issue for all users except User1. What is the procedure to implement the css-cache-clear.patch above? I'd like to give it a try.
Is this the definitive solution?
FWIW This issue is something that I just noticed today after installing http://drupal.org/project/seo_checklist and a number of modules on the seo checklist. Previously I had poormancron installed without this issue occurring.

It is not the definitive solution, it is simply one that might do the trick for some people. Search drupal.org for the phrase 'applying patches' -- the instructions are pretty exhaustive, I think.

http://drupal.org/patch/apply

Is there an alternate module to Panels that offers similar functionality (perhaps a basic level) but doesn't require patching?

I checked out http://drupal.org/patch/apply . As a Drupal and coding newbie I've no idea how to execute that command in the video and there is no Dummies Guide for patching as other commenters on patch/apply page have pointed out. Its a 2 minute task if you know what you're doing and worthwhile testing the patch if you do. If you don't know how to do it, it is a steep learning curve of hours or days to backtrack through and learn all the implied knowledge in the video to implement that 2 minute patch, all with a 50:50 chance that the patch won't work anyway.

If there was an alternative module with similar functionality to Panels I could try first I'd appreciate a pointer in that direction.

Cheers

AdamFX,

I understand your frustration. Panels is sort of the panels module for Drupal. Many modules depend on it and it's rather central. This bug is rather frustrating for all of us because it's not replicable, its erratic, and its difficult to trace.

We're working on it as we are able.

For me, the issue seems to have gone away when I disabled poormanscron (at least, I haven't been able to confirm it since then), so I won't know if this patch is effective.

You're right, patching is not an easy job for folks who don't use the command line much. I remember trying to apply patches myself when I first started Drupaling, it took a very long time and I wasn't sure if I had done it right.

May I respectfully submit that by patching your module and testing the fix supplied here, you are in a position to be quite helpful to the Drupal community.

Here are some other resources that might be useful to you:
http://indiawebsearch.com/content/how-to-apply-a-patch-to-a-drupal-modul...
http://community.contractwebdevelopment.com/patching-drupal-modules-in-w...

Thank you,
glass.dimly

Two cron jobs at the same time plus page load

Folks,

I was able to replicate this issue by opening about 10 separate windows and running cron in each of them, then refreshing the panel page while running these cron jobs.

Here is my best explanation of this:

The way I had poormanscron configured was such that it's cron job overlapped with my linux crontab settings so that at a certain time per day, they ran at the same time.

When I disable poormanscron, cron jobs only ran one at a time, and thus I didn't experience the issue after that point until today, when I ran cron jobs concurrently and refreshed the page.

I'll apply the patch and get back to this thread.

Peace
glass.dimly

I can replicate this issue with a two column stacked mini panel, after manually running cron.php in the browser. I don't use poor man's cron, and I have a custom theme. I tried the patch, and it didn't work for me. I also tried clearing both Drupal and browser caches, then refreshing the page without success.

ajs17: Can you make this happen every time? When you replicate it, is the .css file 1) missing or 2) blank? Also, are you sure this is the same problem? There's a similar problem that is IE-only that happens when you have too many stylesheets.

Its happening in Firefox and Opera, and I haven't been able to get it back to normal yet. I assume I am looking for panels.css? If so, its there, and has styles. I can send the output if you like. (Actually, I see there is also a stylesheet called twocol_stacked.css that also has styles in it.)

Thanks for your help!

Hm. Ok, I think you're experiencing a different problem, as you're not using generated css. The .css file I was referring to would be named with an md5 string. Would it be possible for me to see the site?

OK, I just opened the site up, the mini panel is on the home page:
http://test.staffweb.library.cornell.edu/
...and I don't see an md5 named css file. For what its worth, I turned on the 'optimize css' feature under site configuration -> performace briefly and saw no change either.

Thanks again for any help you can give. We really like the panels module!

ajs17: One of your pieces of content (I do not know which one) has an unclosed <div> tag which is throwing off the layout. Completely unrelated to this issue. =)

Well, I'm embarrassed but relieved. I'll check it out--I guess either the cron was coincidental, or I was looking at a cached version of the normal page. Thanks for the extra pair of eyes.

Folks,

I patched the ctools/css.inc file

and I was able to generate the same issue still with the method I described above.

That is, the patch does not fix the problem.

But hey, progress, I can replicate the issue to test patches.

-glass.dimly

I am also experiencing this bug. Thanks to the comments already posted I was able to track it down to poormanscron

I disabled poormanscron and the problem has gone away. I have not as yet enabled normal cron functionality, so I'm unsure whether that will re-introduce the issue, but I suspect it won't. I'm guessing it has something to do with the fact that cron is running as the page is loading that is causing the problem.

@ pfharlock

With autheticated user role, could you run cron.php (with poormanscon disable) and see if you have the bug please.

So the css file is included like so in the "page source" view:

What I've discovered is that when the error happens, these files are missing, not blank. If I put them into the URL bar directly after accessing the front page, I get a page not found error.

After I refresh the page and the error is eliminated, I can paste the URLs in and see the CSS for the files.

Mind you, this is with the patched ctools/includes/css.inc file.

How to replicate this bug

1. Open yoursite.com/cron.php in a ten or so tabs.
2. Open a panel page from your site in another.
3. Hit refresh on about five of the cron.php tabs (quickly!)
4. Hit refresh on your panel page (faster!)
5. Hit refresh on about 5 more cron.php tabs (with all due speed!)

If this doesn't work the first time, try it a few more times. You'll get it. Maybe even try refreshing your panels page again before its done loading and refreshing your cron pages some more.

For me, this bug only happens when two separate cron jobs were running at the same time.

I think the problem is as follows

* cron is clearly generating the css file in question
* the code that is generating the new css file and potentially deleting the old one is doing so in the wrong order.
* because poormanscron fires cron as the page is loading it make the bug very easy to notice.

What the code that cron is firing should be doing is
* generate the new css file
* only after the new css file is created does it direct pages to start using it
* it should also probably wait until the next time cron is run before it deletes the old css file just in case a page is still using it.

The .css files are not generated on cron. The .css files are generated on an as-needed basis. If it were as simple as pfharlock's description I would've been able to fix this by now.

The problem seems to be that cron is doing something to cause the .css files to be generated or deleted, but as of yet I am not sure what. I had theorized it was search reindexing with panel nodes, but that does not match the description of what some people are seeing.

AdamFX, try composite layout module

@Glass.dimly Thanks for the comment #71. I'll have a look through those pages you referenced. I also take on board your comment about learning then helping the Drupal community - I appreciate you and the other folks here as the example.
@ Thiokol #87 Thanks for the tip - I'll check it out also.

I apologize, I didn't mean to make the problem sound trivial or easy, and I would like to re-iterate what allot of other people have said above. I think panels is a great module and I really appreciate it and all the work you've done on it :)

Is is possible that one of cron's responsibilities is for cleaning up temporary files, thus when it runs the file disappears before the browser has a chance to use it?

It shouldn't. The .css files should only get cleaned up on cache clear. And the best part is that if the file does not exist, then it should automatically go and recreate it when asked. So it seems to me that there may also be some other caching involved; the HTML that utilizes the .css file is already cached somewhere, for example, even though the file has been removed by something else, possibly.

Hi,
Maybe useless, but here are the ways for me to reproduce the bug (at least the config) :
- Cache enabled (il also happens with other caching methods, such as Cache router)
- Poormanscron 1.x

1. Open a tab and run cron.php. Wait for it to finish.
2. Reload a faulty page.
It worked everytime, with any user role (even as admin).

I've upgraded to Poormascron 2.0 (backport of the Drupal 7 automatic cron), and I can't reproduce this bug anymore.

hi,
I have the same problem (I see the panels without style since when I click on "refresh").

I followed this discussion but I don't understand what is the correct method to solve the problem.

I realized that perhaps this form must be turned off Poorsmancron, but I keep it active because I need to index content for search.

I hope that you can suggest me the best solution to the problem. Possibly clearly (sorry but I do not speak English well :) ).

Thanks for the support

Marco

Hi Marco,
Just try using Poormanscron 2.0b

I've been getting this behavior randomly on some of my panels. It happens more often on flexible panels, but I've seen it happen with others too. I have fixed them always by going to edit the panel -> content -> update -> save. That has always fixed them for some time.

I have one panel which is kind of user's dashboard, which never breaks. it's a 33/34/33 stacked panel. Currently I don't have caching on and I'm using Pixture reloaded theme.

I also get this problem where the right column goes under left column.
Using the following:

1. Panels 6.x-3.2
2. Chaos tool suite 6.x-1.2
3. Layout Flexible 3 columns defined
4. Regular cron every 30 minutes, no poormans cron
5. Anonymous user
6. CSS cache can be on or off

Browsers Safari, FF 3.0, FF 3.5, IE 7, IE 8

To repeat: go to a non panels page logged in as admin, run cron, log out, go to the panels page, bingo problem occurs

Has anyone found a fix or work around for this?

Hello,

I believe I'm also encountering this issue.

I'm not using poorsmanscron, but it's on acquia and cron is being run by acquia (either 5 or 10 minutes).

Custom theme, base theme 960.

Not a panel_node; panel page.

I'm not sure if I've been logged in when it's happening.

(Since I'm only using panels for the front page, I think I'll just be making the css a permanent file in the theme till this is resolved).

Added a temporarly work around for myself till it is to disable cron cache clear (unless it's been a day).

Cron sets a semaphore using variable_set (how do 2 cron jobs run at the same time? Variable cache not changing in time before the second starts?) so can check that in hook_flush_caches and not run in that case. The second part copied from ctools_cron; need to have ctools run after system so the variable isn't reset (system_cron is what clears cache; it should run first as long as ctools weight isn't < 0 or put in a folder that is alphabetically before modules/system). Did only a bit of testing but looks okay temporarily.

Subscribing

I'm going to guess this problem is closely related with the following issue report:

http://drupal.org/node/626562

Which states:

"""
Occasionally a page with a flexible layout would be displayed to anonymous users without any styling, but only if Drupal caching was enabled.

This was an extremely frustrating bug to diagnose as it was hard to reproduce consistently. It may or may not be a duplicate of the issue described in http://drupal.org/node/539228, but note that I am not using the poormanscron module.

I finally managed to nail it using FireBug's Net module which reported that the ctool's CSS link was broken. For some reason this file expired while the page was still cached by Drupal. This happened regardless of the cache TTL, but it was hard to catch and reproduce until we increased TTL to 1 hour, which may explain why people are reporting that display problems may "go away" on reload.

Until this is fixed, a simple workaround is to include the CSS in the missing ctools file directly inside the page template in your theme.
"""

I can say I was also getting this problem.

My Set Up

• Panels 6.x.3.2
• Panel Pages
• Flexible Layouts
• Normal Cron (not Poormans Cron)
• Performance = All Caches -- Including Drupal's Minimum Cache Lifetime of 1day

The panel layout was being broken only for anonymous visitors. If I was logged in, it would work just as expected. Looking in the error log, it was mentioning the css files located at /files/ctools/css could not be found. Also, it would only affect certain pages at certain times. Some of the pages would look fine, others would be broken.

I have turned off Drupal's Minimum Chache Lifetime (set back to none), as suggested by lirazsiri most recent post. It appears to have solved the issue, but may not be the best answer for some sites. I will report back if the problem comes back.