Xdebug not triggering

FYI this is the first time I'm ever using Xdebug so I might be missing something really obvious! I keep seeing some talk about "path mapping".

In run/debug configurations, I go to configure the server and there I see a checkbox for "use path mappings". It's de-selected right now, but even if I select it, nothing changes. The local directory path corresponds to the / path on my remote server.

Log file attached

Hi Areeb,

Have a look at this blog post: http://blogs.jetbrains.com/webide/2011/02/zero-configuration-debugging-with-xdebug-and-phpstorm-2-0/

Hello Areeb,

Your Xdebug configuration looks OK. PhpStorm will force break at the first line if there are any problems with path mappings. The current problem is that xdebug doesn't connect to PhpStorm.
Please describe your server/project configuration. Does the server and IDE work on the same machine?

Thank you for feedback!

Hey,

No it's a remote linux server.

I've set up the "remote debugging" configuration in PHPStorm (I think properly).

Areeb,

No it's a remote linux server.

So you have a mistake in your xdebug configuration.
Please pay attention to xdebug.remote_host settings in you php.ini.
from http://xdebug.org/docs/remote:

xdebug.remote_host
Type: string, Default value: localhost
Selects the host where the debug client is running, you can either use a host name or an IP address. This setting is ignored if xdebug.remote_connect_back is enabled.

Your current value is 'localhost' but should be an ip adress of machine on which PhpStorm is running.

Please try to change you xdebug configuration and report here about results.

If I change that line to my IP address all the pages on my site take a really long time to load. Same problem if I change xdebug.remote_connect_back to 1

And even with the slow load times, the breakpoint isn't being hit.

Areeb,

If I change that line to my IP address all the pages on my site take a really long time to load. Same problem if I change xdebug.remote_connect_back to 1

Please set xdebug.remote_host to your client ip, select "Use path mappings" checkbox(it is even better to remove any servers from PHP -> Servers and use zero-configuration), enable listen debug button and try to debug again.

If debugging will not work again, attach your idea.log here(pay attention that you should use "#com.jetbrains.php.debug" as cetegory_name).

FYI, XDebug does make pages load very slow....at least it has always done that for me.

And as was stated, the zero-config works great. I just set these settings in my php.ini:

zend_extension="c:/php/ext/php_xdebug-2.1.0-5.3-vc9-nts.dll"
xdebug.remote_enable=1
xdebug.remote_host=127.0.0.1
xdebug.remote_port=9100
xdebug.remote_handler=dbgp
xdebug.remote_autostart=1

And then click the Listen button!

Keith,

FYI, XDebug does make pages load very slow....at least it has always done that for me.

It should work a bit faster when 'Listen' button is enabled.

Thanks for sharing!

I'm ok with the pages loading slow for me, but they also load slow for all my site visitors. Can I avoid that somehow?

Yes. Turn it off. Seriously, I wrote a script that turns it on and off...wait...are you running XDebug on your production server?

Areeb,

Use xdebug.remote_host setting instead of xdebug.remote_connect_back setting.
Using of xdebug.remote_connect_back is unsafe on production server.

from http://xdebug.org/docs/remote:

xdebug.remote_connect_back

Type: boolean, Default value: 0, Introduced in Xdebug 2.1

If enabled, the xdebug.remote_host setting is ignored and Xdebug will try to connect to the client that made the HTTP request. It checks the $_SERVER['REMOTE_ADDR'] variable to find out which IP address to use. Please note that there is no filter available, and anybody who can connect to the webserver will then be able to start a debugging session, even if their address does not match xdebug.remote_host.

So any user can debug your webserver.

Also all speed of connection related problems caused by usage of xdebug.remote_connect_back setting.

I used the remote_host option with my IP and it was still loading incredibly slow on computers that didn't have that IP.

I also used the remote_connect_back and that was no better.

Areeb,

Does debugging with Xdebug start work for you? I mean original topic of the thread.

I used the remote_host option with my IP and it was still loading incredibly slow on computers that didn't have that IP.

I also used the remote_connect_back and that was no better.

No it still didn't work even with the slow load times. And I have tried disabling remote_connect_back and only having the "remote_host" enabled but it's still horribly slow. But I mean I don't care if it works if the load times are that slow, it's a very busy web server and I can't afford any speed decreases. I guess it's back to echo statements for me :(

Areeb,

Do you have development server?

Yea I guess I could do it on a separate development server, but this one has all the MySQL database entries I wanted to test with. Ok will figure out a solution. Thanks for the help though, will get in touch with you guys if I can't get it working on the development server.

XDebug, in my experience slows down pages loads terribly, once it's loaded, no matter what you do (I'd love for someone to show me a way to make it not the case.)

Like I said, I wrote a script that turns it on and off, but we don't debug on our production server.

Just as a suggestion, what we do is run IIS locally and attach to the database (we have a dev schema for major changes and testing), but that way we are not developing on the live server, but still have access to the real data for testing (you could also create a MySQL slave locally and use that for testing, assuming your MySQL server is on-site...well, even if it isn't, but that's tricky.)

Anyway, that allows us to turn XDebug on and off as we need it.

I had similar problem, and it worked fine after renaming xdebug .dll file to php_xdebug.dll and changing the zend_extension entry in php.ini from 

zend_extension=c:\xampp\php\ext\php_xdebug-2.7.0-7.3-vc15-x86_64.dll

zend_extension=xdebug

However, it doesn't make any sense to me so far. Just adding here thinking that it could help someone.