Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
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(); ?>
Comment | File | Size | Author |
---|---|---|---|
#110 | 979912-110-debug_list_themes_core.patch | 1.31 KB | greg.harvey |
#100 | 979912-39.patch | 858 bytes | dsnopek |
Comments
Comment #1
chrisschaub CreditAttribution: chrisschaub commentedSame 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
Comment #2
chrisschaub CreditAttribution: chrisschaub commentedI'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?
Comment #3
chrisschaub CreditAttribution: chrisschaub commentedHey @pwarterz, are you guys using a fusion based theme and skinr by any chance?
Comment #4
pwaterz CreditAttribution: pwaterz commentedNo, custom its a custom theme.
Comment #5
pwaterz CreditAttribution: pwaterz commentedNo, custom its a custom theme.
Comment #6
grantshow CreditAttribution: grantshow commentedThis 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
Comment #7
bkosborneThis 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.
Comment #8
bkosborneThis 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.
Comment #9
pwaterz CreditAttribution: pwaterz commentedAre you using the development version of chaos tools?
Comment #10
bkosborneNo, 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
Comment #11
bkosborneOkay, 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.
Comment #12
esmerel CreditAttribution: esmerel commentedI 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.
Comment #13
chrisschaub CreditAttribution: chrisschaub commentedI'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.
Comment #14
merlinofchaos CreditAttribution: merlinofchaos commentedMaybe 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?
Comment #15
chrisschaub CreditAttribution: chrisschaub commentedI'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.
Comment #16
pwaterz CreditAttribution: pwaterz commentedFor me all panes, blocks, and custom blocks disappear from the panel configuration. If I clear the cache everything comes back.
Comment #17
chrisschaub CreditAttribution: chrisschaub commentedI wonder if it's a memory issue. When re-creating the panels / views cache does it run out of memory the first time?
Comment #18
pwaterz CreditAttribution: pwaterz commentedI 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.
Comment #19
chrisschaub CreditAttribution: chrisschaub commentedRight, I've only seen on the homepage as well. Anybody else seen anywhere else?
Comment #20
webkenny CreditAttribution: webkenny commentedWe 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.
Comment #21
chrisschaub CreditAttribution: chrisschaub commentedI 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.
Comment #22
merlinofchaos CreditAttribution: merlinofchaos commentedI don't mind marking it critical for the reasons stated, but it unfortunately seems difficult to actually identify what's causing this.
Comment #23
pwaterz CreditAttribution: pwaterz commentedtotally 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?
Comment #24
webkenny CreditAttribution: webkenny commentedPerhaps 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.
Comment #25
chrisschaub CreditAttribution: chrisschaub commentedMerlinofchaos, 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.
Comment #26
memyselfandm CreditAttribution: memyselfandm commentedWe 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.
Comment #27
c4rl CreditAttribution: c4rl commentedI 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.
Comment #28
c4rl CreditAttribution: c4rl commentedAfter 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.
Comment #29
chrisschaub CreditAttribution: chrisschaub commentedAs 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?
Comment #30
merlinofchaos CreditAttribution: merlinofchaos commentedInteresting: Can folks experiencing this issue confirm whether or not they are running in legacy mode?
Comment #31
bkosborneI was in legacy mode when I had issues
Comment #32
chrisschaub CreditAttribution: chrisschaub commentedMy status page says I'm and not in legacy mode. Thanks.
Comment #33
pwaterz CreditAttribution: pwaterz commentedI am not in legacy mode either.
Comment #34
webkenny CreditAttribution: webkenny commentedWe 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)
Comment #35
pwaterz CreditAttribution: pwaterz commentedI am using a custom layout.
Comment #36
chrisschaub CreditAttribution: chrisschaub commentedI 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.
Comment #37
webkenny CreditAttribution: webkenny commented@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.
Comment #38
chrisschaub CreditAttribution: chrisschaub commented@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.
Comment #39
greg.harveyWe 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 corelist_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.
Comment #40
DamienMcKennaSubscribe.
Comment #41
sirkitree CreditAttribution: sirkitree commentedsubscribe. not having this problem currently but wanna keep tabs on it in case we do
Comment #42
merlinofchaos CreditAttribution: merlinofchaos commentedI'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.
Comment #43
BradMorris CreditAttribution: BradMorris commentedSome 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.
Comment #44
pwaterz CreditAttribution: pwaterz commentedSense 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.
Comment #45
webkenny CreditAttribution: webkenny commentedSame here. The API version seemed to do the trick for our problem sites. Also not using memcache.
Comment #46
vordude CreditAttribution: vordude commentedSubscribing.
Comment #47
chrisschaub CreditAttribution: chrisschaub commentedThe API trick isn't absolute. It can still happen if the memory or resources go low during the cache rebuild.
Comment #48
c4rl CreditAttribution: c4rl commented@schaub123 And would thus invoke a PHP memory_limit exceeded error? How did you diagnose that memory would cause this problem?
Comment #49
greg.harveyRaised 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.Comment #50
IRuslan CreditAttribution: IRuslan commentedI 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;
}
.....
Comment #51
chrisschaub CreditAttribution: chrisschaub commentedTo 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.
Comment #52
memyselfandm CreditAttribution: memyselfandm commentedWe 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.
Comment #53
chrisschaub CreditAttribution: chrisschaub commentedCould 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!
Comment #54
chrisschaub CreditAttribution: chrisschaub commentedOk, 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.
Comment #55
pwaterz CreditAttribution: pwaterz commentedI don';t think it is aquia prosper or skinr. I don'tt have either installed.
Comment #56
chrisschaub CreditAttribution: chrisschaub commentedI commented out the panels styles in the theme, still no dice.
Comment #57
greg.harveyHas 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.
Comment #58
chrisschaub CreditAttribution: chrisschaub commentedWell, 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.
Comment #59
Mark F CreditAttribution: Mark F commentedSubscribing - getting similar problem when applied recent security update. Will test with upgrading modules individually to see if that sheds any light on this situation.
Comment #60
djbobbydrake CreditAttribution: djbobbydrake commentedCould 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.
Comment #61
greg.harveyCan you stop memcached without the site falling over? If so, does that make the problem go away?
Comment #62
djbobbydrake CreditAttribution: djbobbydrake commentedWe 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.
Comment #63
chrisschaub CreditAttribution: chrisschaub commentedOk, 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.
Comment #64
greg.harveyI 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.
Comment #65
merlinofchaos CreditAttribution: merlinofchaos commentedI 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.
Comment #66
djbobbydrake CreditAttribution: djbobbydrake commentedWanted to report that the issue with blank panels has resurfaced after our APC cache changes. There's something else going on here...
Comment #67
pwaterz CreditAttribution: pwaterz commentedWhat'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.
Comment #68
djbobbydrake CreditAttribution: djbobbydrake commentedSo we've disabled our APC cache. This fixed our issue.
Comment #69
pwaterz CreditAttribution: pwaterz commentedDo you know if your APC was running out of memory? What is your shm set at?
Comment #70
djbobbydrake CreditAttribution: djbobbydrake commentedWe'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.
Comment #71
pwaterz CreditAttribution: pwaterz commentedHave checked to see if you are using up that 32mb
Comment #72
djbobbydrake CreditAttribution: djbobbydrake commentedI 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.
Comment #73
djbobbydrake CreditAttribution: djbobbydrake commentedOkay, 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.
Comment #74
djbobbydrake CreditAttribution: djbobbydrake commentedSo, 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.
Comment #75
bshelden CreditAttribution: bshelden commentedI 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.
Comment #76
Dr Jason Guo CreditAttribution: Dr Jason Guo commentedOur 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
Comment #77
pwaterz CreditAttribution: pwaterz commentedI 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.
Comment #78
naero CreditAttribution: naero commentedSubscribe
Comment #79
AntiNSA CreditAttribution: AntiNSA commentedWhen I clear my cache using zeropoint I get no more panels content and I cant edit a panel....
Comment #80
jeffschulersubscribing.
I've been experiencing this as well on a site with:
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.Comment #81
drupalusering CreditAttribution: drupalusering commentedI 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
Comment #82
drupalusering CreditAttribution: drupalusering commentedby 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
Comment #83
heylookalive CreditAttribution: heylookalive commentedSubscribing, 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.
Comment #84
Renee S CreditAttribution: Renee S commentedThis 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.
Comment #85
heylookalive CreditAttribution: heylookalive commented@Reinette tried turning off Updates module and running cron and it still happens :(
Comment #86
zyxware CreditAttribution: zyxware commented@alli.price - Do you have memcached running on the server? I have this issue on a server with memcached.
Comment #87
pwaterz CreditAttribution: pwaterz commentedIf 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.
Comment #88
zyxware CreditAttribution: zyxware commentedI 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
Comment #89
DamienMcKenna(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?
Comment #90
heylookalive CreditAttribution: heylookalive commented@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...
Comment #91
Marzuk CreditAttribution: Marzuk commentedI'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.
Comment #92
jeffschulerFollowing-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...Comment #93
Pillhuhn CreditAttribution: Pillhuhn commentedNot 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.
Comment #94
greg.harvey@Pillhuhn, I think you should start a new issue, especially since you can consistently reproduce it. That seems like a different issue.
Comment #95
Pillhuhn CreditAttribution: Pillhuhn commentedThanks Greg!
I did already here: http://drupal.org/node/1172138
Comment #96
merlinofchaos CreditAttribution: merlinofchaos commentedEverything 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.
Comment #97
greg.harveyYes, 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. =(
Comment #98
zyxware CreditAttribution: zyxware commentedWe 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
Comment #99
dsnopekI'm having this problem as well -- in a way very similar to @Marzuk in comment #91:
I'm about to experiment with the suggestion in comment #39.
Comment #100
dsnopekAttached 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.
Comment #101
dsnopekMy 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:
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.
Comment #102
dsnopekThe 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.
Comment #103
elvis2 CreditAttribution: elvis2 commentedWe 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.
Comment #104
dsnopek@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:
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.
Comment #105
elvis2 CreditAttribution: elvis2 commented@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.
Comment #106
heylookalive CreditAttribution: heylookalive commented@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!
Comment #107
dsnopek@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.
Comment #108
Milkrow CreditAttribution: Milkrow commentedSubscribe.
Comment #109
elvis2 CreditAttribution: elvis2 commentedThis 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...
Comment #110
greg.harveyHere'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.
Comment #111
naero CreditAttribution: naero commentedRe #92:
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.
Comment #112
osopolarI 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
Comment #113
greg.harvey@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.
Comment #114
jcisio CreditAttribution: jcisio commentedThis 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.
Comment #115
greg.harveyI 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
Comment #116
rickh CreditAttribution: rickh commentedThis is skinr. I enabled skinr and then it happened. The site was fine before then.
Comment #117
naero CreditAttribution: naero commentedrickh, 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.
Comment #118
greg.harveyUpdate 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.
Comment #119
greg.harveyI'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.
Comment #120
Jim Kirkpatrick CreditAttribution: Jim Kirkpatrick commentedWell 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:
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.
Comment #121
greg.harvey@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
Comment #122
undersound3 CreditAttribution: undersound3 commentedGot 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.
Comment #123
JGO CreditAttribution: JGO commentedI'm having problems with D7 and empty panel pages once in a while as well :s
Comment #124
RobinMofo CreditAttribution: RobinMofo commentedHi 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-----------------------------
--- AND BROKEN (i.e. during WSOD)-----------------------------
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-----
---to-----
*** 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.
Comment #125
Jim Kirkpatrick CreditAttribution: Jim Kirkpatrick commentedOK, 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.
Comment #126
merlinofchaos CreditAttribution: merlinofchaos commentedI just noticed:
In panels_theme() there is this code:
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.
Comment #127
greg.harveyAdded 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.
Comment #128
greg.harveyOK, 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.
Comment #129
Anonymous (not verified) CreditAttribution: Anonymous commentedI'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.
Comment #130
undersound3 CreditAttribution: undersound3 commentedThanks for extensive testing. Any update on how definite this is?
Comment #131
undersound3 CreditAttribution: undersound3 commentedThanks for extensive testing. Any update on how definite this is?
Comment #132
phayes CreditAttribution: phayes commentedHi 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.
Comment #133
Anonymous (not verified) CreditAttribution: Anonymous commentedAny way around modifying drupal core? Perhaps a formal patch is necessary, as it seems more then just a few people are having this problem...
Comment #134
jcisio CreditAttribution: jcisio commentedI 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?
Comment #135
phayes CreditAttribution: phayes commentedFundamentally 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.
Comment #136
naero CreditAttribution: naero commentedWe aren't using Memcache, but we are using Drupal Caching. We still get the WSOD every so often.
Comment #137
phayes CreditAttribution: phayes commentednaero, 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).
Comment #138
naero CreditAttribution: naero commentedphayes:
We have these settings in "Performance":
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.
Comment #139
phayes CreditAttribution: phayes commentedHi naero,
If you are not using a different caching backend, I suspect you have a different issues that is causing the same result (WSOD)
Comment #140
merlinofchaos CreditAttribution: merlinofchaos commentedI've committed the removal of the MAINTENANCE_MODE thing that should alleviate some of this. Not all, I fear, but some.
Comment #141
Anonymous (not verified) CreditAttribution: Anonymous commented@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]
Comment #142
merlinofchaos CreditAttribution: merlinofchaos commentedctrl-f MAINTENANCE would probably have found it, but you can scroll back to comment #126 as well.
Comment #143
Anonymous (not verified) CreditAttribution: Anonymous commentedI 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...
Comment #144
audster CreditAttribution: audster commentedsubscribing
Comment #145
Anonymous (not verified) CreditAttribution: Anonymous commentedAnybody 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)
Comment #146
Letharion CreditAttribution: Letharion commentedTo 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.
Comment #147
RobinMofo CreditAttribution: RobinMofo commentedJust 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).
Comment #148
Anonymous (not verified) CreditAttribution: Anonymous commentedAn update from myself, post #129. Decreasing the amount of reads&writes with memcache seems to have alleviated the issue hugely.
Hope that helps anyone.
Comment #149
audster CreditAttribution: audster commented@merlinofchaos re: #30
yes, see this
http://dev.nodeone.se/sv/caching-failed-with-panels-in-legacy-mode
Comment #150
RobinMofo CreditAttribution: RobinMofo commentedWe 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.
Comment #151
yosisays CreditAttribution: yosisays commentedI'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?
Comment #152
yosisays CreditAttribution: yosisays commentedRegarding 107,
I'm a bit confused about what to do here:
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.
Comment #153
RobinMofo CreditAttribution: RobinMofo commentedThere 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.
Comment #154
yosisays CreditAttribution: yosisays commentedI 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.
Comment #155
audster CreditAttribution: audster commented@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.
Comment #155.0
jcisio CreditAttribution: jcisio commentedAdd a quick fix when it is not resolved.
Comment #156
jcisio CreditAttribution: jcisio commentedWhen this is postponed and somebody still have problem, I've just added a quick fix in the issue summary.
Comment #157
yosisays CreditAttribution: yosisays commentedjcisio, 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.
Comment #158
RobinMofo CreditAttribution: RobinMofo commentedA 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?
Comment #159
merlinofchaos CreditAttribution: merlinofchaos commentedYes, see http://drupalcode.org/project/panels.git/commit/d8616975e0e7251e0ba328ff...
Comment #160
RobinMofo CreditAttribution: RobinMofo commentedExcellent 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.
Comment #161
olli CreditAttribution: olli commentedAny 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.
Comment #162
yosisays CreditAttribution: yosisays commentedcschaub, per #53, does the 'Panels Extra Layouts' module do this?
Comment #163
skyredwangIs there a D7 fix for this issue?
Comment #164
chrisschaub CreditAttribution: chrisschaub commentedNot sure @yosisays, I just used the ctools module approach.
Comment #165
pwaterz CreditAttribution: pwaterz commented@skyredwang I have not see this issue in D7
Comment #166
RobinMofo CreditAttribution: RobinMofo commented@olli #161
Nope, didn't update core. The maintenance mode fix worked for me
Comment #167
sustav CreditAttribution: sustav commentedI 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
Comment #168
jvieille CreditAttribution: jvieille commentedI 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.
Comment #169
drecute CreditAttribution: drecute commentedUpgrading to panels 6.x-3.10 solved this for me.
Upgrade output;
To mention, this thread has been very helpful.
Thanks everyone.
Comment #169.0
drecute CreditAttribution: drecute commentedAdd heading
Comment #171
naero CreditAttribution: naero commentedSo what is the recommended fix for this issue? Is it what is noted in the original post, about putting in the php code at the end of the page template files?
Comment #172
kopeboy CreditAttribution: kopeboy commentedThis is not fixed for me yet.
It appeared recently: things that may have caused it:
Deleting the "Home" menu item
Putting a Panels custom page as site homepage, either from panels ("Make this page your homepage") or my manually writing the path in /admin/config/system/site-information
I have tried everything, homepage is still blank (headers & footers show up, but not the panel contents).
Maintaneance mode,
disabling Update,
recreating/deleting the menu item from the panel page of main menu settings page,
clearing caches from drush, admin_menu, site/performance,
The only thing that DO work temporary is changing my default theme to Bartik (I guess anyone I haven't set default during my developement above would have worked), while still using a layout define by my original theme in the panel, BUT:
1) changing back to the theme I was using will make the problem reappear (using Adaptive Theme latest stable v.)
2) flushing all caches for the first time while still on the working theme (Bartik) will cause this horrible error
Navigating to other pages and then even back to homepage won't show the error anymore.
3) Disabling the original theme, and setting the panel layout to a panels one (one column), saving, will make the problem reappear (no panel content on homepage), and reflushing cache will cause the same horrible error.
Basically I can't get out of this. I tried all the steps both in maintenance and live mode.
_____________________________
Making the panel page NOT the homepage will show it normally.
No other panel around the site is affected, just the homepage.
Using Pantheon hosting.
IMHO the key is one of these:
having deleted the default "Home" main menu item (which before was just disabled),
having deleted the old panel page set to be the homepage (which didn't have a menu item) and created a new panel home page (which I don't remember if was set to have a menu item and be the homepage right away).
I don't remember having updated relevant modules between the working panel home page and the not working one, but I might have updated core in between.
Comment #173
kopeboy CreditAttribution: kopeboy commentedUPDATE:
I have imported my live database (with the old, working, panel homepage) to the dev environment with the problem, leaving the code as is.
Basically the problem is already there, but I couldn't see it because I was showing just a block and a node with no content but images as a jQuery Backscretch slideshow.
Any content I try to put in the panel homepage won't show up.
Now it's even harder to track down what caused this, but shouldn't be a module update at least.
UPDATE 2:
Something very strange happened. I changed my homepage at /admin/config/system/site-information from my panel page path to nothing (ie. the default /node), and the default node list would show. I then went to change the configuration of the block I was showing on the homepage (not placed with the panel)
from: Only the listed pages:
to: Only the listed pages: (nothing)
and saved, I got the same ugly error, but with a much longer second part.
Resaving the block will make the error disappear, but now at home (or at /node) I don't even have the default list of nodes promoted to front page.
Comment #174
jvieille CreditAttribution: jvieille commentedI still regularly encoutner this issue (Drupal 6).
This happens specifically (but not only) when I flush the caches while on a panel page.
I can get my panel page back on the spot by visiting and saving the module page.
Comment #175
penyaskitoHad this issue with 6.x-3.x. In my case updating to -dev helped. See http://cgit.drupalcode.org/panels/commit/?h=6.x-3.x&id=d3f1f07440e89fe23....
Comment #176
othermachines CreditAttribution: othermachines commentedIf your problem involves a custom layout in your theme disappearing from the theme registry after running update.php, try moving the layout into a module. I could reliably reproduce the problem on one of our websites (Drupal 7.44) although I could not reproduce it on a fresh 7.50 installation.
Locally, the result of the missing layout was a WSOD, no errors. On the server the page would render but without the panel.
Fortunately, moving the layout out of the theme and into a module seems to have fixed it.