Vvv: Configure xDebug with atom

[maru3l]

Hi, I'm trying to run xDebug with the plugin https://atom.io/packages/php-debug for atom but it's not working at all. Is there something I'm missing?

This is my config.cson :

  "php-debug":
    ServerPort: 9000
    PathMaps: [{
      remote: "/srv/www/wordpress-default/"
      local: "/Users/maruel/Google Drive/htdocs/vvv/www/wordpress-default/"
    }]

[jeremyfelt]

Hi @ram89, have you enabled XDebug inside the VM yet? Either vagrant ssh -c "xdebug_on" or vagrant ssh then xdebug_on would do the trick.

Also, the remote host of 192.168.50.1 may need to be specified.

[maru3l]

Yes @jeremyfelt, it is activated and I can see the pretty var_dump.

I have tried with MacGDBp and I'm getting a error

Could not open socket

[brazabr]

Hi everyone,
I had the same issue, but I manage to solve. I think it may be interest to document my steps here because everytime I search this topic I end up in this page.

The following steps allow one to debug php in Atom:

1. Run vagrant halt to shutdown the vagrant box.
2. Edit your Vagrantfile, adding the following line: config.vm.network "forwarded_port", guest: 9000, host: 9999. The port number 9999 may be changed to any free port you want, just make sure there is no other process using it.
3. Run vagrant up to start the vagrant box.
4. Check if there is a listening process on the port you selected: netstat -tulpn | grep ":9999".
5. Now open Atom, make sure you have php-debug package installed and edit your config.cson:
   "php-debug":
   ServerPort: 9999
   PathMaps: [{
   remote: "/srv/www/wordpress-default/"
   local: "/Users/maruel/Google Drive/htdocs/vvv/www/wordpress-default/"
   }]
6. Toggle Debugging in Atom so you can see the debug window.
7. Add some breakpoint in your code.
8. Install some extension on your browser that allows you to turn debug on or off.
   
   
   
   • The easiest Xdebug for Mozilla Firefox
   
   
   • Xdebug Helper for Google Chrome
   
   
9. You will see a bug icon in your browser, click to enable Xdebug session.
10. Visit your page.

At this point the browser will hang waiting. You should be able to see the code execution paused in your breakpoint inside Atom and Debugging window will display all the context.

Instead of using a browser extension to control the debug session start and stop, you can set your php.ini to always start a xdebug session. You can find more information about this in the php-debug page.

[JasonTheAdams]

@brazabr Thanks for the walkthrough! I've done just about every identical to what you did above, but I still can't quite get it working. The only difference is that in your PathMaps object you're specifying the path of the wordpress-default. I assume this is a placeholder? Do you have to put the path for every site in www that you want to use xdebug for?

[kikianion]

The problem was pathmaps for Remote Debugging not parsed correctly by atom phpdebug plugin

i have tested some configs on pathmaps

1. "php-debug":{
   ServerPort: 9000
   PathMaps: [
   "/var/www/html/ipku/;x:/html/ipku/"
   ]
   }
2. "php-debug":{
   ServerPort: 9000
   PathMaps: [
   "file:///var/www/html/ipku/;file://x:/html/ipku/"
   ]
   }
3. and variants of config.cson point 2

i am using vm for my ubuntu server, this is my xdebug.ini for php/apache
zend_extension=xdebug.so
xdebug.remote_enable=1
xdebug.remote_handler=dbgp
xdebug.remote_mode=req
xdebug.remote_host=192.168.20.1
xdebug.remote_port=9000
xdebug.remote_log="/var/log/xdebug/xdebug.log" <-- for logging xdebug activity
xdebug.remote_connect_back=1

and if you check /var/log/xdebug/xdebug.log, always the result of the protocol between xdebug<->atom phpdebug plugin was

......

<- breakpoint_set -i 6 -t "line" -f "file://X:%5Chtml%5Cipku%5Cindex.php" -n 7
-> < response xmlns="urn:debugger_protocol_v1" xmlns:xdebug="http://xdebug.org/dbgp/xdebug" command="breakpoint_set" transaction_id="6" id="28610034" >< /response >
.........

