I have heard of the White Screen of Death but never dreamt that i would experience it on my test site's Admin page while updating modules. It started when I disabled the content profile module. My log on MAMP reported the following:

PHP Fatal error: Call to undefined function content_profile_load() in /Applications/MAMP/htdocs/drupal-6.12/includes/common.inc(1645) : eval()'d code on line 4.

All solutions suggested in the forums--- such as increasing memory in php.ini. settings.php crashed and burned. If I could only regain access to my admin page. No such luck with http://localhost/drupal-6.12/?q=user, but I do see a Page Not Found page.

Any ideas on how to resolve this would be appreciated.

Comments

VM’s picture

back up database

go into the database manually (phpmyadmin)
locate the content profile module in the system table
set its status to 1
save

this should reenable the content profile module, if that is when the problem started that should get you back to where you were before you disabled it.

Thomasr976’s picture

I was able to get back in to the admin page. Thanks so much, now I am looking for that snippet.

How can I prevent this from happening again? Seems like severely curtailing or deleting modules from entirely is the best insurance. what do you think or are there modules that are notorious for causing the WSOD?

styro’s picture

Is to not paste PHP snippets into your database.

This problem is not due to the choice of modules - it would happen with any module that has a function you call from a snippet. Once the module is disabled, the function disappears and your snippet breaks your site with a fatal PHP error.

While it is more stuff to learn initially - the best way to add your own custom PHP code into your site is via a custom module. That way your module can be set to "depend" on the other modules it uses. And you won't be able to disable those modules until yours is disabled.

The other advantages with having your custom code in an external file are that a) you can keep the files in a source control system, b) you get to edit the code in a decent code editor rather than a textarea, and c) fixing broken code is much easier when it is in an external file rather than the DB.

dimitriz1’s picture

i see no text about pasting php snippets in original post?

dimitriz1’s picture

wait i think i understand now. are u say that it is best not to use "custom php" textareas in block settings of drupal?

styro’s picture

I'm not saying "don't do it at all" - more like "do your best to avoid it". And if it gives you the push to learn how to make a basic module instead - so much the better.

The basics of making custom modules isn't difficult - but of course they can get complex depending on what you want them to do :)

Turning a PHP snippet into a block via a module isn't difficult - you just need to use hook_block().

Another approach you can take with pasting PHP into blocks is to give yourself a "backdoor" by configuring the PHP enabled block to NOT appear on any of the block administration pages. That way if the block causes a fatal error, you can still easily disable it.

As to guessing it was a PHP enabled block? The clues were a) when an error message mentions "eval()'d code" it generally means code stored in the DB, and b) if it happens everywhere it is probably running in a block rather than a node. But that is still just a best guess.

VM’s picture

it was a hell of a good theory on styro's part that the OP pasted a function from the the module into a block, the same module that the user disabled. By doing so the function in the block could no longer do what it needed to do and was causing a php fatal error.

php code should be used in a custom.module.
if you must use php in a block, always test it in a page with the php filter first as bad php in a block will cause your site to come down.

styro’s picture

You need to track down the snippet you pasted into your site that called it. The "eval()'d code" part the error message usually means that it is user entered PHP code stored in the DB (eg snippets) rather than code living in a PHP file on disk.

It might be in a node, or a block, or in a block visibility page etc etc.

The fact it appears on every page indicates that it might be in a block rather than a node. If you remember what block it is (assuming it is a block), you could also just disable the block from the DB too.

Another possible workaround if the whole re-enabling the module bit is too hard:

In your settings.php file, create a dummy function so that the site loads again - eg:

function content_profile_load() {
}

Then you can hunt down the PHP snippet that tries calling it and delete it.

Thomasr976’s picture

Also know where to find it. Many thanks to all of you for your input.

Thomasr976’s picture

I am following up on everyone's excellent suggestions and have identified sevearal snippets. i am not sure which ones may cause the php fatal error and would appreciate any feedback or suggestions. Here's what I found:

