I am trying to enumerate through a perfectly valid array using php 5.3.5 on Joomla 1.5. Whenever I try to access the array I get the white screen of death. If I add a die() statement right after then I get the array, (but of course, execution after that is halted). I purposely put no code after array call and die() for debugging purposes. Removing die doesn't echo the array. Has anyone else had this issue before?
Edit: yes, turned error checking on. WSOD is BLANK.
**in the View class:**
$seminarsRefDB =& JFactory::getDBO();
$seminarsRefQuery = [MYSQL STUFF]
$seminarsRefDB->setQuery($seminarsRefQuery);
$seminarsRefList = $seminarsRefDB->loadAssocList();
for($i=0; $i<count($seminarsRefList); $i++) {
$classAppendix = $i;
$seminarselects[] = JHTML::_('select.genericList', $seminar_options, 'seminar_title[]', 'class="seminardropdown" style="width:200px;"', 'value', 'text', $seminarsRefList[$i]['value'], 'seminar'.$classAppendix);
};
$this->assignRef('seminarsArray', $seminarselects);
**In the Default Template**
print_r($this->seminarsArray[0]);
die;
END
I have another array called speakersArray which is echoed perfectly. I copied this code verbatim from the backend of my site where both arrays show no problems.
Used get_included_files and the default template is the last file included, so execution stops there.
You should turn on display_errors and error_reporting to E_ALL so you don't get a white screen of death and have your server tell you what errors it is getting.
It sounds to me that if its a big array and your passing it around, you could be running out of memory at some point in the code. By placing a die right after the array, you may have not hit that threshold yet.
Though iLLin's approach is fine for development testing, this is bad practice for a live site. Assuming you have access to your server, view the error log file to find out what is going on here.
tail -f error_log
Related
I have a small ajax script that gets some json data and fills some form fields when the user makes a selection.
I noticed this morning that there was an error when I ran the ajax on my development server but when run production side it worked. I am assuming this is due to some difference in error reporting between the servers but I can't figure out why.
Dev PHP version: 5.3.13
Prod PHP version: 5.3.16
I have tracked the error to some variables that were only setting if additional rows cam out of the database. I am retrieving between 1 and 3 rows.
The first row is assigned to $array1 and additional rows go into their own array as $sec_row[0] and $sec_row[1].
$array1 = ('Name'=>'George','Address'=>'52 Smith St',....etc);
$sec_row[0] = ('Alias1'=>'Jorge','Location'=>'SimCity',....etc);
echo json_encode(array('result1'=>$array1,'result2'=>$sec_row[0],'result3'=>$sec_row[1]);
Note $sec_row is only set when additional results are found.
On the live site when $sec_row is undefined the ajax returns result2 and result3 as NULL. But on the development server on my localhost it gives me an "undefined index" (if only $sec_row[0] is set) or "undefined variable" (if neither $sec_row are set) error.
I have fixed the error locally by setting $sec_row manually before encoding the json but I don't understand why I needed to do this locally but not on the production server.
Any suggestions as to what setting might cause this?
Because you probably have display_errors turned on so it will generate the undefined index error in the middle of the JSON making it invalid JSON which can not be parsed on the JS side.
Easiest thing to do other than fix the error is to turn error_reporting off. But you should fix the error, by checking if the indexes are set and then outputting the value, or null.
json_encode(array(
'result1'=>$array1,
'result2'=>isset($sec_row[0]) ? $sec_row[0] : null,
'result3'=> isset($sec_row[1]) ? $sec_row[1] : null
);
Actually, I would try to correct the error instead of simply ignoring it... Try to do something like this:
$result = array('result1' => $array1);
if (isset($sec_row[0]))
$result['result2'] = $sec_row[0];
if (isset($sec_row[1]))
$result['result3'] = $sec_row[1];
echo json_encode($result);
its to do with the error_reporting levels on your servers
so either turn them off - add the following to the top of the script, or directly in the php.ini if you have access to it - look for display_errors, set to 0
error_reporting(0);
#ini_set('display_errors', 0);
or why not build your json_encode beforehand
ie
assuming you always only have 1 $result1
for($x = 0; $x <= count($sec_row); $x++) {
$more_json .= "'result'".$x+2 ."=> ".$sec_row[$x].","
}
# strip the last comma off
$more_json = rtrim($more_json ,',');
echo json_encode(array('result1'=>$array1, $more_json);
I have not tested this, so the syntax may not be 100%, but you get the idea
I've noticed when a youtube page crashes it puts out a kind of encoded message which can be send to the developers of Youtube without the customers gaining knowledge about the Youtube infrastructure and used programms.
Is this idea a practice to do with your own sites?
Most frameworks nowadays have the ability to use different application settings for production and development use.
In production mode (when the site is being used by customers) no errors should be visible, for security and design reasons. Therefore you often turn log_errors on, and display_errors off. When an unrecoverable error arises the user is presented with something like "Something went wrong, we're putting our best people on it right away." There is no point in showing the user some weird number, like "Error code 823." Use a cron worker to send you the error log, or just check the log manually, and make sure the error messages are verbose enough for you to track the bug down.
In development mode (when you're running the site locally during development) you probably want to see the errors as soon as they arise. Therefore you turn display_errors on. You probably won't mind if the design breaks, and hopefully you understand what's going on.
Error messages are a programmer's best friend, but your users should never have to experience them. If it happens, make sure to give the user some sensible feedback, and not just a blank page or a random error code.
You don't need it with PHP.
Unlike Flash, PHP is running server-side. So, just make PHP to log whatever error messages.
Set these options in your php.ini file
log_errors = On
display_errors = Off
and you will need no volunteer users to see them
but only your web-server's error log to peek into
Just thought of something like creating a custom error handler, with some basic encode/decode Function, it's up to you to extend the idea:
// Set error handler
set_error_handler("customError");
// The error function handler
function customError($error, $errorMessage, $errorFile, $errorLine){
echo(encodeError("<b>Error</b> [$error]: $errorMessage, on line $errorLine in $errorFile ."));
}
function encodeError($string){
$array = str_split($string,1);
$results = array();
foreach ($array as $value) {
$results[] = ord($value);
}
return(base64_encode(implode(".", $results)));
}
function decodeError($string){
$array = explode(".", base64_decode($string));
$results = array();
foreach ($array as $value) {
$results[] = chr($value);
}
return (implode("", $results));
}
// Trigger error
echo(3/0);
// We the developers decode it with the decode function
echo('<br><hr>'.decodeError('NjAuOTguNjIuNjkuMTE0LjExNC4xMTEuMTE0LjYwLjQ3Ljk4LjYyLjMyLjkxLjUwLjkzLjU4LjMyLjY4LjEwNS4xMTguMTA1LjExNS4xMDUuMTExLjExMC4zMi45OC4xMjEuMzIuMTIyLjEwMS4xMTQuMTExLjQ0LjMyLjExMS4xMTAuMzIuMTA4LjEwNS4xMTAuMTAxLjMyLjU2LjUzLjMyLjEwNS4xMTAuMzIuNjcuNTguOTIuMTE5Ljk3LjEwOS4xMTIuOTIuMTE5LjExOS4xMTkuOTIuMTAxLjEyMC4xMTIuMTA4LjQ4LjEwNS4xMTYuOTIuMTIyLjEwMS4xMTQuMTExLjQ5LjQ2LjExMi4xMDQuMTEyLjMyLjQ2'));
I'm writing a web application in PHP, and I'm getting the following warning in Google Chrome only:
Warning: Cannot use a scalar value as an array in
M:\xampp\htdocs\MyProjectTitle\php\classes.php on line 18
Background: Please note that the web app works just fine in all browsers I tested (Firefox, Chrome, IE), but the warning appearing in Chrome is bugging the hell outta me.
Notes: I have tried restarting Chrome and clearing the Chrome cache. I have tried restarting the computer. I have tried searching the source code in FF and IE to see if the warning was just hidden, but to no avail. The warning is only popping up in Google Chrome, and I have no idea why.
UPDATE: Even though Safari also uses WebKit, it does not show the PHP warning. For some reason, Chrome is the only one that has the PHP warning. Weird stuff!
UPDATE: Here's the first 21 lines of code:
class Presenter {
public function includeFile($filePath) {
if (is_readable($filePath)) {
include $filePath;
} else {
echo '<p><strong>ERROR 404</strong></p>';
echo '<p>The resource you requested could not be located.</p>';
}
}
public function sanitize($string) {
return preg_replace("/\s/","_",$string);
}
public function set($varname,$value) {
$this->$varname = $value;
$_SESSION[$this->name][$varname] = $value;
return $this; // enables chaining!
}
// And there's more code after this, but I have cut it out here.
}
Note: The above code is inside a PHP class.
UPDATE: I know exactly what lines of code are causing the warning in Chrome (although I still have no clue why Chrome is the only browser that shows the warning). Since my webapp works perfectly despite the warning in Chrome, I have used # to suppress the warnings in Chrome (I'll fix the warning later).
Most likely it's this:
$_SESSION[$this->name][$varname] = $value;
if $_SESSION[$this->name] was not defined as an array earlier, you'll get the "can't use scalar as array" error. e.g. if you do
$_SESSION[$this->name] = 42;
$_SESSION[$this->name][$varname] = 'will not work';
the error is triggered.
I have the feeling that Chrome sends different data to the server, therefore you are having this error. If there's any $_POST data, or $_GET data please verify that with what other browsers send. You can easily display the contents using print_r() or var_dump() whichever you choose.
This usually happens because you do something browser-specific(maybe you do something IE specific, and firerfox-specific, but forgot to add a "default" case for other browsers?)
UPDATE: I know exactly what lines of code are causing the warning in Chrome (although I still have no clue why Chrome is the only browser that shows the warning...If you know, please let me know!). Since my webapp works perfectly despite the warning in Chrome, I have used # to suppress the warning as a temporary fix until I can fix it for real later.
Basically that is happening because you are trying to access a UNDEFINED variable (or not set variable).
PHP omits MANY common programming mistakes, that other languajes don't permit.
Ok if you start a program like:
<?php if(eregi("hi",$hello)) { echo "hi"; } ?>
Will get this "message"
Notice: Undefined variable: hello in C:\var\www\test.php on line 1
you sould predefined it as:
<?php $hello = "hello"; if(eregi("hi",$hello)) { echo "hi"; } ?>
Or a conditioned to avoid elimination of previous values:
$hello = isset($hello) ? $hello : null;
This code will send you a deprecated function message also.
any why this messages are caused by the PHP.INI configuration on your server, this is happening because you had something like this:
display_error = on;
error_reporting = E_ALL;
And sould be something like:
display_error = on;
error_reporting = E_ALL & ~E_NOTICE & ~E_STRICT
This will remove all NOTICES messages and make PHP more permisive, also you can add ~E_DEPRECATED if you get deprecated messages,
how ever getting this messages, means that you need to be a more secitive programmer! Yes is more tediuos but some one has to make it!
Probably because you need to do ctr+f5 or restart in your other browser. It probably has a previous version of your page cached, happened to me a lot with Internet Explorer 8.
I have all errors turned on (error_reporting(-1)) in Drupal, but for some reason most errors do not come through in the logs or on screen. I can replicate the problem by simply changing a function name to something else, and I would expect to see a function doesn't exist error, but I just get a white screen. I have tried replicating this outside of the Drupal framework and I can't - so it leads me to believe it isn't my setup of PHP (Zend Server/Apache2/PHP/Windows) but is in Drupal somewhere...
Any ideas anyone?
I know this may be late, but it helped me. Most times a module causes WSOD, I couldn't just disable modules to test which it was, since I may have lost data in the process. What I did was to edit this function in module.inc
function module_invoke_all($hook) {
$args = func_get_args();
// Remove $hook from the arguments.
unset($args[0]);
$return = array();
foreach (module_implements($hook) as $module) {
print "Starting loading $module <br />";
$function = $module . '_' . $hook;
if (function_exists($function)) {
$result = call_user_func_array($function, $args);
if (isset($result) && is_array($result)) {
$return = array_merge_recursive($return, $result);
}
elseif (isset($result)) {
$return[] = $result;
}
}
print "Finished loading $module <br />";
}
return $return;
}
And I added those 2 print statements in the code above, then refresh the page, the module which didn't reach the "Finish loading $module" statement is the one with the problem... it was devel in my case.
After finding the module, you can go into the system table and look for that module, set it's status = 0 and bootstrap = 0 or run the query:
UPDATE system SET status = 0, bootstrap = 0 WHERE name = 'module_name' LIMIT 1
Reference: Debugging Drupal White Screen of Death (WSOD)
You need to make sure display_errors is enabled as well.
ini_set( 'display_errors', 'on' );
Full documentation of WSOD.
this might be the dumbest answer on stackoverflow, but this happened to me when i was desiging a cakephp site from scratch and had white background and white font in the css, and couldn't get anything, no errors or sql dump.
see if you can select text on the screen.
Check php's setting for "error_reporting", maybe? Mine's set to:
error_reporting = E_ALL & ~E_DEPRECATED
Sometimes, I would get strange errors including WSOD if i included a file that had the closing php token.
?>
It took me forever to track down.
I started to enable/disable modules to see when I could see errors again and limited it to two modules that turned off the error handling... After more investigation I found that in a nusoap.php class error reporting had been turned off because certain errors kept showing (some other developer had turned it off)... Turned it back on, upgraded nusoap.php and now all is working... Thanks for the help all
I note your question has already been answered but it may be useful for others reading this to know that sometimes a WSOD can be caused by an older incompatible version of PHP on the server. Drupal 7 requires PHP 5.3 but many servers are still running PHP 5.2. This can cause a WSOD with no error messages.
I am well aware about error_reporting(0); & ini_set('display_errors', "Off"); to make error messages go away.
What would be an appropriate way to do this - for a specific file or part of code only?
Surpressing errors with #'s seems like a bad idea since it apparently slows the code down...
The reason? We have a number of memcached servers in a development LAN that is really unreliable due to the network settings, thereby we are recieving errors multiple times every hour and there's nothing we can do about it except stop using memcache or turning off errors for the whole application, which would be giving us a headache - in the middle of the development stage :)
<?php
// normal code
// error_reporting returns the old error code
$old_error_reporting = error_reporting(0);
// your errorful code
// reset error_reporting to its old value
error_reporting($old_error_reporting);
// normal code
Although it would be a good idea to fix what is actually causing the errors.
You've kind of answered your own question. To do it for a specific file, error_reporting(0); will turn off errors. You can also call it multiple times in a script, I think.
You can also use php exceptions to 'catch' errors over a block of code. For example:
try {
// code to ignore errors for here
} catch {
// you can output a custom error here, but putting nothing here will effectively mean errors are ignored for the try block
}
The script will continue running past the try block, even if there is an error within it. See the PHP Manual Entry for more information.
You can change the error reporting level during runtime:
<?
error_reporting(E_ALL);
... some code ....
error_reporting(0);
... some more code ....
error_reporting(E_ALL);
I know of no other way but I can't think of a case where this wouldn't be sufficient. Can you?
That's really a long time ago but someone like me would maybe use my answer.
When i need to do this kind of stuff, i just put # before the variable in order to NOT display the errors coming from this variable.
example:
switch(#$var!="e") {
....
}