Yii - 'white screen of death', debugging tips - php

I have a staging server running a Yii application that now gives a 'white screen of death'. I cannot see anything being ouputted to the screen (or even the source code when 'view source'), locally the same code runs without any issues.
Can anyone suggest a good routine to debug 'white screen of death' within a Yii application?

Getting a blank screen in yii is mostly because error_reporting is off.
Put
error_reporting(-1);
ini_set('display_errors', true);
in index.php should get your output back.
Note that you can always look in application.log and apaches error.log for informations when you don't have some output.

This is for Yii2
I found the code was failing in vendor/yiisoft/yii2/BaseYii.php at method autoload($className). It was failing at execution:
include $classFile; (line 293)
The cause in my case was a function method name declared twice.
You might be interested to know that you can discover the cause (which Yii2 suppresses through its own error-handling) by preceding the command with Chris's recommended code above https://stackoverflow.com/a/25139283/3125602. If you introduce them too early in the code, they get overwritten by Yii2's error-handling settings.

It is quite a simple issue and happens either when a script reaches the PHP memory limit or during a plugin or theme conflict.
Solutions :
Increase the Memory Limit :
Since this is regarded as one of the cause, it is recommended that the PHP memory limit be increased. Edit your wp-config.php file via FTP adding the following line of code:
define( ‘WP_MEMORY_LIMIT’, ‘64’);
This increases your memory limit to 64M. You might need to contact your host before you do it as some host don’t allow it from your end.
Deactivate all your Plugins :
Connect to your site via FTP and rename the wp-content/plugins folder to plugins_old to deactivate all your plugins.
Here is a detailed answer to the infamous "White Screen of Death" problem. Thank me later :)
https://www.perceptionsystem.com/blog/wordpress-errors-solution/

Related

How do I detect error in shared hosting/live server?

In localhost, we can easily find the errors like missing semicolon in line number xxx, undefined variable in line number xxx,class already declared etc. But, when I upload all my files in shared hosting and try to see results in the web browser, I get to see same error page everytime and it's really really hard to detect what exactly caused the error. The project which i uploaded to the live server was written in laravel. I have tried 'Display errors On' in php.ini, error_reporting(E_ALL). I have even checked the error_log in the root directory but, those logs are usually from few days ago. error image description here
Any possible solutions ? Or should I switch to server where proc_open is enabled?
Check this:
https://laravel.com/docs/7.x/errors
Laravel handles errors and can write them in a log file.
You can customize it if you want, but I don't think it's necessary to do so.
If you dont use any frameworks or ones that don't support such a feature for that matter you could always use the native PHP function set_error_handler and catch errors and write them in a log file.
Note: BEWARE of the excessive log file size. If your project has a lot of visitors or has lots of notices and warnings, this log files can get excessively massive, unreadable, and consuming your space. Don't turn it off, it's always good to know where are the errors, but check and debug them often and delete them when not needed.

Notice warning from PHP in Symfony uploading file

I have a form that allows upload three files at the same time but just one is required. That works fine, my only problem is the following: if I upload three files I haven't any problem but if I upload one or two files (leaving two or one files empties) I obtain the following notice:
Notice: No file uploaded in Unknown on line 0
As much as empty files. The files are uploaded properly without any other problem, but I want remove that notice... or unless hide it, although I prefer remove it. I tried to hide it using
error_reporting(0);
and
ini_set('display_errors',0);
but neither of two worked...
It is the first time that I have problem, if someone could lead me I'd be very grateful due to that I am stuck with it.
If you are having the same problem as me, check with phpinfo() if you are using a debug version of PHP. If you see that Debug Build has a value of yes, your problem will be fixed if you install a live version of PHP instead of a debug version
The Error itself is caused by running a Debug version of PHP 7, see the bug report. As noted by HPierce because it was a Debug build it overrides the usual PHP settings for error_reporting. However as the Original question is actually about how to hide certain [expected] error messages (Notices), my answer is to this detail specifically.
Kevin, the attempted ways to hide errors you've listed in your question would normally work on non-debug PHP builds. However, it is unwise to ignore the errors, rather than solving them at source. It's also (more) unwise to hide all errors simply due to having expected errors appearing.
As it's only a Notice, you can work around it by setting your error_reporting() value as below:
//report all errors except notices.
error_reporting(E_ALL & ~E_NOTICE);
I would suggest this is far wiser than turning off error reporting entirely which is not recommended. If you want to stop errors being output to browser (as referenced by Tina) you can use display_errors.
Perhaps you may also need to set
ini_set('error_reporting', 0);
depending on your php ini configuration?
Also make sure you set it before carrying out any of the code.

