Simplify xdebug configuration, fixes #736, fixes #735

[rfay]

The Problem/Issue/Bug:

Docker now supports "host.docker.internal" IP address/hostname, so we don't have to do magic configuration of the host IP address as we used to. See OP #736 .

How this PR Solves The Problem:

• New nginx-php-fpm-image drud/nginx-php-fpm-local:20180412_xdebug (Must be released, tagged, and changed here before pull) https://github.com/drud/docker.nginx-php-fpm-local/pull/67
• Simplify configuration of xdebug on/off (enable_xdebug: true in config.yaml)
• Update docs to reflect xdebug_enabled
• Update xdebug usage docs with new screenshots
• Add vscode instructions.
• Try xdebug.remote_connect_back (doesn't work)
• Update the Stack Overflow article

Manual Testing Instructions:

• Use the updated xdebug instructions to set it all up with your favorite IDE.
• Test with xdebug_enabled: true and xdebug_enabled: false.

Automated Testing Overview:

• Added a test to ensure xdebug_enabled: functions correctly.

Related Issue Link(s):

OP #736
#735 Use xdebug with vscode on windows

Release/Deployment notes:

[rfay]

I think this is ready for review, along with the related drud/docker.nginx-php-fpm-local#67

[rickmanelius]

#785

Preparation

ddev

• git checkout 28ee4ec3
• make darwin
• ddev version
  • Confirmed v0.17.0-9-g28ee4ec3

drupal 7.58

• Remove settings.php, config.yml, etc.
• Ran ddev config with defaults
• ddev start and base install of Drupal 7

I noted new containers for both the ddev binary build and ddev start.

Testing

• Default I observed that config.yml had "xdebug_enabled: false"
  • Logged into the container and ran php -i | grep xdebug to confirm it's not there.
• Turning on
  • Opened config.yml and swapped false to true.
  • Logged into the container and ran php -i | grep xdebug to confirm it is there.
• Testing
  • Enabled the chrome extension and updated to the latest version.
  • Enabled the Atom php-debug package and updated to the latest version.
  • Modified the serverport from the screenshot to 9000
  • Set a breakpoint within index.php
  • I had to modify Atom's config because I realized my Drupal 7 site didn't have docroot. This removed error messages.
• Disabling
  • Confirmed that setting to false and re-running ddev start removed xdebug

At this point, I think I'm stuck on a user error issue because I can see that Chrome and Atom are communicating when I open up the console and see the sessions are being initiated when I have it enabled and not initiated when I disable it. However, it's not respecting the breakpoint, which again is probably user error or an issue with Atom. So I believe this functionality is working but will need to work through that last piece to successfully demonstrate xdebug. if @cweagans approves, then likely its just user error and I'll approve.

[rfay]

Definitely see that I failed to update the atom screenshot, although the config.cson snippet did get updated, https://github.com/rfay/ddev/blob/3ed95b8ed8822e6837551d8a4f025f013dc50729/docs/users/snippets/atom_config_cson_snippet.txt -

I think both should omit the docroot, at least on other IDEs it doesn't matter (the mapping just needs to be consistent, and might as well be repo root)

I will step through the atom config.

[tannerjfco]

I took this for a spin testing against vscode, and hit some snags getting it to work. Re-testing via screenshare w/ Randy, we determined that we needed to set ?XDEBUG_SESSION_START on the test URL in order for vscode to pick up the breakpoint.

Looking at the docs for the vscode php-debug plugin, it looks like they recommend setting the following for the simplest path to working state:

[XDebug]
xdebug.remote_enable = 1
xdebug.remote_autostart = 1

I see we have remote_enable set, but I didn't see remote_autostart set. I wonder if this is the piece we're missing for this to work seemlessly in vscode and possibly others. While I didn't test phpstorm myself, I did observe it to be working as expected when randy demoed via screenshare.

[rfay]

• I added the remote_autostart, which is lovely, and also will help both vscode and atom to work without a browser extension or anything.
• Updated instructions for vscode and atom, with screenshots. See docs that go with this PR
• Removed Netbeans instructions. I couldn't even get the latest version to open a project, not to mention debug. I haven't heard of anybody using Netbeans in recent years.

When retesting this, Please make sure to use the 20180420_xdebug web image (just delete webimage line from config.yaml)

[rickmanelius]

Neat that this is now possible without the browser extension. I can confirm that I can disable the extension and still see the session initiation when xdebug is set to true and I've configured Atom to toggle on debugging. I'm still not able to get a breakpoint to succeed and I've done this before, so I'm not exactly sure what's tripping me up. I viewed the instructions here https://atom.io/packages/php-debug to see if it's user error. I'd like to request a quick video/screencast to determine if I'm simply doing something incorrectly or to determine if my install/configuration of Atom is borked.

[rfay]

Yeah, we should work through it together. Do make sure your path mappings are correct.

[tannerjfco]

I retested this against VS Code and Atom, and both are now working as expected.

I did have a slight hiccup testing Atom initially, but this was cleared up once i stopped/started debug using the atom debug console. I'm not sure if users will need to do this, but it might be helpful to include in the atom steps to open the debug console:

"Open the debug view by pressing ctrl+alt+d, selecting 'Toggle Debugging' from the Command Palette or php-debug menu."

Thanks for the work on this! This should make for pretty simple use of xdebug with ddev.

[rickmanelius]

Worked through this with @rfay. This may have been user error on my part where I put the breakpoints. I'm not a power xdebug user with Atom, so it was either the placement of the breakpoint OR the editor specific behavior. Either way, +1 ready to merge.