Chrome preview does not render the response properly, since yesterday when I upgraded the work machine from Win 8 to Win 10. Please see the screenshots:
As you can see, only one line of the object is rendered, when I tried it with a simple array, same thing happened, it only rendered the word "array" and "0";
I'm using Chrome 72.0.3626.96, WampServer64 with PHP 7.2.14 and those are my Xdebug settings in php.ini:
zend_extension="c:/wamp64/bin/php/php7.2.14/zend_ext/php_xdebug-2.6.1-7.2-vc15-x86_64.dll"
xdebug.default_enable=1
html_errors = On
xdebug.remote_host = 127.0.0.1
xdebug.remote_enable = 1
xdebug.remote_port = 9123
xdebug.profiler_enable = off
xdebug.profiler_enable_trigger = off
xdebug.profiler_output_name = cachegrind.out.%t.%p
xdebug.profiler_output_dir ="c:/wamp64/tmp"
xdebug.show_local_vars=0
xdebug.var_display_max_depth = 10
xdebug.var_display_max_children = 256
xdebug.var_display_max_data = 1024
It worked literally a day ago before I got Windows 10. Chrome bug or am I doing something wrong?
I found the issue and it is quite bizarre. It looks like the latest version of Chrome (72.0.3626.119 for me) has problems rendering the preview when the response text has a hash character (#) in the output. It will happily render everything until it encounters the hash character. This is most definitely a bug in Chrome.
I discovered this by first noticing that the preview stops at <font color='#888a85'>=></font>. I hardcoded this in the document and removed characters until I concluded that the hash character was causing the problem.
Here is a demo of the bug. When you run this snippet in the latest version of Chrome and with Inspector open, you should see the request pop up in the network tab. When you click on the request and go to the preview tab, the third paragraph is cut off since there is a # right before it.
<p>Para1</p>
<p>Para2</p>
#
<p>Para3</p>
I was unable to find an open bug report regarding this so I took the liberty of reporting it here: https://bugs.chromium.org/p/chromium/issues/detail?id=936284
It looks like this issue has already been reported (link) and fixed in the dev version of Chrome but hasn't been updated in the stable version yet.
In the meantime, if you really need to have var_dump work in Chrome, you can do this as a workaround (buffer the output and replace instances of #):
ob_start();
var_dump($var);
echo str_replace('#','',$ob_get_clean());
... or you can just turn off HTML errors:
ini_set('html_errors', false);
I've started working on a large PHP project that was built using Zend Framework 2. In trying to understand the code, I set up xdebug for both debugging within Eclipse and to output tracing of function calls. The problem is, I can't find certain methods in the trace file that I am almost 100% sure are being called. So I set a breakpoint within one of those methods in Eclipse, and sure enough, when I reload the page in the browser, execution halts at that breakpoint, so I know that method is being called. However, I can't find that method being called anywhere within the trace file that was just generated for that page load. Can anyone help explain this discrepancy?
Here is my xdebug (using v2.2.3) config from php.ini:
xdebug.remote_enable = 1
xdebug.remote_handler = "dbgp"
xdebug.remote_mode="req"
xdebug.remote_port=7800
xdebug.remote_host = "127.0.0.1"
xdebug.collect_params = 3
xdebug.trace_format = 0
xdebug.auto_trace = On
I am working on a project that uses CodeIgniter. I use Netbeans as my IDE and I have Xdebug installed. I am using XAMPP for local development.
What Works: Xdebug is working fine for normal PHP code.
Problem: However, I am facing problems debugging my CodeIgniter project. Debugger stops on a redirect()
Problem Details: Start debugging project in netbeans. Debugger starts and we see homepage. On homepage, there is a link that corresponds to a method in homepage controller. Debugger reaches the method in controller to which the link points to. In this method there is a redirect. At the point of redirect debugger STOPS.
Relevant Code Snippet(s):
URL That is clicked (This is part of the header menu)
Click Me
routes.php - Reroute for prettier url.
$route['somefunc'] = "foo/somefunc";
And in my Foo Controller (foo.php):
class Foo extends CI_Controller {
public function somefunc()
{
redirect('/bar/otherfunc'); // DEBUGGER REACHES TILL HERE THEN STOPS WORKING
}
}
As said above in the comment in function somefunc(), Xdebug stops working at the place where the redirect happens.
Additionally, the following information might be of some use:
config.php
$config['uri_protocol'] = 'AUTO'; // I have also tried PATH_INFO, QUERY_STRING, REQUEST_URI & ORIG_PATH_INFO.
$config['permitted_uri_chars'] = 'a-z 0-9~%.:_\-';
$config['enable_query_strings'] = TRUE; // Have tried FALSE too.
$config['index_page'] = ''; // Tried index.php too.
xdebug settings in php.ini
zend_extension ="path\to\xampp\php\ext\php_xdebug.dll"
xdebug.remote_enable=on
xdebug.remote_handler=dbgp
xdebug.remote_host=localhost
xdebug.remote_port=9000
NOTE - I have already tried playing around with different suggestions that I have seen here as well as through google but to no avail. Can somebody please point me in the right direction?
Found a solution. Perhaps this might help someone else who has been struggling with this. Apparantly to allow smooth debugging, you need to include the option:
xdebug.remote_autostart=1
in your php.ini. These settings work for me now:
xdebug.remote_enable=on
xdebug.remote_handler=dbgp
xdebug.remote_host=localhost
xdebug.remote_port=9000
xdebug.remote_autostart=1
The last line is the option I found on (Xdebug Official Documentation). The relevant part of the documentation is mentioned below:
xdebug.remote_autostart
Type: boolean, Default value: 0
Normally you need to use a specific HTTP GET/POST variable to start remote debugging (see Remote Debugging). When this setting is set to 1, Xdebug will always attempt to start a remote debugging session and try to connect to a client, even if the GET/POST/COOKIE variable was not present.
I found the same problem, and fixed it by upgrading my version of xdebug.
There appears to have been a bug in the version I was using (xdebug 2.1.3), but it all works fine on xdebug 2.2.3.
Use this tool for custom installation instructions for your environment.
http://xdebug.org/wizard.php
Be aware that netbeans doenst work with $_SERVER['PATH_INFO'] and url like http://127.0.0.1/site/test.php/v1/v2/parametertoputonphpathinfo/v3, there is a bug of Mon Sep 09, 2013 8:54 am on netbeans board telling about it without response until now 2014:
http://forums.netbeans.org/topic56645.html
It make impossible debug frameworks using that sinatra way to routing requests.
Rewriting my simple Sinatra router to have a $_GET mode to debug and a better hook code.
Updated question : PhpStorm | WebMatrix (IISExpress) | Xdebug.remote_port | — Which Port(s) to put where?
I'm running localhost web server on my Windows machine with WebMatrix and IISExpress. I've installed PHP and Xdebug in it and they both are working.
I have a local WordPress install.
I'm now trying to get PhpStorm to debug it using Xdebug.
When I run PhpStorm it launches the web app in the browser with relevant debugging parameters in the browser.
IDE KEY is matching
xdebug.remote_port is configured correctly. (Later I found that this is wrong, but not erroneous. It should be port 9000)
But it seems Xdebug never gets to communicate with PhpStorm. PhpStorm keeps listening, and the execution runs completely without stopping at any break-points.
These lines are crucial to make it work (in php.ini):
zend_extension=/usr/lib/php/extensions/no-debug-non-zts-20121212/xdebug.so
xdebug.remote_autostart = 1 # <-------- THIS
xdebug.remote_enable = 1 # <----------- AND THIS
Without these lines xdebug will never work on phpstorm ;)
Try changing the xdebug listen port in your php.ini and your IDE.
Running Mac Yosemite, for me the problem was that I installed with homebrew, following a guide that used php-fpm, which uses port 9000 by default (which conflicts with the xdebug default port)... Changing my xdebug.remote_port to 9001 and changing the xdebug port in phpstorm fixed the problem, though I suspect this issue could happen for anyone in any IDE. I googled for the better part of a day and didn't see this solution (since I believe it's so specific to install method).. but I hope it helps someone.
Took me about an hour until I noticed that this button wasn't activated ;)
"Run" -> "Start Listening for PHP Debug Connections"
First check for on what port xdebug is working on, you can find it in your php.ini under xdebug.remote_port=9123. As you can see in my case it is set to 9123.
Now open PhpStorm go to php debug, see screenshot:
under Xdebug you will find Debug port, make sure that its value is the same as in the php.ini file under xdebug.remote_port (9123 in my case).
Hope it helps
Could be a Firewall.
Day 572... Still haven't slept or eaten... But I finally found the culprit: Windows Defender!
Basically, I had a firewall blocking JetBrains IDE Support chrome extension from sending data to PhpStorm through the default 127.0.0.1:63342 address.
--- Edit
Day 864... Same issue happened again, this time on Linux... But I finally found the culprit: Ubuntu Firewall!
Seriously, this happened to me again a few months later, using Linux, and it was the firewall again. Disabling the firewall solved it sudo ufw disable - If you care for the firewall and want to keep it enabled, gotta dive in deep on creating some sort of whitelist for it.
For me it was changing the line:
xdebug.remote_host=localhost
to
xdebug.remote_host=myComputerIP
( Mac user: in terminal run ifconfig to find your ip )
If anyone else runs into this issue and is using Vagrant, this is what finally fixed it for me:
xdebug.remote_host=10.0.2.2
That needs to be the IP address of your local machine from inside the Vagrant box, and 10.0.2.2 is the default. If you ssh into your Vagrant box, it will show the IP where you logged in from if you want to confirm.
I know this isn't directly relevant to the specific setup the OP had, but this post shows up in a lot of xdebug / PhpStorm Google searches so hopefully this can help someone else.
PHPStorm has a build-in tool in Run > Web Server Debug Validation.
It helped me to solve my problem.
There was a syntax error in php.ini. There were extra "quotes" and ;colons;.
I also obtain this error message.
Also was troubles with the php.ini but more subtle.
Try to find and delete a row like this
extension=php_xdebug-...
Consider to look at my answer here for details "Xdebug - command is not available".
I was having this same problem while trying to test a Laravel project using XAMPP on Windows in PHPStorm. I have no idea what exactly I was doing wrong, but I did get it working eventually. I followed the step-by-step instructions on the PHPStorm site here.
One thing I think that was not configured right was that there was no interpreter set up in the PHP menu in Settings.
I was also trying a few too many combinations of settings in my php.ini. These were the settings that I have when things were working:
zend_extension = C:\xampp\php\ext\php_xdebug-2.3.2-5.6-vc11.dll //as recommended from the Xdebug site itself
xdebug.remote_enable=1=
xdebug.profiler_enable=1
xdebug.profiler_output_name = "cachegrind.out.%t-%s"
In my Run/Debug Configurations, I use a PHP Web Application setting, that just starts on the root of the site. (At first, I thought the appended ?XDEBUG_SESSION_START=<xxxxxxx> was a mistake, but it is not). Hopefully that might help if someone else is facing a similar issue.
Right click "Console" tab and uncheck "Focus on startup" (as seen in below image) should do the trick
I had an issue where one project would work and not another one. I tried many different configurations and I tried looking at the logs of xdebug, etc. This fix seems to have resolved my issue:
Try setting your actual ports of xdebug to 9123 instead 9000.
The new version (9) of PHPStorm changed its default xdebug connetion port to 9123 (the PHPSTORM config, not the actual xdebug config), probably for a good reason, since having the PHPSTORM config to the xdebug default 9000 didn't work but having them set to 9123 did work and resolved the issue.
I tried any of the suggested tricks and finally I called the script by 127.0.0.1/script.php instead of localhost/script.php and bingo!
Based on peteclark3 answer:
I think one of solutions if you have multiple php-fpm versions with xdebug, like php5.6-fpm, php7.1-fpm - make sure only one is running. I had both 5.6 and 7.1 running. Then tried to change on 7.1 to 9001 port. But if I change to 9001 port in PhpStorm, then 5.6 starts not working, because it listens on 9000. So each time you change php version, then probably you would need to change setting in phpStorm. So I think it is better to have only one of php-fpm running and all php-fpm versions can use same port.
This fix is specifically xdebug working but breakpoints not working with docker
Step 1 (check if xdebug actually works):
Go to settings in phpstorm and then debug, check the box 'break at first line...'
Try again, if it breaks at first script xdebug is working
Could be the breakpoints aren't working because it can't find the file.
Step 2 (check your paths mappings are set up correctly):
Go to servers (it's below debug)
Make sure you have a server set up and 'use path mappings' selected
Below that ensure that your php files are mapped to the correct path in the docker container. In my case files were mapped to /var/www/files but actually in the container it was /var/www/app/files.
I'm using XDebug to generate profile repport. The profile are generated, but I'm unable to create a complete call graph using kcachegraph.
The XDebug config is:
zend_extension=/usr/lib/php5/20090626+lfs/xdebug.so
xdebug.profiler_enable = 1
xdebug.profiler_output_dir = /var/www/xdebug/
xdebug.profiler_output_name = cachegrind.out.%t-%s
xdebug.profiler_enable_trigger=1
When I open the repport in kcachegrind, it seems to works, except that somt call seem in double, with one of the two having a location: (unknown).
Note that index.php only have 1 line of actual code, that is a require to the front controller. No autoloading at this stage of the execution, so I really can't figure out why I have 2 require::frontcontroller.php.
Here's a screenshot of 3 windows that might help you:
http://img46.imageshack.us/img46/2226/kcachegrind123.png
Any clue on what could be the problem ?
Thanks
Finally that's an XDebug problem with the profile.
It looks like Kcachegrind have changed their format, but XDebug have not been updated yet as per bug #639.
This is now fixed for 2.1.1 and HEAD.