1) In my Blocks, -- My profile:

<?php 
global $user; 
$myuid= $user->uid; 
$node= content_profile_load(profile, $myuid); 
//profile above=the name of our content type 
$profileid= $node->nid; 
print l('My profile','node/'.$profileid); 
//l() is a function provided by Drupal that creates a link. 
//l(link display text, path after main path) 
?>

2) Custom Content in a pane

<?php
$node=node_load(arg(1));
$myuid=$node->uid;
$node=content_profile_load(profile, $myuid);
$profileid=$node->nid;
echo '
View my profile';
?>

3) In Views under basic setings in Empty Text

<?php echo '<img src="' .base_path() . 'sites/default
/files/avatars/defaultavatar.jpg" />'; ?>

Thanks for your help. This has truly been a learning process.

grobemo’s picture

Based on the earlier discussion, it looks like (1) and (2) will both cause problems. Either one is enough to crash the site if the Content Profile module is disabled. base_path is a core Drupal function, so it won't cause a problem.

Here's a rule of thumb for pasting snippets, to supplement the excellent advice given above: If you must paste a snippet, check each function in the snippet to see whether it is (a) a native PHP function [i.e., you can find it in the documentation at http://php.net], or (b) a core Drupal function [i.e., you can find it on http://api.drupal.org]. If it's not, then it's probably a contributed function, and you should wrap your snippet in an if (function_exists(FUNCTION_NAME)) { } statement. For instance, you could replace snippet (1) above with:

<?php

if (function_exists('content_profile_load')) {
  global $user;
  $myuid= $user->uid;
  $node= content_profile_load(profile, $myuid);
  //profile above=the name of our content type
  $profileid= $node->nid;
  print l('My profile','node/'.$profileid);
  //l() is a function provided by Drupal that creates a link.
  //l(link display text, path after main path) 
}
else {
  print t('Error! Drupal could not find the function "content_profile_load"');
}

?>

This method is a bit clumsy and not as good as a custom module, but it should help you avoid WSOD hell.

Thomasr976’s picture

Many thanks for the rule of thumb and the guidance. I'm glad this WSOD issue happened on my test server instead of my production sites. This should be of great value to drupal users who are working with dorien's Ultimate Community Site Guide. I think I am going to get this into the documentation pages on how to resolve WSOD issues.

dorien’s picture

Just a remark. If you copy code from a pdf, be sure to retype the ', because they become curly and will produce errors.

bentonboomslang’s picture

Just wanted to say thanks to the question answerers in this thread. Very useful stuff.

gwenbleyen’s picture

1. Go to phpMyAdmin
2. click on your drupal database
3. click on the SQL tab
4. Execute this code
update system set status=0 where name='update'

No more trouble ever again!

cheers

kairick’s picture

So for the second time today, I got the WSOD. The first one was averted simply by removing the problem module. THIS time I got it after activating elements pertaining to ImageAPI, GD. Once it went down, of course I googled it and apparently there is a general issue with GD overrunning the memory limit. I can't even access the admin page.

I tried the WSOD emergency deal and this was returned:
Fatal error: Call to undefined function: node_get_types() in /test/includes/theme.inc on line 923
hook_exit wasn't executed properly at , possible unexpected exit()/die()
Backtrace:

1: Are the memory issues and this error at all related?

2: How do I use phpinfo.php to find my php.ini file and change the memory limit?

3: What do I fix, because I'm about to freak out. :) I have a deadline on this project due Thursday and I'm dying over here.

Please and thanks!

VM’s picture

2. create a custom php.ini file and override the values. This is discussed in the documentation section. Mileage will vary and is dependent on whether your host allows overriding php values or not.

styro’s picture

I tried the WSOD emergency deal and this was returned:
Fatal error: Call to undefined function: node_get_types() in /test/includes/theme.inc on line 923
hook_exit wasn't executed properly at , possible unexpected exit()/die()
Backtrace:

