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.
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
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.
I was wondering how can I stop PHP & MySQL errors from displaying to users but still have the errors logged in the server so I know something is wrong.
two ways:
Config your php.ini (turn error off)
Put a # after any action...
Example:
<?php
$a = #mysq_query("a bad query");
echo #$b; // $b donst exist, so thrwos an error but with the # dosnt show anything
?>
I want to point out that there is a good reason to surpress MySQL Errors. If there error gives away too much info about your database set up and schema (by showing the query in the error... joins... etc.) you don't want a live site showing those errors to the public. Of course you would want to log them. So in the interest of security this is a good single reason to not display them on a live site. As I said logging yes. Displaying no.
http://www.php.net/manual/en/errorfunc.configuration.php
Set display_errors to zero and define a log file with error_log in your php.ini or with ini_set or something.
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.
I'm new to PHP and I'm confused seeing some examples calling a function with a # prefix like #mysql_ping().
What is it for? Googling / searching is not much of a help since # gets discarded and 'alias' is not good enough keyword.
# suppresses errors, warnings and notices.
You can use it for good purpose if you complement it with a custom error handler or with due check of $php_errormsg variable so you can handle errors properly.
In my experience, this proper usage is not seen very much and is instead used a lot in the bad way, just to hide errors without acting on them.
More info at http://www.php.net/manual/en/language.operators.errorcontrol.php
It suppresses the output of error messages.
Contrary to another commentator here, I think that it is good programming practice to use it (especially if you are developing a web app, where the output would be mixed in the html of the output page).
Functions like mysql_connect return a resource identifier, or FALSE on errors. Use #mysql_connect(...) and check the return value.
Googling for "php at symbol" suggests that it asks PHP to not display any error messages that the call causes.
It suppresses any errors that might otherwise be output.
It is a recipe for pain and hardship, as it inevitably leads to difficulties when an error does occur, you are bound to spend hours tracking down the cause. If the # operator hadn't been used, then the error would have been found in seconds.
There is no good reason to use it, use the display_errors and error_log ini settings to prevent errors from displaying on a live site, and let them be shown on your dev site.
If there is an error that you don't want to see, you're better off just fixing it than suppressing it!
If it's something in an external lib and outside your control, just write it to the logs, turn off display_errors on production, and live with it. Because there's no telling whether the error you're suppressing now and are happy to live with will ALWAYS be the error that is thrown from there.
# === BAD
Suppress error messages:
http://bytes.com/forum/thread10951.html
Prefixing a function with the a symbol stops it triggering the PHP error handler if an error occurs. Bear in mind that you must do all the error handling yourself if you decide to use it.
$test = #file_get_contents('nonexistant.file');
if(!$test)
{
die('Failed');
}
A better practice is to turn display_errors off and use custom error handlers (see Error Exception).
Sometimes it is useful- especially if the admin doesn't want you to play with the php environment or the value isn't important and is mainly cosmetic. Do remember, though; it's a workaround, not a panacea.
[...]
.$foutDate = #filemtime($keyring); /* Don't care, as we've already established file */
$f["date"] = $foutDate;
$f["fullDate"] = date("r", $foutDate);
[...]