Hi I am using panels 6.x-3.x-dev. Everything work great. One problem that we have been having is that randomly our homepage will just display a white screen. When I go into edit the homepage panel, all the content and sections are missing. The way I fix is by clearing the cache. The problem with that is that I am using this on a high traffic site and when I clear the cache the server load gets super high and I have to redirect traffic and load the page manually by ip to rebuild the cache. Any help is much appreciated.

Quick fix

A quick fix is to put this at the end of your page.tpl.php (after </html>):

<?php if (empty($content)) drupal_flush_all_caches(); ?>

Comments

Same problem, marking this http://drupal.org/node/984148 as duplicate.

(from my original post now marked dupe)
I'm not sure if this is related, but I have a panel page (as my homepage) that has a mix of custom content panes and views. The views are all blocks and have caching turned off. Randomly throughout the day, I'll visit the homepage and the only data that displays are the custom content panes, the views don't show. If I clear the cache using drush, then the views re-appear. Latest devs of all modules.

Might be related to this, not sure:
http://drupal.org/node/813646

Priority:Normal» Major

I'm bumping up the status on this one to "major" since we now have two users seeing the same issue, and it basically results in empty site homepages. We are not using any cache except for css in our environment. But clearing the cache does fix the issue, albeit temporarily. I'm wondering if it has to do with IPE pages?

Hey @pwarterz, are you guys using a fusion based theme and skinr by any chance?

No, custom its a custom theme.

No, custom its a custom theme.

This is also happening for me; custom theme and panels for the home page. Have tried a few things but it seems only flushing all caches will temporarily fix the issue.

Grant

This may be related. I upgraded from 3.7 to 3.8 and my homepage panel went blank. Flushing the cache did nothing though. I had also upgraded chaos tools.

I fixed it by basically resetting my homepage destination in site info. Changed it to node, then back to the alias of the panel.

Priority:Major» Critical

This is so odd. Flushing the caches actually causes the problem for me, not fixes them. I have to do what I said above for a temp fix. Then if I flush caches, goes back to being blank. If I edit the panel, all of the content is indeed there.

I'm moving this to critical in hopes to get a bit more attention on it. I'm going to go through the the last update to see what is up with it.

Are you using the development version of chaos tools?

No, I'm using the latest stable. I also noticed that it has nothing to do with it being the homepage panel. I changed my homepage to something else, went to view the panel - and it's fine. But flush the caches, and bam it's gone. There is no caching being utilized at all within the panels or views included in the panels. I'm going to revert for now

Okay, I figured out that my issue was due to a Skinr update.

Last night I updated a ton of modules on my site, including Panels, Ctools, and Skinr. I reverted Panels and Ctools and that didn't fix anything, so I tried Skinr (because it was mentioned in this thread), and that did the trick. I'll post an issue with Skinr.

The Skinr version with the problem was 1.6 from Nov 10 and I reverted to 1.5.

Priority:Critical» Major

I understand this is a difficult and gnarly problem, but bumping the priority isn't going to get more attention on the problem - only cloning merlinofchaos, sdboyer, or finding someone else who is knowledgeable and willing to dig in is going to get the problem solved sooner. Given that it does cause a serious problem, but *can* be worked around, this still fits under a major.

I'm not sure there is a workaround, and it seems to happen if skinr isn't being used. On the first cache clear, some if the panel panes are empty. But the secon cache clear fixes it. Odd. It's interesting that the views panes are the ones that disappear. Any custom content panes still show. I wonder if it's a panels / view cache related bug? Or views are set to not cache as well. Clearing the cache once breaks it, a second time fixes it.

Maybe your problem is with Views itself. There is a bug in Drupal core that causes template preprocess functions to not necessarily be automatically loaded properly, particularly when using Views' theme patterns. IF it happens to views, do they share common styles, for example? Or are they using core Views styles?

I'm thinking it is with views, just weird that two cache clears fix it. First one breaks it, second one fixes. Do you have link to that preprocess bug report -- maybe it's affecting more than just me for this ticket, assuming lots of folks have views on their homepage. It's interesting cause it does seem to kill all views on the page, but leave the other content panes alone.

For me all panes, blocks, and custom blocks disappear from the panel configuration. If I clear the cache everything comes back.

I wonder if it's a memory issue. When re-creating the panels / views cache does it run out of memory the first time?

I don't believe it to be a memory issue. My server has 24gb of ram and my php settings are set pretty high. Also I use a panels on every other page on the site and it only seems to happen on the home page. The site is www.wbez.org.

Right, I've only seen on the homepage as well. Anybody else seen anywhere else?

We can also confirm this issue so far on two customer sites but they run both 3.7 and 3.8 so I'm not sure where the regression might have been introduced but same problem. Random white screens on any page that uses Panels (but not on /user or /contact for example) - Cache clear immediately fixes it. Very interested in this. I'm inclined to mark it critical since it has such a broad impact but, again, can't confirm a root cause as of yet.

I don't see why this isn't critical as well. It's a bug that causes a complete homepage failure with no known work around except clearing the cache. I'd vote for the status upgrade. I'm also digging into the code looking for a solution.

Priority:Major» Critical

I don't mind marking it critical for the reasons stated, but it unfortunately seems difficult to actually identify what's causing this.

totally understood, next time it happen I will see if I can find some info, thanks merlinofchaos! Anything you want me to do when it happens?

Perhaps if we review our MySQL bin logs (assuming those are enabled) for a site when it's down, it could be of use. Specifically the writes that take place just prior to a white screen to all panels and cache tables? Your call, Earl. Not sure what would be best here. I don't know what changes have taken place in >= 3.7 other than IPE being introduced. I went ahead and disabled it on both reporting sites.

Merlinofchaos, anyplace you'd suggest we look for probably culprit? Any advice is appreciated. It seems like an old cache is getting used, or the cache is being rebuilt partially. Not sure. But the fact that a cache clear fixes it makes me think that the cache is corrupt for the view or panel.

We are seeing this problem too on a major site, and we found that it may be caused because at random times are themes are being disabled and/or reset to default (garland) so custom layouts from our custom theme are not being found and causing a WSOD. Was wondering if anyone is experiencing a similar combination of issues?

This problem happens on all of our pages (which all use panels with custom layout plugins).

And here's a link describing the theme issue: http://drupal.org/node/305653

Thanks,
M.

I seem to be having a similar problem using custom layouts in my theme.

When I drush cc all, some of my panes disappear. If I update and save the panel, they are still missing.

I can get the panes to reappear by doing the following:

1. edit mytheme.info, comment out the plugins[panels][styles] line
2. drush cc all
3. edit mytheme.info, uncomment plugins[panels][styles] line
4. drush cc all
5. reload page in browser

