1. Install XDebug on the Server.
  2. Configure XDebug a. Turn on Remote Debugging b. Set idekey
  3. Set up SSH tunneling (via tunnelier)
  4. Configure PHPStorm
    • Set IDE Key
    • Add Server
    • Add Remote Debug config
  5. Install boomarklets

= PHPSTorm + XDebug + Remote Debugging Setup =

Step 1: Install XDebug on the remote server. I use the standard pecl installer $ sudo pecl install xdebug

Step 2: Configure XDebug for remote debugging. a. Set xdebug.remote_enable=”1” b. Make sure xdebug.remote_host=”localhost” c. Set xdebug.idkey=”PHPSTORM”

Next, Reload PHP and look at the output of phpinfo(). You know you’re succesful when you see the following near the top: This program makes use of the Zend Scripting Language Engine: Zend Engine v2.3.0, Copyright (c) 1998-2012 Zend Technologies with Xdebug v2.2.1, Copyright (c) 2002-2012, by Derick Rethan

== Step 3: SSH Tunneling ==

Unless you don’t value your code, you’ll want to setup SSH tunneling.

Otherwise, any determined person with XDebug could conceivably view your source code by hooking up an XDebug instance to your server.

To do this on UNIX-based OS’s you’d run the following command: $ ssh -N -L 9000:localhost:9000 remotehost

To do this in Windows, I use a program called Tunnelier http://www.bitvise.com/tunnelier

== Step 4: Configure PHPStorm ==

This is the most complex step. It assumes you already have an existing project setup on a remote server.

  1. Set up PHPStorm’s debugger IDE Key.

Go to Settings -> PHP -> Debug. Make sure it has xdebug using port 9000.

Then above there, go to Settings -> PHP -> Servers. Click Add Fill in the details and then click “Use path mappings” Then you need to fill in the path of the project’s code on the remote server. Hit Apply, then OK. The final step of configuring PHPStorm is adding a Remote Debug configuration. Go to Run -> Edit Configurations Click the plus next to Details. Right click on PHP Remote Debug, and click Add New Configuration, select PHP Remote Debug again. I would name it “Remote debug” Ensure that the IDE Key says “PHPSTORM”. Hit OK. == Step 5: Install Debug Bookmarklets == The final step is to install the PHPStorm bookmarklets. Go to http://www.jetbrains.com/phpstorm/marklets/

Click “GENERATE” under Xdebug [6:22pm] tsmith: Drag at least “Start debugger” and “Start profiler” onto your bookmark toolbar

I find I never need the Stop ones.

== Testing ==

In your project, find two lines of code that should execute on each page load.

Click inbetween their line number and the edit window to set a breakpoint (looks like a red filled-in circle)

Go to your debugging toolbar up top that has the > play icons.

In the drop down box, select “Remote Debug”

Click the second Play icon.

Make sure the Phone icon is green, and not red.

If it is, click on it to turn on listening for debugging sessions.

Go back to your browser window, load up your remote app, and then click the “Start debugger” bookmarklet.

Refresh the page

If all went well, PHPStorm will popup

Hit the Play button on the left of the Debug section to go to your first breakpoint.

Using debugging gives you much insight into what the application is doing at any given moment / execution path.

This concludes the lesson.

For the next few minutes, I’ll be debuging a pernicious bug my code has. If you want, feel free to watch.

Ah aha!

By following the execution of the script from the beginning, I have found a hard to find bug:

protected function sendToFacebookToLogin()
 header("Location: " . $this->fbClient->getLoginUrl());

The user will be redirected to Facebook, but there is no exit; after the call.

Therefore, PHP keeps executing the script, calling validate();

Since validate can only be called once per login attempt, by the time they call it the second time (after logging into Facebook), their session is automatically invalidated.


By using proper debugging, I fixed two hard to find bugs in just under 10 minutes.

I hope this has been a good demonstration of the power of proper PHP debugging.

I find that people who use real debugging can find bugs in 10 minutes that would take other devs 3 hours to find. AND! If you ever wanted to know how an app worked, all you have to do is set the breakpoint to the first line and step through it. You’ll see exactly how it works, and it’s a lot easier, faster and fool-proof than trying to mentally work your way through it.