I'm developing with Symfony 2. The thing is that not always I can see the errors or var_dumps that I use to debug. I can see them if I go to inspector->network and select the proper file and this is very annoying.
How could I see it directly to the browser?
I use Xdebug.
I have in my php.ini:
display_errors = On
And I tried with:
xdebug.force_display_errors = 1;
xdebug.force_error_reporting = -1;
but that doesn't work.
Any idea?
------- Editing ------
This is an example of how i have to debug.
I have to go to inspector -> network and select the proper file. Apart of being very annoying, it is not efficient. Problem to see the full result as I cant scroll down or scroll right.
----- End Editing -----
I'd like to avoid to write any init_set or others options in my code if possible.
Another question... if a var_dump have more than 120k character or it is protected property how can I display it? So far I was changing it to public to dig in.
You have 2 ways to resolve your issue. First - you can directly use under your class namespace ini_set('error_reporting', E_ALL);, (but this is a not a best practice) or try to find the same string in your php.ini file and set it to E_ALL
error_reporting = E_ALL
display_errors = On
And finally you need to restart your web server.
About your second question - use Symfony Var Dumper for nice data output. Note that var-dumper sometimes is not compatible with old symfony versions. Use var-dumper 3.4 for best compatibility.
Related
I have a form that allows upload three files at the same time but just one is required. That works fine, my only problem is the following: if I upload three files I haven't any problem but if I upload one or two files (leaving two or one files empties) I obtain the following notice:
Notice: No file uploaded in Unknown on line 0
As much as empty files. The files are uploaded properly without any other problem, but I want remove that notice... or unless hide it, although I prefer remove it. I tried to hide it using
error_reporting(0);
and
ini_set('display_errors',0);
but neither of two worked...
It is the first time that I have problem, if someone could lead me I'd be very grateful due to that I am stuck with it.
If you are having the same problem as me, check with phpinfo() if you are using a debug version of PHP. If you see that Debug Build has a value of yes, your problem will be fixed if you install a live version of PHP instead of a debug version
The Error itself is caused by running a Debug version of PHP 7, see the bug report. As noted by HPierce because it was a Debug build it overrides the usual PHP settings for error_reporting. However as the Original question is actually about how to hide certain [expected] error messages (Notices), my answer is to this detail specifically.
Kevin, the attempted ways to hide errors you've listed in your question would normally work on non-debug PHP builds. However, it is unwise to ignore the errors, rather than solving them at source. It's also (more) unwise to hide all errors simply due to having expected errors appearing.
As it's only a Notice, you can work around it by setting your error_reporting() value as below:
//report all errors except notices.
error_reporting(E_ALL & ~E_NOTICE);
I would suggest this is far wiser than turning off error reporting entirely which is not recommended. If you want to stop errors being output to browser (as referenced by Tina) you can use display_errors.
Perhaps you may also need to set
ini_set('error_reporting', 0);
depending on your php ini configuration?
Also make sure you set it before carrying out any of the code.
I'd like to see any PHP errors that are occuring, ie the "Expected ; on line 5 of myfile.php" sort of thing. Unfortunately, I cannot seem to figure out how to see this information.
I've set E_ALL, display_errors ON, friendly error messages are turned off, IIS is set to pass-through on errors, what am I missing?
Syntax errors used to show up as stated above on any page; they no longer do. We moved the server to a localhost for development, and I guess didn't mimic exactly the server config. Now I'm stumped.
Tried on IE and Chrome, neither of which show the errors.
Errors are logged in PHP's log file, but I'd still like them to be displayed on the page; at least for now.
UPDATE:
Just tried adding ini_set('display_errors', 'on'); directly into the requested page, and it now works.. but why? Why does it need to be set locally? My PHP.ini file has this declared already.
To answer the first part of the question; to see the errors when using ajax: You can use the developer tools of your browser to see the exact response from the server.
In FireBug for Firefox for example, you go to the Net tab and there you see all ajax request popping up as they happen. Opening one of these requests will give you an overview with more tabs like Response and HTML.
Try using:
error_reporting (-1);
E_ALL isn't really "all" for php < 5.4.
Also, make sure 'display_errors' is set.
ini_set( 'display_errors', 1 );
Well, looks like this is half my own stupidity, half the cloudiness of automatic installations.
Turns out there were TWO php.ini files, and that IIS used the one located within the iis express directory on the main drive, instead of the regular PHP directory.
So to anybody else having this problem, I'm providing the full list of crap you have to wade through to get the errors as you would like:
1) Turn off the IIS default error pages
2) Disable 'friendly error messages'
3) Ensure you are using the CORRECT php.ini file, and change the parameters as needed. Specifically error_reporting and display_errors.
All of this is necessary before seeing all of the error messages you need right in the browser.
I'm not sure why, but xdebug does not highlight var_dump(). But config seems to be fine. Have no idea why... Any suggestions?
This is my phpinfo(); http://pastebin.com/A45dqnWN
plus even xdebug_var_dump() doesn't highlight anything. It works, but look like normal var_dump().
I found that option "xdebug.default_enable Off Off" in you php_info(). I also have noticed that in last versions of EasyPHP this option is turned off. So turn it on by setting this line in php.ini:
xdebug.default_enable=1
Next is just common operation which disables var_dump and other errors in HTML output completely (not your case, but maybe helpful for others):
html_errors = On
For Xdebug 3 you need to enable develop mode in your php.ini:
xdebug.mode= develop
You can also use multiple modes at once as explained here.
The following values are accepted (for xdebug.mode):
off
Nothing is enabled. Xdebug does no work besides checking whether functionality is enabled. Use this setting if you want close to 0 overhead.
develop
Enables Development Helpers including the overloaded var_dump().
coverage
Enables Code Coverage Analysis to generate code coverage reports, mainly in combination with PHPUnit.
debug
Enables Step Debugging. This can be used to step through your code while it is running, and analyse values of variables.
gcstats
Enables Garbage Collection Statistics to collect statistics about PHP's Garbage Collection Mechanism.
profile
Enables Profiling, with which you can analyse performance bottlenecks with tools like KCacheGrind.
trace
Enables the Function Trace feature, which allows you record every function call, including arguments, variable assignment, and return value that is made during a request to a file.
You can enable multiple modes at the same time by comma separating their identifiers as value to xdebug.mode: xdebug.mode=develop,trace.
As mentioned by #Shadoweb for Xdebug v3 you want debug to allow stopping at breakpoints, and develop to format the var_dump
The following you'll likely want in php.ini therefore:
xdebug.mode=develop,debug
As an aside, I also needed xdebug.start_with_request=yes to replace the renamed xdebug.xdebug.remote_enable=1 setting to get step debugging working in my IDE.
For php 7.0.2 and xdebug 2.4.0
xdebug.default_enable=1
+
html_errors = On
Still does not colorize xdebug_var_dump() output.
but this patch fixes my issue. It applies to the xdebug.c and xdebug_var_dump() only. I think they made a mistake that xdebug_var_dump works only if it need to be overload function.
## -2191,11 +2191,6 ##
int i, len;
char *val;
- if (!XG(overload_var_dump)) {
- XG(orig_var_dump_func)(INTERNAL_FUNCTION_PARAM_PASSTHRU);
- return;
- }
-
argc = ZEND_NUM_ARGS();
#if PHP_VERSION_ID >= 70000
Turn off xdebug.mode=debug in php.ini like
;xdebug.mode=debug
and restart Apache.
I would like to log PHP errors on a CakePHP site that has debug = 0. However, even if I turn on the error log, like this:
error_reporting = E_ALL & ~E_NOTICE & ~E_DEPRECATED
log_errors = On
it doesn't log errors.
The problem is that even for a parse error that should cause the CakePHP environment to not load completely (I think), it still blocks the error from being logged. If I set debug to 3, it logs to the file without issue.
I am using CakePHP 1.2. I know this is apparently made easier in 1.3, but I'm not ready to upgrade.
Another way to keep track of and log errors would be to use the Referee plugin as it provides a way to arbitrarily log and catch all (including fatal) errors that occur during exection.
define('LOG_ERROR', 2); in core.php
PHP should log errors to its own logfile, regardless of what CakePhp is doing.
Look in /etc/php.ini file (or wherever yours lives) and search for error_log. This will show you where the PHP log resides on your system.
There is a bug in CakePHP 1.2-1.3 where PHP errors/warnings are suppressed in view code when debugging is disabled.
In the file cake/libs/view/view.php on line #664 it reads
#include ($___viewFn);
But the # directive suppresses errors for the entire view handler. Instead it should be:
include ($___viewFn);
Which allows PHP errors/warnings to be generated in view code and subsequently get logged. Once I changed this and had the right logging settings in core.php I was finally able to get complete logs in production.
Sometime the reason could be very different. For example the framework you are using may have its own internal caching module which keeps the value in buffer while you keep on trying. Check whether duplicate copies are getting generated or not. Typically those files would be named as filename.ext.r123 and so on.
I've been using Zend Framework and just living with this problem for a while, but it's now just gotten too annoying so i'll send the question out to you.
There are certain problems within the Zend framework that Zend can recognize (such as calling a nonexistent controller), and will send that problem to the ErrorController. I've got that working fine.
There seem to be some problems that Zend Framework will fail and display the error through php, like if a certain function doesn't exist or something. Those I can see and fix.
Sometimes though, Zend won't fail, but it will also just send out an empty response. I will get a blank page. They layout doesn't show up, there's no code, there's no nothing to give me an idea of what's gone wrong. Last time, there was a require() that failed. I had to manually figure this out with no feedback.
Have any of you experienced this? Do you have any advice on how to get these errors to show? Any help would be appreciated!
The internal error handling of the framework's MVC components can only trap Exceptions, not PHP errors.
To assist in debugging during development, you can use the standard:
error_reporting(E_ALL|E_STRICT);
ini_set('display_errors', 'on');
Also, if you're using the new Autoloader included with 1.8, use:
Zend_Loader_Autoloader::getInstance()->suppressNotFoundWarnings(false);
To allow failed include/require statements to be issued.
For others coming across this question: I changed the following line in configs/application.ini
resources.frontController.params.displayExceptions = 0
To:
resources.frontController.params.displayExceptions = 1
This allowed me to see the full Exception, including stacktrace.
Set this in your config:
phpSettings.display_startup_errors = 1
phpSettings.display_errors = 1
resources.frontController.params.displayExceptions = 1
Edit the file public/index.php.
Change the APPLICATION_ENV to 'development'.
This will use the development settings in your application/configs/application.ini file. Those settings define whether to suppress errors.
It's too late to answer this question now. But hope it will help someone else...
Just place the following function in your Bootstrap.php file to enable exceptions..
protected function _initErrorDisplay(){
$frontController = Zend_Controller_Front::getInstance();
$frontController->throwExceptions(true);
}
Open urproject/application/config and open application.ini
Change the second line:
phpSettings.display_errors = 0
to
phpSettings.display_errors = 1
Now it will display errors.
Fast and dirty decision, if none of already mentioned methods worked (useful for old or ugly-configured version of ZF):
find ErrorController of your application.
put the call of debug_print_backtrace function at the top of init method (with die() optionally)
For anybody for whom the answers given here didn't work, one can always go to the apache logs to see a description of the problem. It would of course be more convenient if this showed on the page, but I find it to be an acceptable alternative.
/var/log/apache2/error.log
I have this file open with vim and type :e to refresh and G to go to the bottom of the page to see the most recent error when I get the blank page. It tells you the time the error occurred, the message and the line, so it's pretty helpful.
put these lines in application/configs/config.php
error_reporting(E_ALL|E_STRICT);
ini_set('display_errors', 'on');