require_once fails on a readable file php wordpress site

I have a php script that is really simple, but requires some of the wordpress includes. I have used the code from their website for most of it but it is failing whenever I try to call the require_once parts of the scripts. here is the relevant code:
$fn = dirname(__FILE__) . '/wp-admin/includes/media.php';
if(!file_exists($fn))
{
echo 'No File';
}
if(!is_readable($fn))
{
echo 'File is unreadable';
}
require_once $fn;
Interstingly enough, The only echo that I get when the require_once is uncommented is the full path to the document. The file is both existing and readable. However, when I uncomment the require_once code it comes back with a 500 error.
On a slightly related point. What is the easiest way of debugging php. I haven't found anything that is VS easy yet (or even as easy to debug as Django!!)
PHP has various settings in php.ini for how logging works. You can also set them at runtime. It might be logging to a file somewhere rather than displaying the error. Consider trying:
error_reporting(E_ALL)
To debug your application. Don't leave it on when you're done working with it.
You should be developing and debugging the code locally on your workstation, not on a shared hosting server. On your local workstation you have access to the php.ini, Apache error log, and the PHP error log. You can also set project-specific settings for debugging using .htaccess files. For example, you can configure separate PHP error log files for each different project you're working on.
As #Steve Howard pointed out, there are many settings you can alter in the php.ini in order to get more detailed error reporting. In fact, most LAMP packages install a development copy of the php.ini, which is basically a template of a php.ini file that's optimized for detailed error reporting. Detailed error reporting is something you want on your local environment for debugging. It is NOT something want on your production environment where customers and potential hackers will end up seeing more information than they should!
If you don't know how to set up PHP on your workstation, take a look at XAMPP, MAMP, Macports, etc. There are many options. You don't need to be super technical to get a stack set up on your computer. Once you have a good dev environment setup on your computer you can tail the PHP error log and the Apache log.
One thing I like to do is to use the PHP error_log() function. This allows you to output custom messages to the PHP error log. For example, if I'm debugging code and I need to know what the value of $foo is, I can do something like this:
<?php
error_log("Foo is: " . print_r($foo, true));
This is much better than using var_dump() or echo to print debugging data to the screen because it won't interrupt the normal execution of the program or the display of its view layer.

Magento white screen of death