1: Are the memory issues and this error at all related?

Doesn't sound like it. Generally when you run out of memory the error message will complain about not being able to allocate memory.

node_get_types() is part of the node module. (In the latest Drupal 6) The only call to node_get_types() in theme.inc looks like this:

  if (module_exists('node')) {
    foreach (node_get_types() as $type => $name) {
      $defaults['toggle_node_info_'. $type] = 1;
    }
  }

So Drupal only tries to call node_get_types() if the node module exists. But if the node module actually exists but doesn't have that function, then it sounds like your node module file might have been corrupted somehow.

I would replace your core files with good ones and see what happens. Or at least compare your node.module file with what it is supposed to be - does it contain a node_get_types() function definition?

kairick’s picture

Well, I repaired my node.module issue by replacing the corrupted points, now it's just that when I enable ImageAPI, I get the WSOD until I remove the module via FTP. Now along with my other image-related issues, I'm getting Access Denied dialogs when I try and upload images to galleries. This was addressed here http://drupal.org/node/360463 and I am indeed trying to upload from an area with more than 41 images as proposed in that dialogue, but I don't know how to create the my.cnf file... blah blah...

Since this thread is dedicated to WSOD, a reply on that topic would be welcomed. I've posted on the above node as well if you'd like to respond to that issue there.

Thanks a lot

VM’s picture

if on a shared server you don't have access to my.cnf
otherwise, do a grep on your file system to locate the file.

trying to get the machine to actually throw an error would be the best way forward.

How much memory is available to the server? imageapi reccomends 92 MB of memory for it alone.

as a sidenote, the linked node is not for support questions. questions should be directed to the forums as this post is. Thus comments on the linked node above have been deleted.

kairick’s picture

Currently there's only 64MB available. It being a shared server, I'd probably have to contact the host (Yh) and have them up it, right?

VM’s picture

Depends on what they allow and don't allow. I use a custom php.ini file to override default php settings. Checking hosts support forums, knowledge base and the like will better answer that questions. Some hosts only allow a specific amount of memory per account on a shared hosting platform. considering you need 92M for impageapi and 32 for core they may not up it to where you need it and you may need to move to a VPS. however, only your hosts documentation and RUP (resource usage policy) can formally provide answers.

kairick’s picture

Gotcha. Is there a viable alternative or multiple alternative modules to ImageAPI? Last thing I want to do is go back and tell the client they have to switch to a VPS because of this.

VM’s picture

no. Images can be intensive. First thing first, see if you can get memory upped. If this project was designed around heavy image use better research on your part for the client prior to introducing modules into an environment would have been prudent.

As styro has stated until you get an error to print every one is basically guessing at the issue. My guess is based on 48 images and the use of heavy modules on shared server with relatively low memory.

kairick’s picture

I have the same guess on the matter.

The site was set up by someone else who got the work started and then was handed over to me. This issue arose when I had to activate modules to upload images to multiple galleries. I'll talk to the client to see if we can't get the memory upped, but that's my only problem as of right now.

Thanks so much for your help!

styro’s picture

Since this thread is dedicated to WSOD, a reply on that topic would be welcomed. I've posted on the above node as well if you'd like to respond to that issue there.

Having a "WSOD" is practically meaningless - all it represents is an internal server problem. And there are an almost infinite number of ways they can happen.

Diagnosing them requires the actual error message for clues to the actual problem . eg like the one you quoted earlier that pointed out the missing function.

When you get nothing back from the server (ie the "WSOD") it basically means that PHP and Drupal are configured NOT to send internal error messages to the browser (normally a good thing when in production). So if your host doesn't give you access to the web server error logs (note: the error logs are different to the access logs), you might still be able to enable sending the errors to the screen.

Changing the "Error Reporting" settings in Drupal might be enough to see the errors, but there is a chance you might also need some PHP config overrides too (I'm not too sure what exactly).