I'm going to dig into this a bit more. It doesn't seem to be happening with non-custom layouts.

After poking around for a while, I have fixed the problem that I was having, and suggest the others in this thread investigate my proposed solution.

The disappearance of panes/regions was due to the panel being rendered in legacy mode rather than standard mode. The mode appears to be determined by the ctools plugin API version. For modules, this is defined with hook_ctools_plugin_api(). For themes, this is defined in the theme's .info file.

Unfortunately this isn't yet well documented -- see remarks here: #865840: How to upgrade a style to be legacy free

Leaving issue active until other issue participants can confirm whether the API version is indeed the cause.

As an initial test, I added

; make sure panels never trigger legacy mode
api[panels][styles][version] = 2

into my acquia_prosper theme info file. Now, I can clear cache with drush 10 times in a row without ever having the homepage panel lose blocks. It used to be that just clearing cache would sometimes cause this. So, fingers crossed. I'll post this over on the fusion issue queue so they know to add this line. I still need to check modules that provide styles. Thanks for the help!!

EDIT: It's still happening. I need to see if any modules are causing this as well. I've already checked skinr, but I wonder if even the core fusion themes need to be patched?

Interesting: Can folks experiencing this issue confirm whether or not they are running in legacy mode?

I was in legacy mode when I had issues

My status page says I'm and not in legacy mode. Thanks.

I am not in legacy mode either.

We have confirmed the legacy fix seems to fix it for me. Although we don't get the report of running in Legacy mode, the snippet suggested in #29 works for me.

That said, is anyone experiencing this issue that is -not- using a theme with custom panels layouts? i.e. Just core Panels, CTools, and a non-layout providing theme (like Garland)

I am using a custom layout.

I have a feeling more than one thing is going on here. It's interesting, when we lose the homepage, our custom panes come through fine. But, blocks created by views do not, they disappear. Clearing cache both fixes and causes the issue.

@schaub123 The culprit is that ctools cannot load the include files at theme registry build time and when it goes to look in theme cache later for them, it comes up short of the file and returns null. That then bubbles up the chain to whatever made the call.

The blocks created by views. I assume these are mini-panels? They go through a similar load process.

It's a big process. But if anyone is interested in seeing what's involved review the plugins.inc file of both CTools and Panels.

@webkenny Interesting info, especially since it happens randomly. I'm wondering if this might be caused then by a lack of memory or resources. Say the theme registry doesn't complete its build due to a timeout or lack of resources, then you have no cache for certain items as you said. I wonder if there's a way to manage updating the theme cache. Or maybe it's truly just a memory issue on the server and we need to allocate more. I did add the code from #29 into my parent fusion theme and acquia_prosper. Since doing that, I have seen it less or maybe not at all, but it's hard to say.

