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.
Related
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.
I am trying to analyze what's what in my Yii application by using XDebug paired with PHPStorm. In the "Debug" tool window I can see function calls and the variable list associated with a function call.
There are setting in php.ini that allow xdebug to also collect parameters passed to functions, function return values and also variables that were modified by a particular function.
Is there a way to see all of that in PHPStorm?
The "collect_params" and "collect_returns" extra php.ini settings are for function and stack traces. Xdebug doesn't provide information on which variables where modified by which function. There is information on how to turn on tracing at http://xdebug.org/docs/execution_trace
In PHP Storm, you can easily see the arguments passed to a function by setting a breakpoint on the first line of the function, and inspecting the incoming values. You can also monitor the return value, by setting up a breakpoint at the return statements of the functions that you are interested in. PHP Storm does not allow you to set a break point on a function's entry point and/or exit point - although Xdebug's DBGp protocol does support that: http://xdebug.org/docs-dbgp.php#breakpoints You could file a feature request at https://youtrack.jetbrains.com/dashboard if you want.
I'm trying to get xdebug working on my Mac. I'm using OS 10.6 with the built-in versions of Apache (2.2.1) and PHP (5.3.8). I followed the "tailored installation instructions" on the xdebug website, which basically consisted of these steps:
Build xdebug (version 2.1.3) from source
Move xdebug.so to /usr/lib/php/extensions/no-debug-non-zts-20090626
Add to php.ini:
zend_extension = /usr/lib/php/extensions/no-debug-non-zts-20090626/xdebug.so
Restart the webserver.
From what I understand, that should be it. I know most people use xdebug with an IDE like PHPEclipse, but it doesn't sound like that's necessary just to get debugging output on the page. And a lot of old instructions involve installing MAMP, but it looks like that's no longer necessary.
Signs xdebug is working: When I run php -m and phpinfo() I get the expected information on xdebug. In scripts I'm able to call functions like xdebug_is_enabled() (returns 1) and xdebug_get_function_stack() (returns the stack).
Ways xdebug is not working: The main reason I installed xdebug was to get a stack trace when there's an error, and that's not happening. According to this documentation page, I should get a stack trace as long as display_errors is set to On in php.ini, (which it is). I've tried code that should evoke a warning (e.g., echo(hello)) as well as code that produces a fatal error (e.g., $x->awesomefunction() when $x isn't an object). Neither one produces any xdebug output, and the fatal error just causes the page to die silently. The test code given in the documentation I linked to also produces nothing.
UPDATE: It turns out that if I run a script with a fatal error from the terminal, I do get a stack trace from xdebug. However, it's still not showing up when I run the script from a browser
Also, regular error reporting is now broken: Previously, I'd get error output by including the commands:
ini_set("display_errors","1");
ERROR_REPORTING(E_ALL);
Now, putting those lines in my script doesn't produce any error reporting either. (in the browser. It does cause errors to be shown when I run the script from the terminal.)
So, what's wrong here? Did I leave something out of the xcode installation? Do I have a setting hanging around somewhere else on my system, suppressing errors? I've tried everything I can think of, but I'd be happy to test any ideas you have.
If it is working on console and not on browser, it's probably a xdebug configuration issue.
I'm not a Mac user, but on Ubuntu there are 2 different php.ini files, one for console and one for apache. If that's the case for Mac also, you can check if xdebug is enabled and properly set up in both php.ini files.
Also you can check the xdebug settings mentioned in the guide.
After several more hours of thrashing, I discovered that one of my test files actually was including another file that set display_errors to 0. The other test file was straight off of the xdebug site, but I think that at the time I was using it I'd introduced some other config error that prevented it from working properly. I'm truly embarrassed! Let this be today's object lesson in the importance of systematic, repeatable tests during debugging. On the bright side, xdebug is now working like a peach.
To summarize, the series of steps that worked was:
Build xdebug (version 2.1.3) from source
Move xdebug.so to /usr/lib/php/extensions/no-debug-non-zts-20090626
Add to php.ini: zend_extension = /usr/lib/php/extensions/no-debug-non-zts-20090626/xdebug.so
Add to php.ini: display_errors = On
Restart the webserver.
The administrator has installed Xdebug 2.1.1 in our shared PHP 5.3.0 server in order to use its debugger. Now, I can hardly read the stack traces of uncatched exceptions because they are formatted by Xdebug with annoying colours that interact badly with the site's CSS:
Since PHP runs as Apache module, I've tried to disable this feature in an .htaccess file but I can't make it go:
php_flag xdebug.default_enable Off
php_flag xdebug.overload_var_dump Off
php_flag xdebug.show_exception_trace Off
php_value xdebug.trace_format 1
phpinfo() shows my changes in the Local Value column but I can still see those horrible orange tables. What's the directive I need to change?
Check for xdebug_disable()Docs:
Disables stack traces
Disable showing stack traces on error conditions.
See as well xdebug.default_enableDocs.
You need to make sure you have html_errors=0 in PHP as well.
Also, orange isn't horrible ;-)
Add following code in the initialization Script:
if (function_exists('xdebug_disable')) {
xdebug_disable();
}
I am implementing a template system using the wrapper class in this example: http://www.php.net/manual/en/stream.streamwrapper.example-1.php
I use this code to get the wrapper output:
ob_start();
include("template://" . $template_name);
$template .= ob_get_contents();
ob_end_clean();
However, in some servers this code is not working, all I get is a blank page. I am not sure if it is a php directive issue, I changed allow_url_include to both 0 and 1, but it did not have any effects on the code.
So what is the problem with the code.
EDIT: error logging is on, and it is not showing any errors related to this issue
in some servers this code is not working
In all likelihood, this is because php streams are not available or configured properly on these servers. It die with an error, and you don't see the error because of the output buffer
My host updated to Litespeed and a more stringent Suhosin setup. At first I thought it was Litespeed, but it was indeed Suhosin (I twigged from this thread, thanks!).
It's just a php.ini setting you need to change, you have to add your stream name to the include whitelist:
suhosin.executor.include.whitelist = template://
And then it'll work fine again. Here's a couple more links saying the same:
A bigger example: http://cweiske.de/tagebuch/suhosin-phar.htm
-Others struggling with the same: http://forum.bytesforall.com/showthread.php?t=12262&page=2
Suhosin doco (doesn't really explain with huge detail) search for: suhosin.executor.include.whitelist
I had the same issue and found that PHP Suhosin was causing this 'white screen of death'.
That could explain why this works on some servers and not on others.
There could be a Suhosin config option for dealing with that, check out the website: http://www.hardened-php.net/suhosin/
tl;dr I ended up removing Suhosin which resolved the issue.