file://X:%5Chtml%5Cipku%5Cindex.php supposed to be replaced by pathmaps, but it never replaced

[begroff]

@brazabr Your solution worked perfectly for me! I was using Atom(1.8) on a Mac (El Capitan, OSX 10.11) so the command from terminal to check to see if forwarded port 9999 is listening after rebooting up the vagrant box is:

lsof -i :9999

In the Xdebug config if you set the remote autostart to true, each time you bring up Debugging and then run the script (or go to the webpage configured in your pathmaps) it will stop at the breakpoint:

xdebug.remote_autostart=true

[JasonTheAdams]

@groffTECH Glad you got it to work! Unfortunately I've never been able to. I set xdebug.remotae_autostart=1 hoping that was it, but no joy.

Would anyone who has succeeded be willing to throw together a quick and dirty screencast of how you have things configured from start to finish? That would be awesome.

[begroff]

I found this issue thread through Google. I don't do WordPress development or use VVV (yet!) but I do have a vagrant box that I setup manually with CentOS 5 (to mimic my reseller server) and I am using Drupal with Atom. I think for my first ever screencast, I'll attempt to show how I configured it and got php debugging to work in Atom.

[redgeoff]

The info above was helpful, but none of it quite did the trick so I've posted some details to Debug PHP in Atom While Using Vagrant. I hope this saves someone time!

[JasonTheAdams]

@redgeoff Thank you! That finally did it! I added xdebug.remote_connect_back=0, set xdebug.remote_autostart to 1. Finally, I had the port in Atom set to 9999, per previous instructions and changed it to 9000. I think I was confusing that the final port it connects to isn't the forwarded port but the port xdebug is watching for.

[JJJ]

/etc/php/7.0/fpm/conf.d/20-xdebug.ini

...was overriding my changes in...

/srv/config/php-config/xdebug.ini

...which hung me up for a while today (while trying to get Atom to work with XDebug.)

Interestingly, I didn't need to do the additional port 9999 stuff to make it work.

For wordpress-develop, my working config.cson section looks like:

  "php-debug":
    AutoExpandLocals: true
    GutterPosition: "Left"
    PathMaps: [
      "/srv/www/wordpress-develop/src;/Users/my/path/to/VVV/www/wordpress-develop/src"
    ]

I did change xdebug.idekey from VVVDEBUG to xdebug.atom though.

[bfintal]

This worked fine for me:

1. Settings of php-debug in Atom for Path Maps to:

     /srv/www/wordpress-default;/Users/path/to/wordpress-vvv/www/wordpress-default

1. No modifications to the VagrantFile:
2. /srv/config/php5-fpm-config/xdebug.ini:

   xdebug.remote_autostart = 1
   xdebug.remote_connect_back = 0
   xdebug.remote_enable = 1

Same as @JJJ, I didn't need to do the port 9999.

[cmwang-cottageclothing]

I am on Windows 7 64 and have the same issue too.
Almost 7 hours to solve this problem.
Hope this can help

Varying Vagrant Vagrants 2.0.0

config.cson

  "php-debug":
    PathMaps: [
      "remotepath;localpath"
      "/srv/www/wordpress-default/public_html;C:\\vagrant-dev\\www\\wordpress-default\\public_html"
    ]
    ServerPort: **9001**
    currentPanelHeight: "341px"
    currentPanelMode: "bottom"

Edit /etc/php/7.0/mods-available/xdebug.ini on VM

xdebug.idekey = "xdebug-atom"
xdebug.remote_host = "10.0.2.2"
xdebug.remote_port = **9001** <-- this maybe the most important part

In Firefox set the idekey "xdebug-atom"

I find the solution because I read the xdebug-remote.log
There are some lines added when I use php-debug

Log opened at 2017-09-05 09:09:01
I: Connecting to configured address/port: 192.168.50.1:9000.
E: Time-out connecting to client. :-(
Log closed at 2017-09-05 09:09:01

I google this, and got this solution.

[tomjn]

Marking this as closed as it hasn't been touched in a very long time

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.