Common handler i used
<?php
function error_msg($err_type,$err_msg,$err_file,$err_line)
{
$fh=fopen("error/errorlog.txt","a");
$date1=date("Y-m-d H:i:s");
$er="
===============================================================================================================
"."
Error: Type: ".$err_type."Message: ".$err_msg."ErrorFile: ".$err_file."Errorline: ".$err_line."Time: ".$date1.
"
===============================================================================================================
";
fwrite($fh,$er);
fclose($fh);
}
set_error_handler("error_msg");
?>
These codes Log error perfectly. Since i am using framework i cant use this codes. so i am using KLogger. KLogger perfectly logs my error but it also display error in front screen to user.
How to log error using KLogger If any one use this KLogger Help me how to use with simple examples.
Just do something like:
require_once 'KLogger.php';
$log = KLogger::instance('/var/log/');
$log->logInfo('Returned a million search results');
$log->logFatal('Oh dear.');
# Output will log to the path you specified, at log_[current-date].txt
It's crazy simple. Read the docs at GitHub
PS, I wrote KLogger.
Related
I have a php script in root of my site. I have added a cronjob in my cpanel.
It is working with basic database operations like shown below:
<?php
require_once "classes/class.database.php";
$db = new database;
$db->connectToDB();
$data = date("Y/m/d H:i");
$res = $db->insertRow("cron",array("datetime"),array($data));
echo $res;
?>
In same file I have replaced these codes with codes below which are real codes that I want to schedule but it is not working. If I enter manually, it works but by this way it doesnt working.
Real Codes:
<?php
require_once "/home/domain/subdomain.domain.com/share/share.php";
$share = new share;
$share->sharePosts();
?>
I dont think there is an error in my code because it works manually however I want to be sure about that. Can I log output of this file?
Thanks in advance.
I have finally solved the issue.
I have enabled error logging with codes below.
error_reporting(E_ALL);
ini_set("log_errors", 1);
ini_set("error_log", "/tmp/php-error.log");
I have tried to mail myself (it is cpanels property) and just echo something.
Mail came succesfully. Then I wrote wrong code (I wrote wrong path to "required_once"), when I execute manually, gives fatal error. Fatal errors not mailed. After that I replaced "require_once" with "include" to avoid fatal errors, then it noticed an error but this time it mailed to me. Error was "No such file." Then I tried path like that "/home/domain.com/yourcron.php" and no errors. In conclusion, all paths must be like "/home/domain.com/yourcron.php".
I came across in a project of about 900 files with 3 millions lines of code, and my boss asked me to find a solution to prevent mysql_error() to show errors.
This is the syntax
mysql_query() OR die(mysql_error())
So, how can I disable the mysql_error() from showing errors?
function mysql_own_error($debug = false){
$msg = mysql_error();
if($debug){
echo $msg;
}else{
// Function to log errors here.
}
}
With that you can set a global debug-variable $debug. Only if that is true output the error msg.
Now replace every mysql_error() with mysql_own_error($debug). There are Editors that can do suche replaces fast.
With that you will prevent the mysql_error() from showing errors publicly but you can still debug the code if you need to.
If you're still having errors then your project is not finished yet.
One way would be to do a site-wide find/replace on your files and replace the OR die(mysql_error()) with an # in front of mysql_error() like so: OR die(#mysql_error()).
Placing an # in front of a function call suppresses error messages. But use it carefully, this is not always a good solution.
Read this post which links to this article to know if it's a good solution for you.
I would change all OR die() occourrences to a custom error-handling function, then if you get an error you will still know about it without displaying them to users.
Yes, it would take a lot of time, but a good project takes a lot of time.
Check this article to create your own error-handling function and this other one to Enable PHP error logging via .htaccess, they really helped me.
How would I write a MySQL error to a file instead of displaying it to the user?
here is what I have so far...
if (!mysql_query($sql_query,$connection))
{
die('Error: ' . mysql_error());
}
echo "Success!";
You can use the error_log function in php for that.
error_log("You messed up!", 3, "/var/tmp/my-errors.log");
Edit: so in your case this would look like the following (although i would use a different if statement)
if (!mysql_query($sql_query,$connection))
{
error_log(mysql_error() . "\n", 3, "/var/tmp/my-errors.log");
}
echo "Success!";
Use error_log, or fopen/fwrite/fclose/etc.
I often use create my own error handler with something like set_error_handler in PHP and use trigger_error to capture ALL errors and write them to file. This may be a better scenario for you; rather than writing numerous error_log()'s, you can just create an error handler function and then use trigger_error.
Firstly, you should not use die if you do not want to display your error message to the user.
Secondly, instead of using die, you must log your error message into a file. If you are using some logging library, you may output the error to some log, else you may want to have a look at File handling in PHP.
Link - http://davidwalsh.name/basic-php-file-handling-create-open-read-write-append-close-delete
This is a bit of a long shot, but I figured I'd ask anyway. I have an application that has web-based code editing, like you find on Github, using the ACE editor. The problem is, it is possible to edit code that is within the application itself.
I have managed to detect parse errors before saving the file, which works great, but if the user creates a runtime error, such as MyClass extends NonExistentClass, the file passes the parse check, but saves to the filesystem, killing the application.
Is there anyway to test if the new code will cause a runtime error before I save it to the filesystem? Seems completely counter-intuitive, but I figured I'd ask.
Possibly use register_shutdown_function to build a JSON object containing information about the fatal error. Then use an AJAX call to test the file; parse the returned value from the call to see if there is an error. (Obviously you could also run the PHP file and parse the JSON object without using AJAX, just thinking about what would be the best from a UX standpoint)
function my_shutdown() {
$error = error_get_last();
if( $error['type'] == 1 ) {
echo json_encode($error);
}
}
register_shutdown_function('my_shutdown');
Will output something like
{"type":1,"message":"Fatal error message","line":1}
Prepend that to the beginning of the test file, then:
$.post('/test.php', function(data) {
var json = $.parseJSON(data);
if( json.type == 1 ) {
// Don't allow test file to save?
}
});
Possibly helpful: php -f <file> will return a non-zero exit code if there's a runtime error.
perhaps running the code in a separate file first and attach some fixed code on the bottom to check if it evaluates?
I've got a test script - test1.php:
echo "2";
include_once("api_class.php");
echo "3";
$objAPI = new API();
echo "4";
api_class.php has:
<?php
class API extends DATABASE
{
...
}
?>
However, when I access test1.php, I see only:
23
What am i doign wrong?
You didn't get the class source pasted in, but something must be wrong with your syntax. Add the following line to the top of your file and it will output verbose error messages that should point you in the correct direction.
error_reporting(E_ALL);
Most likely, there is an error in api_class.php, more specifically in the API constructor and it is failing. And you have debug/error messages turned off in PHP.
Either turn debug/error messages display on or check your server logs to find the error message.
I 'd guess that the API class expects to establish a database connection (maybe configured by constructor parameters?) and calls die if it cannot. Which is probably what happens when you try to construct a new API.