We are getting this on two major high-traffic sites as well. We also figured it was likely something in Ctools, but we thought the cause might be the database temporarily (and we're talking for fractions of a second here) going away - just for long enough for Ctools to read theme .info files instead of the database. This is little more than an intelligent guess for now, but here's the thinking:

_ctools_list_themes() in includes/plugins.inc tries to get a list of all themes using the core list_themes() function.

When it has an array of theme objects back from the core function, it checks the status property for each theme object and makes sure it is enabled before including any plugins that theme might contain.

The problem could be that the core list_themes() function returns the contents of the themes' .info files if the database is not available (no active db leads to separate call to _system_theme_data() which reads and returns the contents of the info files):
http://api.drupal.org/api/drupal/includes--theme.inc/function/list_themes/6
http://api.drupal.org/api/drupal/modules--system--system.module/function...

If this happens, in effect $theme->status == null for all themes... the status property does not exist in the context of the info file. Oops! Ctools thinks the theme is (in fact, *all* themes are) disabled, even if they are not, purely because at the instant it tried to access the database there was an outage.

Now, if this is cached aggressively then it gets worse - that can persist for a long time. So (and this I'm not sure on) if the result is cached, then that would explain why a cache clear works, forcing Ctools to check again for enabled themes. Since the db outage was very short and just happened, by freak chance, to occur when Ctools was checking for enabled themes, then normality should resume (unless, of course, lightening strikes twice).

This is really untested, it's just a theory from looking at the code and what might cause Ctools to view themes as disabled.

Thoughts? A simple test would be to remove the call to list_themes() and replace it with a direct db query on the system table instead, just to see if that resolves the issue.

We have been asked to move all Ctools plugins from themes to modules for now, as this also neatly side-steps the problem. Our client is obviously not willing to test this 'live', but if someone else likes the theory and thinks they can... well, I'd be curious.

Subscribe.

subscribe. not having this problem currently but wanna keep tabs on it in case we do

I'd LOVE feedback on greg.harvey's theories because that's some really valuable insight and it is definitely the direction that I'm thinking.

Some additional info for our panels whitescreen problem (that greg mentioned above):

1. This seems to only happen when memcache is enabled. Disabling memcache for Drupal caching cures the issue.

2. We get these errors in our watchdog log during the problem: "Layout: XXXX_onecol_half couldn't been found, maybe the theme is disabled". This repeats many times for our custom layouts. So this seems to happen to all layouts at once. Clearing the cache fixes the problem.

3. When we run a drush sm while the problem is happening, our theme is enabled, and a drush st shows our theme as being default.

4. We have some evidence that moving the layouts out of the theme won't work either. We will be testing soon.

5. We have a script that monitors the page size of our homepages. If they fall below 30% of their previous size, we clear the drupal cache. A total hack, but it has worked.

I've looked over the panels and ctools code. What is unclear to me is when does CTools decide to forget the previous cache and build a new layout cache? Could multiple workers try to rebuild this cache at the same time, with disastrous results? Why are we only seeing it with memcache? Because the database is slower?

Very interested to heard what you all think.

Sense I added the API version to my info file we have not seen the problem. We not using memcache, but we are you APC. I will update if it happens again.

Same here. The API version seemed to do the trick for our problem sites. Also not using memcache.

Subscribing.

The API trick isn't absolute. It can still happen if the memory or resources go low during the cache rebuild.

It can still happen if the memory or resources go low during the cache rebuild

@schaub123 And would thus invoke a PHP memory_limit exceeded error? How did you diagnose that memory would cause this problem?

Raised a core issue in relation to my theory in #39: #1058198: We do not need to call _system_theme_data() when the database is not available

I'm still not sure if this is really the cause of anything, but the logic stands, so until someone is able to properly test I think it's worth examining list_themes() in core too.

I have same issue.
WSOD randomly appears.
I have custom layout (in my custom theme).

I figure out next.
In function ctools_plugin_load_includes(it's called from panels_get_layout() function) from module ctools (file ctools/includes/plugins.inc)
We have this string
$cache = cache_get("ctools_plugin_files:$info[module]:$info[type]");
And in $cache i have no my custom layouts.
So seems while this cache setted up, information about my custom layouts are missed.
As a result my layout not found, and this case works:

class panels_display {
...
function render($renderer = NULL) {
$layout = panels_get_layout($this->layout);
if (!$layout) {
return NULL;
}
.....

To add another data point that does confirm it has something to do with themes not being available. We've been using themekey and then just switched to sections. I am noticing that whenever a theme switch happens, then the cache gets corrupt right afterwards and the homepage has missing panels.

I also have the line ...

api[panels][styles][version] = 2

in each of my theme info files.

We had this problem on a major site and it would appear that moving the custom styles/layouts outside the theme into a module solved our problem.

Could somebody post a stub of how to move panels layouts to a module. I think I've got it from looking at the panels module, but an example would be cool. Maybe even for doc? Thanks for any help.

Nevermind, found it in the ctools docs!

Ok, I've moved the layouts into a module -- still see it happening. There are no layouts in my themes. Now, I have a few styles since we're using Acquia Prosper, could that be causing it? Our skinr is a recent dev to get around skinr issue.

I don';t think it is aquia prosper or skinr. I don'tt have either installed.

I commented out the panels styles in the theme, still no dice.

Has anyone tried the suggestion in #39? merlinofchaos seems to agree this might well be at least a part of the problem. I don't think thrashing about will resolve this bug - folk can forget about "getting lucky". It needs methodical testing by somebody who can reproduce the problem consistently, if we're going to squish it.

Well, I've disabled all layouts and panels stuff in all of my themes, moved them out. So, if that was the issue, then #39 won't fix it. It was mentioned that doing that side-stepped the issue, but I'm not so sure. But I will try moving out that function and doing and sql query instead. I'm really thinking that the cache is not being totally re-built due to memory limitations at any given time. But I'll try #39 too.

Subscribing - getting similar problem when applied recent security update. Will test with upgrading modules individually to see if that sheds any light on this situation.

Could this be server related? We are seeing a similar issue, but only on one server. On a panel page, everything loads on our site except for the panels. Requests are going through one varnish server, which load balances the traffic to two web servers. Those two web servers are also using one memcache server. Currently, we're unable to figure out what is different between these two web servers. When we restart memcache, the issue resolves itself, but comes back later in a few hours on that one server.

Can you stop memcached without the site falling over? If so, does that make the problem go away?

We haven't tried that, but we finally figured this out. Using phpinfo(), we saw multiple sessions open for the same user on the web server that was giving us an issue. I reported this to our server guy and he looked at the APC cache ini settings on that web server. He added the following to the /etc/php.d/apc.ini file:

; Enable apc extension module
extension = apc.so
; Options for the apc module
apc.enabled=1
apc.shm_segments=1
apc.optimization=0
apc.shm_size=32M
apc.ttl=7200
apc.user_ttl=7200
apc.num_files_hint=1024
apc.mmap_file_mask=/tmp/apc.XXXXXX
apc.enable_cli=1
apc.cache_by_default=1

This appears to have solved our issue. We've gone about half a day now without this panel issue popping up - usually, we would have seen this issue pop up within an hour or two. Will update this queue if this issue pops up again for us.

Ok, I think our issue was still caused by Skinr -- I found a panel region where it was set as the style. I changed it to "No style" and now the pane is not disappearing. I'm using the version of Skinr which is supposed to play nice, not force into legacy mode. But there still seem to be issues. So, if you're seeing panel panes disappearing, or view blocks, remove skinr or change the style of that pane/region to not use it. I think this thread is still pointing out an issue where a true WSOD occurs with panels, but maybe it's related to APC or memcache which do similar things? Not sure why that would be the case, but we are not running either.

I think there is maybe more than one issue at play here then. Because I just heard from a customer on one of the sites I worked on exhibiting this behaviour (the one prompting me to write #39) - the site does not use Skinr and never has - and he reports that, to the best of his knowledge, moving the panels layouts to a module solved their issue.

I think this issue might actually need splitting.

I think the skinr problem is because it keeps its hook_ctools_plugin_directories in file that is conditionally loaded, and there are cases that seem to cause a plugin cache rebuild *before* it is loaded. At that point, skinr styles disappear and any panels using them go blank until cache is rebuilt. I thought I submitted an issue in skinr module for this but I can't find one, so I guess I still have to do that.

I'm pretty sure it's separate from the themes going missing issue.

Wanted to report that the issue with blank panels has resurfaced after our APC cache changes. There's something else going on here...

What's odd for us is that it's been almost a month sense I added the api version to our info file and have not had any problems. I also would like to make note that about two weeks ago we downgraded from php 5.3 to php 5.2.
Our configuratoin:

Hardware:
Dual 6 Core Xeon processors
24gb of ram
64gb solid state drive

Software:
Ubuntu 10.04 64bit
Apache/2.2.14
Mysql 5.1.41
APC 3.0.19
apc.shm_size = 100
99% Hit
PHP 5.2.10
post_max = 512MB
memory_limit =512MB
max_input_time = 120
max_execution_time = 4000

Maybe looking at configurations we might see if it's memory issue. Granted we do you have a pretty tough machine but we sometimes get close to using up all of our ram.

So we've disabled our APC cache. This fixed our issue.

Do you know if your APC was running out of memory? What is your shm set at?

We've re-enabled our APC cache because we also saw this missing line on our problem server in /etc/httpd/conf.d/mod_fastcgi.conf:
LoadModule fastcgi_module modules/mod_fastcgi.so

We've added the line above and hope this will fix the issue. I pasted our APC settings in comment #62. Our shm is set to 32MB.

Have checked to see if you are using up that 32mb

I pinged our server dude. He says he hasn't checked, but he highly doubts it and that it should recycle anyways. Currently, we've disabled the APC cache and we're running into the same problem, so this is definitely not an APC issue for us. So we're back to square one.

Okay, so we finally figured this out and were able to reproduce the error as well as reproduce the solution. This was entirely unrelated to memcache, APC, or fastcgi. We have a panels-pane.tpl.php file that's nested inside /sites/all/themes/theme-name/tpl/panels. We also have a preprocess function called theme-name_preprocess_panels_pane(&$vars). Inside this preprocess function, we had to add this

$vars['template_file'] = 'panels/panels-pane';

to let Drupal know to use this template file for theming within that panels directory. This fixed our issue. Sorry for the APC, memcache, fastcgi runaround.

So, I've gotten some more insight into this issue. Our code wasn't being deployed correctly to the server in question. On one server, the tpl file was in a different directory than the other server. The blank panels were showing up because the template file couldn't be found. The site on the other server had already registered the template file path, which didn't exist on the other server.

I had the issue come up when moving the site from my local development machine to a webhost.

I was able to clear this issue, but it took some brute force to do so. What I did was disable everything down to and including chaos tools, then used the uninstall tab for all chaos tools modules (I did not uninstall any panels modules, I only disabled them). When I brought everything back up, the white screen on login issue disappeared.

At a guess, chaos tools was caching something.

Our site is getting wsod on the homepage as well, nothing appears in php error log. Wsod occurs very ramdomly and what exactly triggers it is still unclear. Also the wsod returns a 200 OK code.

However it seems the following query (always) clears the issue for us:

DELETE FROM `cache` WHERE `cache`.`cid` = 'ctools_plugin_files:panels:layouts'

We are running:
Core: 6.20
Ctools: 6.x-1.8
Panels: 6.x-3.9

I was the original creator of this issue and we have not seen any problems since we have done the following.

1. Added the Api version to our theme info file as noted in post #29
2. Upgraded to the latest development release of panels and ctools.

We have not seen a WSOD in about 4 months. We are a high traffic site and I think one of those fixed our problem.

Subscribe

When I clear my cache using zeropoint I get no more panels content and I cant edit a panel....

subscribing.

I've been experiencing this as well on a site with:

  • Drupal core 6.20
  • Panels 6.x-3.9
  • Chaos tool suite 6.x-1.8
  • Views 6.x-2.x-dev (2011-Apr-12)
  • APC
  • no Skinr
  • no memcached

It seems to have begun happening after updating core and a number of contrib modules -- including Views, but not CTools or Panels.

It's only happening on a panels page that uses a custom layout defined in my custom theme. Other panels pages using default layouts have not exhibited the issue. Clearing the cache fixes it... temporarily.

I haven't figured out how to intentionally trigger the issue to test possible solutions. It's happening frequently enough to cause major issues with the site, but not frequently enough to test very reliably.

I've just added api[panels][styles][version] = 2 to my theme's .info file and will report back.

I had the same problem. It was solved by disabling the Optimize JavaScript files: & CSS under drupals performance to recash the panels. Once the panels were recashed i reenabled bw optimization

by the way. If the settings under bandwidth were disabled then enable them and disable them. Whatever happens in the process puts the panels back in the output

Subscribing, also having this problem.

After cron run certain panel panes just disappear (though not all). This is a panel page being used as the site homepage, and with a custom panel layout defined in the theme. Flushing the cache after the cron run restores the missing panes.

I've tried the things suggested in this issue such as turning on Optimize CSS & JS, block cache, tried without all of that, tried api[panels][styles][version] = 2 in the theme's .info file.

We use:
Drupal core (6.20)
Panels (6.x-3.9)
ctools (6.x-1.8)
views (6.x-2.12)
acquia_marina (6.x-3.1) as the admin theme
fusion core (6.x-1.0)
skinr 6.x-1.6

If anyone wants further info I'll provide it.

Edit: Forgot to add, no varnish, memcache or op-code caching is implemented on this dev box.

This might be related to the problem that I was having here #1113614: Panel disappears on menu rebuild - page rendering, panels just...not. It was related to the well-known-but-still-mysterious theme-getting-disabled-during update issue. In our case certain panels (mostly the frontpage, but some others too) were getting b0rked. It wasn't the entire page WSODing, just the theme areas disappearing, but that could be because I have specified an alternate default theme in settings.php - so the panel section showed blank but the rest of the theme rendered.

Turning off the Updates module fixed it (we have a dev server anyway that tells us when it's out of date, so the production site has no need of the module).

Hope this helps somebody.

@Reinette tried turning off Updates module and running cron and it still happens :(

@alli.price - Do you have memcached running on the server? I have this issue on a server with memcached.

If you have a large panel with lots of content panes on it, and you don't have enough memory allocated to memcache that could possibly cause a white screen. I have been following this thread for some time and it seems like panels is truing to cache a large amount of data and sometimes it just craps out. Like runs out of memory.

I have this issue on a server with memcache set to have 1G of memory allocated for it. I also see that memcache usage hovers around 50-60%. So I am not sure about the possibility of memcache running out of memory

(just brainstorming) Could it be that the memcache Panels bucket is being filled by one page request while another is trying to clear it, causing a collision?

@zyxware nope no memcache.

I've got another site running the same kind of setup with (same modules, etc) which has older versions of the modules and is fine, tempted to roll back some versions...

I've narrowed this down to a single cache entry:

theme_registry:acquia_commons

(I've upgraded to Commons 1.5 on this site)

Clearing the cache or running cron results in *some* panels being empty - html structure but no content. If I delete just that single entry, it is regenerated and works properly.

Following-up on #80, adding api[panels][styles][version] = 2 to my theme's .info file seemed to work for awhile, but I just got the white screen again -- 26 days later...

Not sure whether I should open a new thread since this happens to me as well but on Drupal 7. But it only started after the security update to Drupal 7.2.

Actually, I can reproduce it: every time I run update.php, the two panels I have do not contain any content. Both panels include one custom panel and one Views panel. Flushing the caches always restores the panels.

I can repeat this several times in a row and it always does the same thing; run update.php, panels are gone, flush the cache, panels are back.

@Pillhuhn, I think you should start a new issue, especially since you can consistently reproduce it. That seems like a different issue.

Thanks Greg!

I did already here: http://drupal.org/node/1172138

Everything here points to a bad theme registry build where the layout theme ends up not being available, presumably because at the time the theme registry was built, the layout plugin was not available. It is not yet clear why the layout plugin was not available at that time.

Yes, that's exactly what I believe is happening. I think there is some subtle core bug here, tbh, but no one seems to be able to identify exactly what. I think my post in #39 is maybe warm, but the problem is I have not had time to test it properly, mainly because creating an environment to mimic the conditions that make the bug manifest is pretty time and resource consuming. =(

We have this problem and also seem to have another problem with cache. Not sure whether these are related but thought this might throw some light.

Here is the issue that describes the related problem that we have - #1174676: Variables cache is being lost

I'm having this problem as well -- in a way very similar to @Marzuk in comment #91:

  • If I clear the cache, my panels content disappears (for me running cron is OK)
  • No amount of clearing the cache will make it return!
  • However, if I remove "theme_registry:mix_and_match" (that the theme I'm using), the panels will return.

I'm about to experiment with the suggestion in comment #39.

StatusFileSize
new858 bytes

Attached is a patch where I attempted to implement the test that greg.harvey describes in comment #39. Greg, did I get it right? The patch is against the latest ctools 1.x dev.

Unfortunately, it doesn't help. I can still recreate my problem exactly as I describe in my last comment. Let me know if I did something wrong!

I'll going to keep testing...

Regards,
David.

My variation of this problem is skinr-based! I still haven't found a solution, but comparing the good theme registry and the bad theme registry, shows that its the skinr theme functions which are missing!

For reference, see these documents in PasteBin:

This shows that the following theme functions are missing:

  • panels_skinr_style_render_pane
  • panels_skinr_style_render_region

I suspect that this is the problem that merlinofchoas referred to in comment #65. Next, I start trying to track down a corresponding issue in the Skinr issue queue -- and hopefully a solution!

I hope this information will be helpful to others trying to solve this problem.

Regards,
David.

The problem that merlineofchaos referred to in comment #65 turned out to be the culprit! I was able to create a patch that amounts to an ugly hack to fix it.

I couldn't find any existing tickets in the Skinr issue queue about this, so I created a new one with the patch. Hopefully, we'll be able to come up with prettier solution there!

Regards,
David.

We aren't using the skinr module but we are using the zen theme and have multiple subthemes throughout the site. Does zen behave the same way as skinr? I am specifically referring to comment #65.

@elvis2: This thread is about several different problems which, unfortunately, all the have the same symptoms -- cache clearing breaks (and sometimes fixes) panels pages going blank.

I recommend doing the same tests that I did in comment #100 and comment #101:

  • Try greg.harvey's fix - there is a patch attached to my comment. See if it makes the problem go away.
  • Compare your theme registry when the problem is present and when it isn't - if you use "drush" do the following commands from the command line:
    # When the problem isn't happening, capture a copy of your theme registry to good_registry.txt
    # (This is assuming your theme is "garland" - replace with the real machine name of your theme)
    drush ev 'print_r(cache_get("theme_registry:garland"))' > good_registry.txt
    # Then, when the problem IS happening, capture a copy of your theme registry to bad_registry.txt
    drush ev 'print_r(cache_get("theme_registry:garland"))' > bad_registry.txt
    # And finally, get the differences between them
    diff -u good_registry.txt bad_registry.txt

Post a comment here with the results of both those experiments. It's possible that the first one could just fix it, if that issue is your problem. If not, the second one may point to the cultprit if it's similar to the problem that I experienced.

Hope that helps!

Regards,
David.

@dsnopek, thanks. We did a diff and it looks like the only differences is the array structure. For example, the good registry has ctools_collapsible array closer to the top than the bad. That is one example, there are several differences like that. But, each registry output has the same array keys and values.

I am going to try the patch next.

@dsnopek Your patch for skinr http://drupal.org/node/979912#comment-4668928 worked great for me! I did try the patch in comment 100 but that had no effect.

Thanks!

@alli.price: Awesome, I'm glad it worked! When you get a chance, please comment on the issue in the Skinr queue: #1203390: modules/panels.skinr.inc not loaded during theme cache rebuild sometimes. The more comments there, the more likely this will get the attention of the Skinr developers and maybe we can get a real fixed accepted.

Subscribe.

This is just an update to our occurrences of missing panels content. I hope someone finds this useful.

First, we are running on pressflow 6.17, views 6.x-2.12 , panels 6.x-3.9, ctools 6.x-1.8. We are using the mysql innodb engine. We also run a replication db server, which is on a different host. We are not using memcache or varnish, but we are using apc.

In our case, we originally assumed this was a cron + clear cache issue. Here is what we thought was happening. Cron is ran during a time when traffic spikes. Cron is truncating cache tables and rebuilding the menu_router table. Suddenly, users hit a page during the cron run (the pages that have missing content are taxonomy/term/% panel) where either the menu_router row is missing (because it is being rebuilt) or the theme_registry theme functions that the panel is calling does not exist yet in cache, or something else down the thread of called functions / theme functions were not recognized yet by drupal.

At first, we could not produce these weird results on our dev server. But, using apache bench, we simulated a high load of traffic for 5 minutes, while clearing cache from the admin_menu option. Though we could not duplicate missing content, withing the panel output, we were able to see a strange layout - once the server had a high load. For example, we use the grid layout for each node within our panel. Our nodes were node displaying in a grid layout, more like a list. And, the left column along with the main content in the right, the content was fragmented, parts of content were not showing or things were showing (like field lables) that were not supposed too.

So, we figured we would turn cron off, thinking our problem would disappear. Low and behold, it DID NOT. So we (our team) can rule out that clearing cache on cron is the culprit. We still have the issue about twice a week now, less than before but still it is not welcomed.

Here is another interesting thing we found. Normally when we found this sporadic problem, we would have to put the site in maintenance mode, flush cache two times using the admin_menu flush-cache option, then refresh each page to see the content come back to life. I found that if you clear cache from the /admin/settings/performance, you only have to do it once. Pure coincidence? Possibly. Sense we have been clearing cache from /admin/settings/performance this missing content frequents us less often. Again, possibly coincidence. I reviewed the code for menu item 'admin/settings/performance' and see that the order of clearing cache tables and rebuilding the menu_router along with the theme_registry is very specific. I have not compared that to the sequence admin_menu uses. Not that the solution lies here, but it could be a contributor on our end, as we always use the admin_menu clear cache feature...

I hope that helps others squash this bug...

Status:Active» Needs review
StatusFileSize
new1.31 KB

Here's a patch, not for Panels, but for people to install if they are experiencing this issue to see if it is related to the list_themes() function. Obviously, if this is being triggered by the db going away, you'll need to be using syslog instead of dblog to actually gather the debug data, but I imagine most high traffic sites are doing that already.

Re #92:

Posted by jeffschuler on May 28, 2011 at 2:15pm

Following-up on #80, adding api[panels][styles][version] = 2 to my theme's .info file seemed to work for awhile, but I just got the white screen again -- 26 days later...

I did the same a few months ago, but to no avail. I had a WSOD this morning for the first time since.

Just a note, I don't use Skinr.

I have similar problem. I don't get a white screen, but just the content is empty: there is no panel output.

But this issue deals with the white screen (WSOD) problem, right? Therefore I'll post here: #1113614: Panel disappears on menu rebuild - page rendering, panels just...not. Or is this issue for all strange random disappearance behaviors with panels?

Just one general hint here: We set up a script on our webserver which checks every 3 minutes if the panel content is on page (just by looking for an panel css id), if not, the script dumps the database, runs two dimes drush cc all and call the frontpage again, to built it for the cache. This is working well and in 2 weeks the error appeared 3 times and got "cured" successfully.

Now I have a dump with the missing panels, which I can use for more research purposes on my stage server. BTW: I experienced the problem on the live an on the stage server.

I followed the instructions from dsnopek in #104 and created a registry diff. See in the other issue: http://drupal.org/node/1113614#comment-4988728

@osopolar, actually my issue is yours - it's more the page is empty rather than a true WSOD, but that's because the theme gets disabled and the Panels layouts are in the theme.

This is mostly a subscription. I'll try #110 for monitoring. I experienced this a few times in the past, and once today. I've just disabled legacy mode as described in #29. Let's wait.

I don't understand why cache fail makes layout break only in the homepage, even I use Panels page everywhere.

I actually disproved list_themes() as the cause and have added some more debug lines to a site we have running. We are basically running a drush command every couple of minutes on cron and if it discovers the theme is disabled it re-enables and writes to watchdog. This definitely happens when system_theme_data() is called, I've got that far - now capturing a backtrace every time that function is called and waiting for it to happen again.

Edit: btw, I'm now pretty convinced this is *not* a Panels bug, though there may be things Panels/Ctools can do differently to work around what feels like a core bug. See also #1226644: Themes being disabled - not done by an Administrator

This is skinr. I enabled skinr and then it happened. The site was fine before then.

rickh, I'm not sure it is related to skinr, since the WSOD is happening to our sites and we do not have the skinr module installed.

Update from us, we've finally discovered what causes the themes to be disabled. It's the update module. We don't know why, but we caught it red-handed. So in our case this doesn't seem to be a Panels or Ctools bug.

But it *is* cron related (see #109).

Here's the question, people this is happening to:

1. Are you sure the cause is theme being disabled?
2. If so, do you have the core Update module enabled?

If the answer to both those questions is yes, humour me. Turn off the core Update module, see if the problem still manifests and report back here.

I've started a new issue: #1331676: Update on cron appears to be disabling themes

I'm now 100% certain, in our case at least, Panels is not guilty. I would close this issue if I were merlinofchaos.

Well this issue discussion seems to refer to several possible causes of the 'panels not rendering' problem... But for me, it's not Update Status because that's not running on my server. So there's a bunch of possible/probable causes and perhaps more than one actual issue.

My situation, for the record:

  • Had two sites using older versions of CTools and Panels which ran on shared hosting on Apache. Never used Skinr.
  • Set up a new Linode VPS server based on the Aegir environment with Barracuda setup (Nginx + PHP-FMP). This included caching by Memcache, Redis and APC. Update status is automatically disabled in this environment.
  • This issue started: Head and foot of page rendered, panels content area missing/empty.
  • Have since disabled Memcache and Redis but not APC. Tried increasing max packet size in mysql. Checked my themes (all fine) and my panels layouts/styles are all in custom modules that define the proper API level.
  • There is plenty of available memory and CPU.
  • Clearing the caches fixes the problem every time.

None of the above seems to have made a difference, I still get a two of the sites (those with Panels) showing empty pages occasionally... It seems to happen when cron runs overnight, Barracuda has self-healing scripts that clears the caches daily.

The main difference for me from 'working fine' to 'occasional empty pages' is a) Newer DEV versions of CTools and Panels; b) APC and other server-level changes; c) cron runs and other scripts 'heal' the server occasionally.

Happy to test anything anyone says might work, thought the above might help narrow down the issue.

@Jim - yeh, that's a completely different issue to us. Feels like there are *at least* two separate issues bound up in this.

So I guess advice is if you experience this, first thing check if your themes are OK. If they are, then there's an unidentified issue there and post away in this issue.

If they're not, this is not the issue you're looking for - go here -> #1331676: Update on cron appears to be disabling themes

Got same problems... running a drupal 6.22 site with fusion sub theme and Panels 6.3.9

Not experiencing this issue http://drupal.org/node/1331676 but experiencing white screens of death on pages that should be showing panel's content.

Just run a "drush upc", updated all modules, switched theme to Garland, but still experiencing the problem with pages that have Panels content on them. They just won't render.

Stats:
Drupal version : 6.22
Drush version : 4.5

Decided to disable Panels and Page Manager, Skinr, Devel
Rebuild all pages that contained panels content because client was going crazy, wsod where happening on front page and such.

Problems has gone away now, I thought this had something to do with Fusion theme but after this switch to Garland it couldn't. There should be an issue with caching and Panels somewhere but I will leave that that to the experts, willing to test though if being asked to help in every way possible.

I'm having problems with D7 and empty panel pages once in a while as well :s

Hi all, I've been battling random WSOD for a year.. When I get a "Panels area only" whitescreen.. it's usually caused by a PHP error .. try using Devel "debug backtrace" (or manually use the PHP function debug_backtrace()) .. this should reveal a PHP error.

However, my second and much more fatal issue is a total WSOD on the site.

I battled this for a while and eventually we got ourselves a very talented system admin who set up our web stack; he's also been debugging the WSOD issue. He's also tracked it down to the cache key "ctools_plugin_files:panels:layouts"... here's our cache entries:
---WORKING-----------------------------

[cid] => ctools_plugin_files:panels:layouts
    [data] => Array
        (
            [panels] => Array
                (
                )
            [qs_global] => Array
                (
                    [scorecard] => stdClass Object
                        (
                            [filename] => sites/all/themes/qs_global/layouts/scorecard/scorecard.inc
                            [basename] => scorecard.inc
                            [name] => scorecard
                        )  ...... etc....

--- AND BROKEN (i.e. during WSOD)-----------------------------
[cid] => ctools_plugin_files:panels:layouts
    [data] => Array
        (
            [panels] => Array
                (
                )
        ) //  THEME ARRAY IS MISSING...

So we are having problems with this cache key.. he's suggested setting the cache key conditionally on whether $info['load themes'] is set within ctools_plugin_load_includes(). I'm not convinced it will fix it yet.. but it's certainly interesting.. We're going to test the following changes to the key name in that function next week (for both cache_get/cache_set):
---from-----

cache_set("ctools_plugin_files:$info[module]:$info[type]");

---to-----
cache_set("ctools_plugin_files:$info[module]:$info[type]".($info['load themes'] === false) ? "_without_themes" : "");

*** EDIT *** DO NOT USE THIS CODE - WILL BREAK YOUR PANEL !!
(sorry I forgot to clear my cache when I made my changes so I only just realised the above code breaks panels)

This will obviously create two cache entries .. but he's hoping that the request that sets the key "without_themes" doesn't override the cache entry that is correct... or will re-run the ctools_plugin_get_directories() function and ignore the bad entry.

However my opinion is that this will have no effect... because I agree with greg.harvey (#39) who said it's the list_themes() function... only because our themes are badly developed (based on 960gs).

My opinion is enforced by another interesting thing the sysadmin mentioned; which is that our WSOD sometimes occur during very heavy POST operations we have on our site.
So this could explain why the list_themes() function might not use the DB to get the theme information (like greg.harvey said)... I'm going to try putting the API version setting into our theme.info because it just makes a TON of sense that, during these random times when we WSOD - if the DB isn't available and it's trying to use files only.. that our themes need to declare the ctools plugin API properly.

OK, further to my comment in #120, I've not had the issue since I posted that. And nothing has changed.

In fact, I've only had the issue when Memcache and Redis were caching things, and then once a day after disabling them. So what was every 1-5 days is now ~20 days. So now I'm pretty certain that the issue for me was caused by caching problems.

Musings: I wonder if CTools or Panels needs more robust caching/validation so that values stored, especially larger ones that might fail to go into Memcache etc, are checked for validity or a sensible size. Even something as simple appending a 'STOP' character to the end of the data and invalidating the cached entry if it doesn't have it might help. Maybe that's a job Core or caching modules etc.

I just noticed:

In panels_theme() there is this code:

<?php
 
// We don't need layout and style themes in maintenance mode.
 
if (defined('MAINTENANCE_MODE')) {
    return
$theme;
  }
?>

I don't know why that's there, but it seems like this might be part of the problem. Maybe that's there because trying to build the themes in maintenance mode was breaking? In any case, I highly recommend putting a watchdog() in that and seeing if that happening is coincidental with the themes dropping out. That could provide us some very valuable information.

Added this in - see #1331676: Update on cron appears to be disabling themes

I'm actually about to examine watchdog on that site to see if there's any more information I can get on the phantom theme disabling. It must have happened a few times since I last checked, so will be interesting to see if anything new emerges.

OK, after extensive testing I'm pretty sure my WSOD issues have always been directly related to this: #147000: Rewrite module_rebuild_cache() and system_theme_data()

That bug (lack of proper db locking when calling the system theme rebuild function) has been around since the dawn of Drupal (6 at least) and remains unfixed. When the themes go away because of it, the panels implementations in the themes go to. And if your theme happens to contain your front page layout, then uh oh!

@merlinofchaos, I've left the check you requested in place, in case that turns anything up.

I've only read about 60% of the comments above but I think this is the root of all of my problems as well. Though I have a little more insight into possible issues related to this.

We too have the issue with the WSOD on the homepage that is built with panels, mini-panels, et cetera -- but also we experience a
slightly different take on issues where content loaded from CCK does not get loaded, and the only solution is a good old fashioned
cache clear (or also, a dump of memcache bins)

See related post: http://drupal.org/node/1387742

EDIT:
(obviously now leaning towards the theme issue, but the fact that it only really effects cck related content seems confusing)

Also, completely unable to reproduce this issue in a local or development environment. Seems to only happen in a scenario with high load.

Thanks for extensive testing. Any update on how definite this is?

Thanks for extensive testing. Any update on how definite this is?

Hi All,

I thought I would share our problems with this and how we fixed it. We ran into this problem whenever the site was under heavy load. Investigation lead us to believe that the following was happening;

1. The database becomes unavailable for a request temporarily.
2. Drupal bootstraps the theme layer to display a nicely themed "Cannot connect to database" error
3. MemCache is still online, so the theme bootstrap process happily inserts caches into memcache
4. Because drupal was not fully bootstrapped properly, the theme-cache entries that get inserted into memcache are *wrong*
5. WSOD!

To fix this we modified drupal-core to immediately die (with an ugly error message) if for some reason it could not connect to the database before the theme layer ever gets invoked.

Any way around modifying drupal core? Perhaps a formal patch is necessary, as it seems more then just a few people are having this problem...

I have also sometimes CCK fields problems as described in #129 (at least 3-4 times a year). So is this a Drupal core caching problem?

Fundamentally it's a bug in Drupal core in that it implicitly assumes that it cannot insert cache entries when the database is down. This is true most of the time, except when users are using modules such as memcache etc. I would be *very* curious if users who are using database-cache-table caching ever see this issue.

We aren't using Memcache, but we are using Drupal Caching. We still get the WSOD every so often.

naero, what do you mean by "Drupal Caching" ? Just turning caching on likely wont result in the problem we found (but I suspect there are more than one issues lurking in this thread that are all intermingled and hard to tease out). The issue we had was specific to using a different caching backend (other then the default database-tables one).

phayes:

We have these settings in "Performance":

  • "Caching mode" set to Normal
  • Minimum cache lifetime: 30 min
  • Optimize CSS files AND Optimize JavaScript files: disabled

I do want to point out that we have views caching turned on in a few places. We designed our site so that views (content panes) are placed into panels, which virtually control the way the entire site displays/outputs.

Hi naero,

If you are not using a different caching backend, I suspect you have a different issues that is causing the same result (WSOD)

I've committed the removal of the MAINTENANCE_MODE thing that should alleviate some of this. Not all, I fear, but some.

@merlinofchaos -- which MAINTENANCE_MODE thing? can you point me to the patch?
EDIT: nevermind, i see it :P I will place that and see if it coincides but part of me thinks it won't help my issues much...

Also, did you look here: http://drupal.org/node/1387742

I'm currently thinking of instead of dying, have it send back header information that will just simply refresh the page exiting bootstrap
in the middle of what it's doing so it doesn't write anything incomplete/corrupted to memcache (still trying to figure out how to ignore that if the DB connection is in fact timing out for longer then the fractional time period people are mentioning here) [don't want to inadvertently DDOS myself :P]

ctrl-f MAINTENANCE would probably have found it, but you can scroll back to comment #126 as well.

I placed watchdog right above the return in that if statement and so far it hasn't been triggered.

Had the WSOD on homepage a couple of times in past 24 hours. Hmm...

subscribing

Anybody any other suggestions?

I've resorted to getting an email anytime there is a 200OK on the front page but with WSOD. From there i've
just been flushing the appropriate memcache bin to clean up the issue.

Any other help on this would be sincerely appreciated.

(It's been happening about 3 - 4 times a day and it's starting to wear me out)

Status:Needs review» Postponed

To the best of my knowledge, the best lead on this problem, is this core issue: #147000: Rewrite module_rebuild_cache() and system_theme_data(). Subscribing/commenting in this issue is unlikely to be helpful at this point. Postponed until the core issue is resolved. Please focus your energy on testing out that patch.

Just an update from me (comment#124), after re-adding the default layouts that are provided with Panels (god knows why someone removed them!).. our cache entries during WSOD now include the default layout keys... yay!

I'm also going to comment out the return for MAINTENANCE_MODE, seeing as it makes sense to me, that the panels layouts are always available; and well.. MerlinOfChaos removed it too :)

I'll probably update this fairly post soon as I'm getting them (wsod) very frequently on one of my sites (varnish caching is off and I think the load causes a "db-lock" issue).

An update from myself, post #129. Decreasing the amount of reads&writes with memcache seems to have alleviated the issue hugely.

Hope that helps anyone.

We have been running the maintenance_mode fix for two weeks on one of our sites and it's (unusually) not WSOD'd once.

We'll be putting this fix to another similar site which has experienced 50(!) WSOD in the past 2 weeks, I'll report back on the second site's fix soon.

I'm at wits end. I've tried every fix on every discussion thread on this site and my panels are still not showing up and if they do (which seems like they randomly show up after days of not) they disappear again when cacheing. I tried every patch, module update, and change prescribed throughout drupal dot org with no success. Has anyone come up with a fix for this that I don't know about? My panels are operating in legacy mode though and if switching that off would fix it, how do I do that? I found this http://drupal.org/node/865840 and tried that fix but it didn't seem to work either.

I looked at:
http://drupal.org/node/147000
http://drupal.org/node/979912
http://drupal.org/node/1113614
http://drupal.org/node/865840
http://drupal.org/node/1172138 (although my issue is the opposite - flushing cache breaks it)
http://drupal.org/node/1203390 ( although in comment #1 you'll see my issue for this but otherwise i tried it)
http://drupal.org/node/1102636
http://drupal.org/node/962638

and some others with no luck.

**update**
I just went to my user page, the page where I use panels (apk), and the panels showed up as they seem to randomly do. Then I left the page and came back not 30 seconds later ,WITHOUT caching, and the page is gone again! I bring this up since I always assumed the panels disappeared due to my caching. This time it disappeared with no apparent reason. Any clues?

Regarding 107,

I'm a bit confused about what to do here:

@@ -402,4 +388,4 @@
/**
  * @}
- */
\ No newline at end of file
+ */

Do I remove or add the last line where is says */ ?

I asked the question on the other thread but got no reply so I'm hoping someone here might know.

There could be many reasons why your panels are white screening, so you'd be better off creating a new issue for your own problem, listing: your environment, version, related modules, etc.

Also, did you remove the MAINTANANCE_MODE return in theme_panels? This has fixed my random WSOD for a few weeks now.

I tried this fix but no luck. I also updated my core to 6.25 and that didn't help either. I did start a new post but got no responces or help. This is basically the big bug that's holding up my sites launch.

@yosisays

The previous poster is correct, you are better off posting your problem as its own issue instead of here.

Please try to give more information on that issue you create as well such as any log errors, modules installed etc.

If you weren't having this problem before and it has suddenly started you should note down what changed on the site (modules, theme, code etc) just before you began to have the issue.

It's going to be impossible for anyone to help you with no information to go on.

Issue summary:View changes

Add a quick fix when it is not resolved.

When this is postponed and somebody still have problem, I've just added a quick fix in the issue summary.

jcisio, thanks, I tried your quick fix but it didn't work for me.

audster, like I said in #154, I did opened a new thread (which, btw, makes little since since it would only be a duplicate of this one) but not even one person responded to it. In case it makes a difference I'm using Drupal 6.25 (although I had the problem with the last few versions as well) and I upgraded the relevant modules to the latest and greatest:

panels: 6.x-3.10
Chaos tool suite (ctools) 6.x-1.8+46-dev (2012-Jan-21)
Skinr:6.x-1.x-dev (2011-Feb-25)

I'm also using the Acquia Prosper theme (latest version).

I'm happy to furnish any other information you may need.

A month since my last comment (#150), we've seen no WSOD with the MAINTENENCE_MODE removed... This is a huge win for us.. did it get committed?

Excellent and many thanks MerlinOfChaos :)

"jcisio" (#156) asks why it's 'postponed' .. I'm not sure .. I guess it depends on whether the Original Posters' problem is fixed with the suggestions. I know mine is fixed and it was a very similar issue to the OP... my issues would occur multiple times a day during heavy traffic, usually several times a week. I've not had one for 6 weeks.

BTW; "yosisays", I replied to your thread over a week ago: http://drupal.org/node/1448270 .. still waiting on the answers/feedback.

Any news on this since #147000: Rewrite module_rebuild_cache() and system_theme_data() was resolved?

@frobinrobin : Did you also update drupal core between comments #147 and #150?

@merlinofchaos : Should panels add watchdog "Layout: @layout couldn't been found, maybe the theme is disabled." when the issue occurs? Atleast in legacy mode I think it should, but not sure about the standard mode because it looks like unreachable code.

cschaub, per #53, does the 'Panels Extra Layouts' module do this?

Is there a D7 fix for this issue?

Not sure @yosisays, I just used the ctools module approach.

@skyredwang I have not see this issue in D7

@olli #161
Nope, didn't update core. The maintenance mode fix worked for me

I can reproduce the issue related to MAINTENANCE_MODE (post #126 above)

- update a minor verion of 7.x and run update.php script
- update.php has "define('MAINTENANCE_MODE', 'update');" which might be related to the issue
- after an update panels go blank
- if to run on command line: 'drush cache-clear' and choose option '2' for 'theme registry' then panels show up again

- if to comment out the MAINTENANCE_MODE portion in panels/panels.module as in post #126 above
- run update.php
- panels do not blank out

Commenting out MAINTENANCE_MODE was commited to panels module version 7.x-3.0

I had this problem using Acquia prosper + skinr.
My panels became to go blank erratically about 2 weeks ago without particular reason.
I had to flush caches several times to recover them.
Reading this post, I tried around APC: bingo, it resumed to work well when disabling cacherouter.
But this wasn't a solution...
I tried the skinr patch from dsnopek http://drupal.org/node/979912#comment-4668928
It seems that the problem is sovled for me.

Upgrading to panels 6.x-3.10 solved this for me.

Upgrade output;

Project panels was updated successfully. Installed version is now 6.x-3.10.
WD php: Table 'prisacdn-stage.panels_layout' doesn't exist           [error]
query: SELECT * FROM panels_layout t__0 WHERE plugin = 'flexible' in
../modules/ctools/includes/export.inc
on line 379.
'all' cache was cleared                                              [success]
Table &#039;prisacdn-stage.panels_layout&#039; doesn&#039;t exist    [error]
query: SELECT * FROM panels_layout t__0 WHERE plugin =
&#039;flexible&#039; in
..//modules/ctools/includes/export.inc
on line 379.

To mention, this thread has been very helpful.

Thanks everyone.

Issue summary:View changes

Add heading