This is something that has been bothering me for a while now and I'm sure there's a simple solution.
So my basic page structure starts like this with the every page file first and the header second.
require_once '../private/core/ep.php';
include template('header');
the ep file contains autoincludes for classes and functions, so everything inside of there occurs above the header. Whenever errors occur internally I often have to inspect the elements in my browser and navigate through the HTML to find what the error is which is really time consuming. Is there anyway around this?
There are a few things you can do to keep your errors from showing up in your header. If you have access to make changes to your php.ini you can configure your error log so that all of your php errors can be logged there and set display errors to false. These can also be set in your ep.php file at the very top using the ini_set function.
Another solution is to configure your own error handler using http://www.php.net/manual/en/function.set-error-handler.php
You can then open a terminal and use "tail -f /my/log/file/location" to actively monitor your errors.
You could write a LOG function to a file or better to a database.
You will see exactly where your code broke.
Another thing you can try in enable error reporting on your server (php.ini)
I don't think there is any other way.
Ovidiu
Related
Hi I have got project where I have to do some changes, but then I do some changes in php files I can't see any changes in web browser, only then I deleted files, when I see error in windows, but if I comment all lines from same file, and want see changes, when I refreshed the page where will be page like before, what means I see page like normally, and if I download the file and open it I see commented lines.
So I am using YII framework, I understand that I should turn on debugging on, so in [project-name]/index.php file in the top I pasted code.
defined('YII_DEBUG') or define('YII_DEBUG',true);
But it didin't work for me, still can't see any changes.
I also try ctrl+f5 on page refresh.
Maybe I should look in to Apache configuration?
If some one know please help.
I believe that defined('YII_DEBUG') or define('YII_DEBUG',true); causes a debug dump to be sent to the screen when an exception is thrown. Without that code there will be a single line exception error.
I have my index.php page and just afrer my header i want to include a message.php file.
This message.php file executes some mysql queries, runs a couple of functions and in the end makes echo of some text.
If i go to mysite.com/message.php - i can see all the text i need in my browser. But if i add the following line:
<?php include "message.php"; ?>
to my index.php, the page loads only until the include statement and then produces 500 internal server error. How is that even possible? I'm totaly stuck here...
EDIT: I've figured it out, thanks for pointing me to the right direction with apache logs. Even though i didn't have the log access, i've made the edit to .htaccess with a statement php_value error_log log.txt. It dumped the error in the txt file in the same directory. The error was produced by a function that was a name that was already in use. That's why a separate enviroment wasn't producing the error.
Add the following to the top of your message.php:
ini_set('display_errors',1);
error_reporting(E_ALL);
As everyone has said, there is probably a simple error (maybe a missed quotation mark) that is throwing the error, but in that environment, it gets thrown as a 500 error rather than output to the screen. Enabling the above should reveal the problem.
As dm03514 pointed out, it might be that there's something in your message.php which is breaking your code. If there's a fatal error in that file, it'll cause a similar error in your main file.
Ask support for your error_log - this really helps debugging.
This is possible becuase you have an error in your message.php file! The next step is to figure out what is throwing the error. You can look at your web servers error logs to see the exact line. To solve this problem you only have to focus on the code in your message.php file.
Well, if you don't have access to the log files, try to run the same file in any other environment where you can see the errors.
That's the only way available.
Asking strangers to tell you what error you have in your php file makes very little sense, you know ;)
Try to make a copy of index.php, say copy.php, insert a test.ph include, displaying just some "KILLROY WAS HERE".
If that does work, go for <?php echo "..."; ?>.
if that does not work, place the include elsewhere and/or remove code.
One cause could be a hidden redirect, blocked because output already happened.
More likely some global variable was shared.
I think I'm having problems using PHP sessions because I've got cPanel installed on the same server and I believe it has additional security in place that prevents write access to /tmp
I can set a new folder, but am unsure what permissions / owners should this folder have.
Also where should it ideally be located?
/tmp should always be accessible. You can of course create a new "tmp" folder somewhere near you application. Just make sure it does not reside within the web root. Give it read/write permissions and chown it to the user of the webserver.
You then need to change the session_save_path to your new "tmp" folder.
Look, bro.
You are pulling this log from the wrong end. Guessing will never help you.
There is a thing called error message.
And you desperately need to get in touch with it.
It will tell you everything of the reasons why your sessions doesn't work.
If it's really a /tmp problem, PHP got a special error message for tis case:
Warning: Failed to write session data (files). Please verify that the current setting of session.save_path is correct (/tmp))
If you get this message, you can be certain that it's the reason for your sessions doesn't work and you can start to repair it.
It has an error message for the wrong session handler as well. As well for the every other problem.
So, you have to get error message first. Then read it nd it makes you know, what certain problem you have. Easy-peasy.
As a quick workaround you can use this code to bring error messages on the screen
error_reporting(E_ALL);
ini_set('display_errors',1);
but only to debug this situation and then remove it. Error messages shouldn't be output on the screen a production server.
So, learn to read error logs. I am sure your server put all errors messages into error_log. Just find it and look for PHP errors.
I'm having some issues to debug this in php. When I include this line:
require_once("http://" . $_SERVER["HTTP_HOST"] . "/dompdf/dompdf_config.inc.php");
what I get is just a blank page, I don't get any html code as response. Maybe the error messages are hidden ?
Quite often, when you get a WSOD (white screen of death), it's because there's a Fatal Error, and it's not displayed on the standard output -- i.e. the generated page.
To have it displayed, you need to :
set error_reporting to the right level
and enable display_errors
An easy way is to do that at the top of your PHP script, with a portion of code like this one :
error_reporting(E_ALL);
ini_set('display_errors', 'On');
In your specific case, you are trying to include/require something via HTTP ; which is often disabled.
See the allow_url_include directive, about that.
A possibility would be to enable that one in your PHP's configuration... But it's generally not considered as a good idea : it's disabled for security reasons.
And sending an HTTP request to include a file is slow -- and means your application will not work anymore if the remote server doesn't answer !
Also, here, you are trying to include a file from a remote server that is $_SERVER["HTTP_HOST"]...
... So, you are trying to include a file from a remote server that is, in fact, your own server ? i.e. not a remote one ?
If so, you should not try to include via HTTP ; instead, you should work with a local file ; this way (will need some tunning) :
require_once dirname(__FILE__) . "/dompdf/dompdf_config.inc.php";
This way :
No network un-needed request (you'll just read from the local disk) => faster and safer
And no need to enable allow_url_include
I should also add :
When including a local .php file, the content of the .php file is included in your page ; like if it's copy-pasted
When including a .php file via HTTP, chances are that the remote server will interpret the PHP code, and only send you the output back
Which means it's not the PHP code that will get included by your script
But only the output you'd get by executing that PHP code !
You should not require/include a remote file like this. Instead provide the local absolute or relative path.
Though insecure and not recommended, it is technically possible to do if certain configuration options are set. (allow_url_include)
See other answers below regarding display_errors for future debugging concerns. I often use the PHP command line interpreter to get the real error, without allowing error details to be presented to web visitors.
This a very unusual and insecure way to include files, but yet if you still want to use it, make sure that the file you're including isn't being executed on the remote server since you probably targeting the php source code on the require_once here not the final output of it.
The parameter to the require_once statement should be a file path, not a URL.
You are telling the web server to import a file from the file system, not the client to import the file from the web.
It is documented on the include statement page.
Try adding this as the first line of your script (after the <?php obviously):
error_reporting(E_ALL);
After debugging a CodeIgniter application that were installed into a new development environment, I have started to freak out when seeing white screens with nothing more available. I have been able to solve each and every one of the errors that have caused this, but it has taken seriously way too long time.
PHP error_reporting(E_ALL) & display_errors", 1 is set as well. I even installed Xdebug in hope of getting more output, but no. My logging settings are also working, but nothing is written to the log.
Is there a way to get something informative printed out instead of a complete white screen? It would certainly shorten my time spent on solving the eventual errors that cause this.
Reference:
Why does Code Igniter give me a white page?
If there's a fatal compilation error, then you may well get a blank page.
Try doing a
php -l <filename.php>
against your script
Look near the top of /index.php for a call to error_reporting() - and make sure it's not changing your php.ini configuration to something else (besides E_ALL).
And since you didn't mention your php.ini configuration, check to ensure you have error_reporting = E_ALL there as well.
I've found out, since the time of my question, that nothing seems to ensure that errors are always outputted with PHP, which seems to throw white screens here and there. Regardless of PHP's ini-settings.
I've found out that the best workaround however is to use the following line to ensure that error logging is put into a file easily is accessed and monitored by the application:
ini_set('error_log', MYPATH .'logs/errorlog.log');
As far as I've tested it, when white screens appear - it also gets logged into this errorlog. It seems to be the easiest way to know what happens when things go wrong.
Grep the files for 'error_reporting', and 'display_errors'. The application might turn it off somewhere.
Also, to be able to see parse errors, you need to set error_reporting/display_errors in the php.ini file, or a .htaccess file. Setting it in the script files will not do and will lead to the white page you describe if there are parsing errors.
Aside from everything else posted, also make sure that something masked with the # (error suppression operator) isn't throwing a fatal error.
The best thing is to have a checklist of the common problems that could cause this since CodeIgniter's default is already
error_reporting(E_ALL);
Same name controllers and models
using reserved words as methods
The list goes on...
Consider setting PHP's error_log configuration variable -- it can be helpful when you have code setting error_reporting() without your knowledge. Then you can check the error log and see what errors, if any, occurred.
I had this problem on my freshly installed server. Debian 7.
I enabled logging, error reporting, disabled gzip and so on.
However, my PHP-installation did not have MySQL enabled. Enabling MySQL did the trick for me.
Make sure your logs and cache folder inside /system are chmod'ed to 777.
Ensure that there isn't any whitespace in your files output outside of the CodeIgniter buffer, especially if compression is turned on. You can test this by turning off compression in your CodeIgniter configuration file.
See step two at: http://codeigniter.com/user_guide/installation/upgrade_141.html (Note that while this is for the upgrade, it contains a snippet of the configuration file which explains the problem.)
If you by chance have happened to create a cached output for that particular method inside your controller, then it may create a cached version of the page and practically that page is not even running.
The cached error output page is showing up. Please check your cache folder inside the application. It should only contain the index.html file.