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.
Related
I am having an issue when I have a php application that is returning an internal server error (500) however nothing is showing up in the error log.
Now I know there are error with what I am trying to run, I know I have missing some files and what not but something should show in the apache error log (otherwise how are I supposed to know exactly what I am missing).
I created a test script is errors it in under the same vhost configuration and those error show up fine so everything seems configured right as far as php/apache. Are there certain php errors that does show up in the error log (php is configure to display any type of notice, warning, , error, fatal error, etc...)?
This is running on ubunut 10.04 with the standard apache and php from the ubuntu repo with apt-get.
Scan your source files to find #.
From php documentation site
Currently the "#" error-control operator prefix will even disable
error reporting for critical errors that will terminate script
execution. Among other things, this means that if you use "#" to
suppress errors from a certain function and either it isn't available
or has been mistyped, the script will die right there with no
indication as to why.
Copy and paste the following into a new .htaccess file and place it on your website's root folder :
php_flag display_errors on
php_flag display_startup_errors on
Errors will be shown directly in your page.
That's the best way to debug quickly but don't use it for long time because it could be a security breach.
If you still have 500 error and no logs you can try to execute from command line:
php -f file.php
it will not work exactly like in a browser (from server) but if there is syntax error in your code, you will see error message in console.
Maybe something turns off error output. (I understand that you are trying to say that other scripts properly output their errors to the errorlog?)
You could start debugging the script by determining where it exits the script (start by adding a echo 1; exit; to the first line of the script and checking whether the browser outputs 1 and then move that line down).
In the past, I had no error logs in two cases:
The user under which Apache was running had no permissions to modify php_error_log file.
Error 500 occurred because of bad configuration of .htaccess, for example wrong rewrite module settings. In this situation errors are logged to Apache error_log file.
For Symfony projects, be sure to check files in the project'es app/logs
More details available on this post :
How to debug 500 Error in Symfony 2
Btw, other frameworks or CMS share this kind of behaviour.
Here is another reason why errors might not be visible:
I had the same issue. In my case, I had copied the source from a production environment. Hence the ENVIRONMENT variable defined in index.php was set to 'production'. This caused error_reporting to be set to 0 (no logging). Just set it to 'development' and you should start seeing error messages in apache log.
Turned out the 500 was due to a semi colon missing in database config :-)
Another case which happened to me, is I did a CURL to some of my pages, and got internal server error and nothing was in the apache logs, even when I enabled all error reporting.
My problem was that in the CURL I set
curl_setopt($CR, CURLOPT_FAILONERROR, true);
Which then didn't show me my error, though there was one, this happened because the error was on a framework level and not a PHP one, so it didn't appear in the logs.
You need to enable the PHP error log.
This is due to some random glitch in the web server when you have a php error, it throws a 500 internal error (i have the same issue).
If you look in the PHP error log, you should find your solution.
see here in the doc of how to enable it in the php.ini
Be sure your file permissions are correct. If apache doesn't have permission to read the file then it can't write to the log.
What happened for me when this was an issue, was that the site had used too much memory, so I'm guessing that it couldn't write to an error log or displayed the error. For clarity, it was a Wordpress site that did this. Upping the memory limit on the server showed the site again.
SOLVED
I struggled with this and later on, I realized that I was working on PHP 5.6, so I upgraded to PHP 7.0, then I released there were comments placed by git for conflicting codes. I found something like this in my code <<<<<<<< But solved it.
We want to monitor all php errors. We can check all errors with error_log file.
Error logs files become so heavy.
So it is very difficult to check errors in error_log file.
Could it possible to write php error_log file on date-wise example '19-05_2015_error.log'
or we can write error like "fetal.log" "notice.log"
You can absolutely do it in PHP. A popular logging library is Monolog.
You can change the PHP config at beginning of your application, create the log file dynamically.
<?php
function logByDate(){
$sPath = '/logs/application/PhpError_' . date('Y-m-d') . '.log';
ini_set('error_log', $sPath);
}
// To validate only, it is not necessary
echo 'Actual log ' . ini_get('error_log') . PHP_EOL;
logByDate(); //Call it at beginning
// To validate only, it is not necessary
echo 'Validate new log ' . ini_get('error_log') . PHP_EOL;
To get logs in daily format (19-05_2015_error.log) you can use logrotate if you're on a UNIX stack (but it' a bit more complicated if you're on a Windows stack).
There are some useful hints on controlling duplication and suppressing error messages.
As far as I know, the mod_log_config module does not accept variables for file names so that excludes the most straightforward possibility. Apache-based solutions you can actually use include basically:
Send logs to a script and let the script choose the file name.
Good old log rotation.
Said that, I think PHP has pretty good built-in logging. You can do exactly what you are asking for with the error_log() function (together with e.g. date('Y-m-d')). You can even define a different file for different error types. Sure, that will not capture errors that prevent PHP code from running (such as parse errors, request time-outs...) but you can set the error_log directive as fallback mechanism—these situations should be rare enough to keep the log file manageable.
One more thought: make sure your development box has full error reporting enabled (many devs use third-party bundles with default settings and happily write buggy code). It isn't normal to have so many logged errors in a production server.
I have a CodeIgniter PHP app running on a Heroku Cedar instance.
We are running a PHP app and we need to log errors, but NOT print them to the screen. No matter what I do, the errors are printing to the screen, which is not safe for production.
Here is the PHP code which works on my local environment and everywhere else (besides Heroku):
error_reporting(E_ALL); #we care about all errors
ini_set('display_errors',0); #but DONT print to screen
I have seen this document which suggested I try adding a custom CodeIgniter logging class, which did not work.
I also added a phpinfo() to the app to check if somehow my settings were being overridden downstream, but it shows that display_errors is set to "Off".
So why am I STILL seeing errors printed on the screen?
It turns out that CodeIgniter 2.x has some completely asinine error handling in which they use a custom error handler to ignore the developers configurations. Apparently this is fixed in v3.
I was able to fix it by just commenting out the custom error handling, which for me was located in in CodeIgniter.php, line 72...
//set_error_handler('_exception_handler');
Or the best solution of all: don't use CodeIgniter in the first place.
How can we debug a PHP script when display_errors is off and PHP is running in safe mode ?
The best way is to use error_log()
http://php.net/manual/en/function.error-log.php
And you can set specific handler to that method. Either record it to database, file or simply display the error.
If you want to set handler method you can use: set_error_handler
If you're in a development environment you should disable safe_mode and enable error_reporting. On a production environment you should probably not do live debugging (since it's live). If you want to track down errors that seem to be only present on the production environment use error_log, or use the logging mechanism of the framework you are using, and check the logs afterwards. This way you won't break the normal operation of your production environment. Some frameworks like symfony provide a separate interface to access your system in another environment (for example accessing index.php has error reporting disabled but frontend_dev.php has not)
If you don't have a separate production and development environment it is high time to separate the two. You can for example install XAMPP or similar to your development PC, where you can do the development and only deploy to the live servers if you have already debugged / tested / etc. your code.
You can use that:
error_reporting(E_ALL);
ini_set('display_errors','On');
ini_set('error_log','my_file.log');
PHP writes log file to file.
If you can't enable display errors directive, you can using var_dump, debug_backtrace and exceptions for debugging php source code.
When ever error display is off, only way we can debug the code with echo $var; exit; OR var_dump($list); exit;
var_dump($variable);
exit;
OR
echo $variable;
exit;
OR
echo "<pre>";
print_r($variable);
exit;
"Whenever you are tempted to type something into a print statement or
a debugger expression, write it as a test instead"
--Martin Fowler
I am having an issue when I have a php application that is returning an internal server error (500) however nothing is showing up in the error log.
Now I know there are error with what I am trying to run, I know I have missing some files and what not but something should show in the apache error log (otherwise how are I supposed to know exactly what I am missing).
I created a test script is errors it in under the same vhost configuration and those error show up fine so everything seems configured right as far as php/apache. Are there certain php errors that does show up in the error log (php is configure to display any type of notice, warning, , error, fatal error, etc...)?
This is running on ubunut 10.04 with the standard apache and php from the ubuntu repo with apt-get.
Scan your source files to find #.
From php documentation site
Currently the "#" error-control operator prefix will even disable
error reporting for critical errors that will terminate script
execution. Among other things, this means that if you use "#" to
suppress errors from a certain function and either it isn't available
or has been mistyped, the script will die right there with no
indication as to why.
Copy and paste the following into a new .htaccess file and place it on your website's root folder :
php_flag display_errors on
php_flag display_startup_errors on
Errors will be shown directly in your page.
That's the best way to debug quickly but don't use it for long time because it could be a security breach.
If you still have 500 error and no logs you can try to execute from command line:
php -f file.php
it will not work exactly like in a browser (from server) but if there is syntax error in your code, you will see error message in console.
Maybe something turns off error output. (I understand that you are trying to say that other scripts properly output their errors to the errorlog?)
You could start debugging the script by determining where it exits the script (start by adding a echo 1; exit; to the first line of the script and checking whether the browser outputs 1 and then move that line down).
In the past, I had no error logs in two cases:
The user under which Apache was running had no permissions to modify php_error_log file.
Error 500 occurred because of bad configuration of .htaccess, for example wrong rewrite module settings. In this situation errors are logged to Apache error_log file.
For Symfony projects, be sure to check files in the project'es app/logs
More details available on this post :
How to debug 500 Error in Symfony 2
Btw, other frameworks or CMS share this kind of behaviour.
Here is another reason why errors might not be visible:
I had the same issue. In my case, I had copied the source from a production environment. Hence the ENVIRONMENT variable defined in index.php was set to 'production'. This caused error_reporting to be set to 0 (no logging). Just set it to 'development' and you should start seeing error messages in apache log.
Turned out the 500 was due to a semi colon missing in database config :-)
Another case which happened to me, is I did a CURL to some of my pages, and got internal server error and nothing was in the apache logs, even when I enabled all error reporting.
My problem was that in the CURL I set
curl_setopt($CR, CURLOPT_FAILONERROR, true);
Which then didn't show me my error, though there was one, this happened because the error was on a framework level and not a PHP one, so it didn't appear in the logs.
You need to enable the PHP error log.
This is due to some random glitch in the web server when you have a php error, it throws a 500 internal error (i have the same issue).
If you look in the PHP error log, you should find your solution.
see here in the doc of how to enable it in the php.ini
Be sure your file permissions are correct. If apache doesn't have permission to read the file then it can't write to the log.
What happened for me when this was an issue, was that the site had used too much memory, so I'm guessing that it couldn't write to an error log or displayed the error. For clarity, it was a Wordpress site that did this. Upping the memory limit on the server showed the site again.
SOLVED
I struggled with this and later on, I realized that I was working on PHP 5.6, so I upgraded to PHP 7.0, then I released there were comments placed by git for conflicting codes. I found something like this in my code <<<<<<<< But solved it.