I am trying to compile my magento store's code. Initially compiling was producing an error which I tracked down to the Fooman Speedster advanced module. I removed the module entirely from my store's code and again recompiled. The compilation successfully completed this time and all classes (around 7500) could be seen in the/includes/src/ folder.
However after compilation, my site's frontend is showing the white screen of death with no error being generated in the apache error log. What is strange is that the backend is working perfectly fine.
I have also increased my memeory limit for php scripts to 1024M so that php running out of memory is not the problem.
Any suggestions as to what might be the propblem or how to go about tracking the problem/bug.
Reposting my answer from here. Hope it will help
Magento white screen on Admin log in page?
I faced with the same problem. Actually it was even worse because it was a commercial product and a new hosting for me with really strange server configuration. So I couldn't made errors appear in any log file.
As I've found out the magento white screen means some PHP Fatal error occured. So there is a proper way to show them. Just add at the begin of your index.php
ini_set('error_reporting', E_ERROR);
register_shutdown_function("fatal_handler");
function fatal_handler() {
$error = error_get_last();
echo("<pre>");
print_r($error);
}
And you will see what is really happening with your magento.
This is how I got it corrected(Hope will help you guys):
Use the following code in your index.php file
ini_set('error_reporting', E_ERROR);
register_shutdown_function("fatal_handler");
function fatal_handler() {
$error = error_get_last();
echo("<pre>");
print_r($error);
}
In my case it tolde me that error/503.php was unavailable.
3.The issue was with testimonial extension I used(http://www.magentocommerce.com/magento-connect/magebuzz-free-testimonial.html)
I deleted the testimonial.xml file in my app/etc/modules/testimoanial.xml.
delete “maintenance.flag" file.
I deleted all the folders from my var->cache directory and frontend started working.
As I read, it is caused by when your Persistent Shopping Cart enabled.
Set System > Configuration > Persistent Shopping Cart > General Options > Enable Persistence to disabled and try again.
You can have a look here.
It's a common problem with compilation, you can temporarily disable compilation by editing /includes/config.php and commenting out these lines:
define('COMPILER_INCLUDE_PATH', dirname(__FILE__).DIRECTORY_SEPARATOR.'src');
define('COMPILER_COLLECT_PATH', dirname(__FILE__).DIRECTORY_SEPARATOR.'stat');
After a lot of research and testing, I have come to the conclusion that while compiling there may be several errors that lead to the white screen of death. These will not be visible for some reason leaving you with no clue as to where is the problem.
In most cases - custom modules or installed modules are the culprits. The only reliable way to debug the magento compilation is to use the xdebug.scream = 1 in the xdebug configuration. This will scream out the error file/reason which can then be worked upon.
A better explanation could be found here:
http://www.brimllc.com/2012/03/magento-fun-with-debugging-the-magento-compiler/
Another reason for not seeing any error in any log might be the APC cache.
See my Stackoverflow answer here for more details.
You can
disable it via .htaccess: php_flag apc.cache_by_default off
clear the apc cache every time the page is called: add at the top of index.php apc_clear_cache(); (no solution but good to see if the APC is the problem)

PHP Deprecated errors won't disappear on WordPress Dashboard

TL;DR : Upgraded PHP on our server which caused a bunch of Deprecated errors to appear in WordPress, tried a number of fixes but the errors won't go away.
PHP Version: 5.3.10
WordPress Version: 3.3.2
I have a WordPress installation that has been up and running for a little while now, with no complaint.
This week, we upgraded PHP on the server to 5.3.10, after the update, the WordPress Dashboard began filling up with errors like this:
Deprecated: Assigning the return value of new by reference is deprecated in /home/random/public_html/wp-includes/class-simplepie.php on line 738
A large number (I suspect 116) of errors like this (each on a different line) appear in
Incoming Links
WordPress Blog
Plugins
As advised by a number of posts around the WordPress forums, I disabled error reporting both at a file level (by adding error_reporting(0); to the top of wp-config.php and/or other files) and using PHP.ini. Phpinfo confirms that error_reporting = 0.
This had no effect, with the warnings still showing up on the dashboard.
I tried disabling all of my plugins and reverting to the default theme (with a mind to enable each one in turn to see if one of them was causing the issue) but the errors continued to appear.
Next, instead of treating the symptom, I went to see if I could fix the cause of the issue.
Getting deprecated error with Simplepie
and
Assigning the return value of new by reference is deprecated
pointed to class-simplepie.php having some out of date syntax inside.
Using find/replace in my text editor I swapped all 166 instances of
=& new
for
= new
And I am still seeing errors on my dashboard.
So, as far as I can see, there should be no errors to report, and if there were, they shouldn't be showing up anyway.
Wordpress is not running in debug mode.
A paste of my phpinfo can be found here: http://pastebin.com/Pk68sDL1 if it is of any use to anyone.
Not sure what to try next. Any tips much appreciated.
D
try this and u will not have this errors:
error_reporting(0);
ini_set("display_errors", "off");
ini_set("display_startup_errors", "off");
Or set the same directives in your php.ini file in your server.
I was having the exact same problem today and I also tried all of the solutions you listed. Eventually I realized that after I replaced
=& new
with
= new
in class-simplepie.php, I also needed to reload the modules in the dashboard. This doesn't seem to happen when you just refresh the browser page, or even hide the module and then show it again.
So I highlighted the Incoming Links module on the Dashboard and clicked Configure. I changed the RSS feed URL to anything else (google.com), hit Submit, and it worked. Refreshed that module with no more deprecated errors from class-simplepie.php. Did the same for the Wordpress Blog module and that also worked.
The only thing I cannot figure out is how to refresh the Plugins module. It doesn't have a Configure option and I can't get it to reload like the others.
Edit: Plugins module works now as well. Just needed time to reset.
I had these warnings as well. I stumbled across a message by a developer of simplepie that this happens with PHP5.3+ and is related to the compatibility to PHP4. Using simplepie v1.3-dev drops this downwards-compatibility and fixes that.
Download from GitHub
Add this to the top of your wp-config.php file, right after the first
error_reporting(0);

Categories