So - strange situation I got here.
The statement error_reporting(0); has been giving me a server 500 error.
However, error_reporting(1); works just fine..
And its killing me, too many warnings for some of my URL validators. What's up with this? Any idea on how this can be fixed?
First of all, I'm sorry if I behave "smartass", but I have to tell you that if there are warnings, you should consider to fix them instead of just reduce them to silence... :)
Junk PHP code let bad things happen, and you won't like it. I understand 80% of the PHP code around is junk, but really try to fix that library, if it's not huge.
We can however try to solve the problem if you just make a simple .php file, with only one line:
<?php
error_reporting(0);
?>
and test if it fires the error. If it doesn't, the problem is not caused by error_reporting, but just triggered by it, and there's some sick stuff going on elsewhere. :)
try error_reporting(E_ALL); and ini_set("display_errors","On"); and check the errors that occur. After you fix those, there shouldn't be any problem.
Good luck
Shai.
P.S. i would be guessing for almost 100% that you use Chrome, because for some reason chrome would sometimes just show its own error screen instead of showing error messages. So also try another browser just to check the errors.
error_reporting()'s value is defined with constants, so don't use direct value to set it.
If you had used the constants, you would have noticed that none of them have 0 as value.
If you want to report all errors, there is an exception to the rule : use the value -1 :
error_reporting(-1);
Source : http://us.php.net/manual/en/function.error-reporting.php
And consider fixing all warnings! (and even notices if possible)
Note : the -1 value is used to be sure that even if more error code are added, they are all included.
Related
I have a problem with my Wordpress site, more specifically, The7 template. On every page, including the main page at the bottom of page below footer I have 4 Warnings which are the same:
“Warning: call_user_func_array() expects parameter 1 to be a valid callback, function ‘wp_filter_content_tags’ not found or invalid function name in on line”
I do not know how to solve it/turn it off. Could you tell me which PHP page or what exactly cause this problem to appear? It’s really annoying. Due to the fact that it is in the main body and not in any div/b/p/etc. tag I cannot hide it with CSS just for a while.
Kind regards
Peter
Hiding error reporting on prod
On prod you want to avoid showing errors, due to security and user experience reasons. To achieve this, in PHP you can run
error_reporting(0);
or, even better, in php.ini, you can have this line
error_reporting = off
What the error means
The error tells you that a function is to be called by name, but it does not exist. wp_filter_content_tags does not exist in your context.
Solution to the error
Even though you have hidden error reporting on prod, you still need to show errors on dev and that function might do something very useful. From the doc you can see that it's located in wp-includes/media.php. So, if you do not need to call this function, then search for its calls and remove them. If you need this function, then require or include it into your files. If, for some reason you cannot remove this function (for ex. you do not want to hack a template that might have some versions in the future), but the function/file is not helpful for you, then you can implement a function with the same name.
Thank you very much for answer. I used it to find solution and in my case there is a need to change wp-config.php a little bit. It means to add these specific lines to code:
ini_set('display_errors','Off');
ini_set('error_reporting', E_ALL );
define('WP_DEBUG', false);
define('WP_DEBUG_DISPLAY', false)
In my case it worked and no more errors / warnings showed on every / main pages.
Kind Regards
Peter
I want to migrate code from PHP 5.2 to 5.4. This worked fine so far except that all the code I use makes extensive use of just using an object with a member without any initialisation, like:
$MyObject->MyMember = "Hello";
which results in the warning: "Creating default object from empty value"
I know that the solution would be to use:
$MyObject = new stdClass();
$MyObject->MyMember = "Hello";
but it would be A LOT OF WORK to change this in all my code, because I use this many times in different projects. I know, it's not good style, but unfortunately I'm not able to spend the next weeks adding this to all of my code.
I know I could set the php error_reporting to not reporting warnings, but I want to be able to still get other warnings and notices. This warning doesn't seem to be effected by enable or disable E_STRICT at all. So is there a way to just disable this warning?!
Technically you could do this by installing your own error handler for warnings. From inside the handler check the string error message; if it's the one you want to suppress then return true, otherwise return false to let the default error handler do its thing.
However I would still recommend doing the right thing and manually fixing your code wherever this misuse does appear because, if nothing else, it gets you into the correct habit. Unless this is paid work (in which case there usually are concerns that override purity of implementation), consider this as a lesson and do the right thing.
I know I could set the php error_reporting to not reporting warnings, but I want to be able to still get other warnings and notices.
Don't disable the error reporting, leave it at an appropriate level, but disable the display_errors directive:
ini_set('display_errors', 0);
There's no reason to print notices to the screen in production.
Then as Jon said, use a custom error handler if you aren't already, example:
function my_error_handler($error_level, $error_message)
{
// write error message to log file
}
set_error_handler('my_error_handler');
You can pass in the error reporting level to the second param of set_error_handler. This way you can take your time and do the right thing, which is fix the code to stop generating notices.
If you're moving a lot of sites over to 5.4, you can probably have your server admin turn off display_errors in php.ini until you have enough time to fix everything. Better yet, stage everything and fix it before upgrading, but that may not be an option.
you really could use an IDE for php and try to do this:
Search for $MyObject->MyMember = "Hello";
Look for the results and if it brings the right things, try to replace that with:
$MyObject = new stdClass();
$MyObject->MyMember = "Hello";
So maybe the IDE would do the long work for you...
I had the same problem i handle it like bellow in production environment
\error_reporting(\E_ERROR);
I have to say that my application doesn't need/generate errors, it's on a very controlled environment so doing this wouldn't hurt much, but if your application is an error prone one you should have you own error handler and with a proper regex and preg_match ignore the “Creating default object from empty value” warning and log/prompt others at your discretion.
My problem was, after migrating a website to another server using backup buddy, I came upon a the white screen of death.
I turned on debug mode in Wordpress and still no errors, just white screen.
So I tried removing all the files and re uploading them again and leaving the database as is (the one imported by BackupBuddy) but it's still giving me white screen.
So I tried to trace the specific line where the white screen occurred and got stuck in a weird behavior.
In /wp-content/plugins/woocommerce/widgets/widget-init.php:
include_once('widget-cart.php');
include_once('widget-featured_products.php');
include_once('widget-layered_nav.php');
include_once('widget-price_filter.php');
include_once('widget-product_categories.php');
include_once('widget-product_search.php');
include_once('widget-product_tag_cloud.php');
include_once('widget-recent_products.php');
include_once('widget-top_rated_products.php');
When I add a "die('boom');" before
"include_once('widget-price_filter.php');" = boom is printed out.
When I add a "die('boom');" after
"include_once('widget-price_filter.php');" = boom is NOT printed
out.
So it's safe to say that the bug is inside widget-price_filter.php right?
The problem is when I add a die at the beginning of widget-price_filter.php, it does not print it out. It's like the line where the error occurred is nowhere.
What could be the cause for this?
So it's safe to say that the bug is inside widget-price_filter.php right?
Yes, totally (and you followed the correct way of debugging).
The problem is when I add a die at the beginning of widget-price_filter.php, it does not print it out. It's like the line where the error occurred is nowhere.
If (as you say you've done) you have added die('HELLO'); right at the top (after the <?php) and it does not appear - this means there is one of two problems
File not found
A syntax error in that page.
You can solve in 1 of three ways:
Check the php error logs (if you have access)
Before you call the "include_one" (in init.php) add:
error_reporting(E_ALL);
ini_set('display_errors', 'on');
Completely empty the code (just leaving the <?php die('HELLO'); ?>, check that appears and then add code in bit by bit.
If you got route 2, remember to take it out when you've got it working. Very important!
+1 for actually taking time to try to solve it yourself before posting (with the echo and die). So I hope that helps with the rest.
I've to make a website works and I don't know what to do right now. I can run it in a virtual machine with Ubuntu, on my company's server in Debian, on a WAMP... but I can't get it working in a server from a client.
I think the problem is with the gets. The form that I can't modify is sended by get, using the next url:
http://domain.com/SGAP/dades_proj_edit.php?idedit=2011854&id=&projectname=afsdfasdf&comptitle=asasfdafsdafs&codarea=ECIV&grauimp=1&codtipus=2&codsubtipus=6&subtipusdef=fdsaafasfddfs&codpais=8&clientid=2&promotor=asdfa&entfin=fsdafadsfds&impcontract=2&initdate=21%2F01%2F2011&findate=30%2F01%2F2011&uteflag=false&utepartic=&utepercent=0&descprelim=fdsadasdadfsadfs&codprojstatus=1&statusstamp=25%2F01%2F2011&cruserid=&action=update
Firefox shows a blanc page with no error. I've tried to force to show all errors with error_reporting(E_ALL) and ini_set("error_reporting", E_ALL) to show if something happens but the wait page is showed with 0 errors.
I supposed that was a $_GET error and I tried to put on the top of the page and in the end of it a <?php if($_GET["test"]) echo "Works"; ?> and call the webpage with: domain.com/SGAP/dades_proj.edit.php?test=testing and it works from top to end... I don't know where is the error.
What I can check to figure where is the white page comming? Thank you in advance!
Here's what I would do.
Start at the top of the file/stack, and add this code:
<?
$myUniqueCounter = 0;
error_log(++$myUniqueCounter . ', line ' . __LINE__ );
Then, copy and paste the error_log line all over the file/stack, and see where it stops logging.
I have occasionally seen php die without a blank output. Generally, the only way to solve this is to remove everything from the file, and then add code back in one line at a time. When it stops working, you know that whatever you just added caused the fault. You can try running php with the -l flag, to check the syntax, but this might not find the problem; the only sure way really is to just to add or remove things until the output changes.
I know this isn't much help, but there is no other way to debug the problem, short of executing php itself with a debugger... actually, you could do that; can you run php from gdb? That might help you find what is causing the issue, but no guarantees.
I'm using a PHP4 implementation of SimpleXML, which uses the built-in xml_* functions from PHP 4. I have an odd problem that I'm unable to diagnose due to no error reporting on the server and not being able to turn on error_reporting.
I've modified the Parse() function to include this:
[stuff here to initialise the parser]
echo '<textarea rows="8" cols="50">', htmlspecialchars($this->xml), '</textarea>';
$parsed = xml_parse($this->parser, $this->xml) or die('error with xml_parse function');
The textarea displays the XML fine, and the XML itself is perfectly valid. But the page stops right after that and doesn't appear to call the xml_parse function, or output the 'die' message.
Should also add that this works fine on other pages, it just appears to be a problem with this particular page for some reason.
What could be happening here? Are there other ways to debug this?
Yes, you can debug this by adding this to your script:
error_reporting(E_ALL);
Thus will turn on error reporting.
Also, using ‘or die‘ only works if the function call before it returns a falsey value. In the event of fatal errors, it doesn't help.
Try to set the error reporting on and see what error comes though, it is likely there is some fatal error coming up:
ini_set('display_errors', true);
error_reporting(E_ALL);
Try getting the XML specific parser error message:
echo xml_error_string(xml_error_code($parser));
IIRC, these are not output by default no matter what your error reporting is set to.
Reference:
xml_get_error_code
xml_get_error_string
It seems that the problem was due to the XML being too big for the parser. Since we can't turn on error_reporting there was no way to get proper debugging info.
I decided to use a separate script the generate the HTML for the page, to avoid issues with the page going down occasionally.