Setting up local step debugging with PhpStorm

Setting up PHP debugging in an IDE with a local development environment has gotten so easy it can be done in a few automated steps. In this post I will demonstrate how to get step debugging functioning with PhpStorm and Zend Debugger when the server is set up on a local environment.

To begin with, I had the following:

  • Local installation of Zend Server 8.5.+ (basic LAMP stack, but with Zend Debugger included in the Zend Server installation). Alternatively I could have had a vanilla LAMP environment with Xdebug.
  • Ensure that Z-Ray is active in the Zend Server settings.
  • A local project set up on PhpStorm, without the server set up in the PhpStorm project configuration. (in this example I have a Zend Expressive Skeleton ready)
  • The local project set up as an Apache virtualhost.

With the project open in PhpStorm I click the icon to inform the IDE to start listening for debugging sessions. (Usually in the upper right corner, looks like a telephone receiver with a red indicator that it is not listening, and turns green when you click it)

Then a browser with the application rendered I click the debug icon in the Z-Ray toolbar at the foot of the window, and select the desired debugging action.

This will cause PhpStorm to prompt after it receives the debug connection from Zend Debugger. In most cases we can simply click Accept and let things happen normally.

That’s about it, we are debugging!

Behind the scenes, PhpStorm created a site and associated it with the project.

Of course we could have created the server ahead of time and not be prompted to Accept the incoming connection, but what is the fun in that?


This was a very simplistic local development environment setup. We didn’t have a firewall to contend with, and the server was set up locally rather than inside a virtual machine. I have other posts, linked below, to help with some of these alternative setups.

Happy Debugging!

Other posts on Debugging you may find helpful:

PHPStorm and debugging IP issue

Recently I was helping someone troubleshoot an issue using PhpStorm and Zend Debugger. In this case Zend Studio was able to debug an application using Zend Debugger while PhpStorm was failing unless an SSH tunnel was used. The error received was:

Host ‘’ is not allowed to open debug sessions – please configure zend_debugger.allow_hosts in the ini file.Failed to connect to host ‘’, reason: ‘Connection refused’.

The person experiencing this issue was attempting to debug a site in a VirtualBox virtual machine from the host machine. Both the host machine and the virtual machine were running Ubuntu 14.04. At first glance I thought adding to the allowed hosts would do it. But turns out it was more than that.

In this case we knew there was not a firewall blocking access, so it had to be networking.

To start things off I wanted to take a look at what PhpStorm was listening to, so I used the broadcast port 20080 to see this in a browser:

Screenshot from 2016-04-04 16:13:09

So it appears PhpStorm was attempting to use the IP addresses linked to the host systems ‘localhost’ and ‘hostname’, but not an IP address accessible via the network. This meant the server would never be able to send information back to the IDE without the use of an SSH tunnel, because it could not reach or of the host.

Unfortunately PhpStorm doesn’t provide a way to alter the listening IP addresses in the preferences, so we were left with either using an SSH tunnel to allow port forwarding of the listening port (10137) back to the host, or manually informing Zend Debugger where the IDE would be located.

Zend Debugger Tweak

By default Zend Debugger will automatically attempt to detect the IDE settings, as shown below:

Screenshot from 2016-04-04 16:23:04

However, this wasn’t working because PhpStorm was not reporting a usable IP address, so we needed to update the settings manually:

Screenshot from 2016-04-04 16:22:37

NOTE: Checking the box “Use browser’s IP Address” did not fix the issue. The IP address needed to be entered.

With this done, the server now knew where to reach the IDE for debugging sessions. One downside to this is if the host machines IP address changes, this setting will need to be updated.

This post is one in a series on debugging. For others click below:

Setting up step debugging in Zend Studio
Using an SSH tunnel to step debug through a firewall
Setting up local step debugging with PhpStorm

Edit: Please head out to the PhpStorm ticket system and +1 this fix to make this a thing of the past.

PHPUnit, Composer, PHPStorm, Oh my!

Installing PHPUnit within a project via Composer, then running tests through PHPStorm is not an intuitive process. However, with the right steps it’s actually pretty simple. Here is my story:

To launch the call for papers for the SunshinePHP Developer Conference it was a pleasure to use the OpenCFP project as a starting point rather than creating the entire thing from scratch.  While the project is still a “beta” with a few wrinkles to get ironed out, it’s still a pretty nice effort. (I have a pull requests pending, and another to submit.  Love open source!)

For my CFP I wanted a few more fields of information than the “out of the box” setup, so I quickly added them to the app.  However, doing this meant the included unit tests would fail.  But wait, I hadn’t run the unit tests yet!  I realized immediately how spoiled I had become with today’s modern frameworks with a testing method built in.  This little project did not have that luxury, so I would need to run the tests the old fashioned way, or let an IDE do it for me.  I decided to configure PHPStorm do it. (I’ll do the same for Zend Studio in another post later.)

The way OpenCFP was set up, using Composer, meant that PHPUnit was already placed in the /vendor directory as a requirement in the composer.json.  So rather than taking the lazy way out and using the PHPUnit already installed globally on my system, I wanted to use the latest PHPUnit within the project.  This requires 2 setup steps in PHPStorm.

Step 1

To start I needed to inform the IDE where to find the Composer autoload file and leverage the awesome PSR-0 goodness to autoload PHPUnit in the /vendor directory.  To do this I open the Settings via the icon on the toolbar, or by using the File->Settings menu item, or hitting the Ctrl+Alt+S keyboard shortcut.  Then in the Project Settings (top section) I expanded PHP to get the PHPUnit dialog.

PHPUnit setup in PHPStorm

Step 2

Now I had to add a Run/Debug Configuration for the project.  I did this by clicking on the toolbar dropdown and selecting Edit Configurations.

Edit Configuration

Once the dialog opened I clicked the “+” to add a run configuration, and select the PHPUnit type.

Choose configuration type

Now it was just a matter of adding the directory where the tests reside. (Name the configuration to your taste.)

Location of tests

All done!!!  Now I was able to run the tests simply by selecting the new run configuration defined in the dropdown, and clicking the Run button in the toolbar.

Good luck, and happy testing!

Add items to Ubuntu 12.04 Unity Launcher (quicklaunch)

The recent upgrade to Ubuntu 12.04 Precise Pangolin left me somewhat hanging when it comes to creating launchers on the desktop, and also in the Unity Launcher (also called quicklaunch in some places) for Zend Studio and PHPStorm. In Gnome prior to Unity in Ubuntu it was easy to right click the desktop and select Create Launcher to create icons on the desktop to launch applications or scripts, but in 12.04 that options is gone. So here is how I solved some of the issues.

I will cover adding Eclipse to the launcher, adding Zend Studio to the launcher, and PHPStorm to the launcher.

Method 1 (easiest)

For Netbeans and Eclipse based editors like Zend Studio or Aptana it is not too bad. I created a {name}.desktop files for each one and put it in the /home/{username}/.local/share/applications/ directory. Here is how I created a zendstudio.desktop file:

Note: If you want this option to be available for all users you can alternatively create the file in the /usr/share/applications/ directory, but that requires superuser permissions.

[Desktop Entry]
Name=Zend Studio
Comment=PHP IDE for PHP development
Name[en_US]=Zend Studio

After creating the file above I rebooted. Following the reboot I was able to click the Unity Dash Home button, type “Zend” in the search field, then drag and drop the Zend Studio icon to the launcher where I wanted it to be. Now the application stays in the Unity Launcher.

For PHPStorm see method 3 below.

Method 2

Another method I found was to install the ‘gnome-panel’ package. (Actually it was already installed on my system for some reason.)

sudo apt-get install --no-install-recommends gnome-panel

With the gnome-panel I was now able to create a launcher on the desktop using the command below.

gnome-desktop-item-edit ~/Desktop/ --create-new

In the create launcher dialog I filled it out as follows:
Type: Application
Name: PhpStorm
Command: /bin/bash /home/username/PhpStorm/PhpStorm-117.257/bin/

NOTE: You could use /bin/sh or whatever shell you use. I use bash so that is why I put /bin/bash.

To create a shortcut in the Unity Launcher I double clicked the new desktop launcher I created above. (NOTE: If you start PHPStorm by executing the you do not get any options at all when right clicking the icon in the Unity Launcher.) Then when PHPStorm was running I was then able to right click on the icon in the Unity Launcher and selected “Lock to Launcher”. Voila! Now I have phpstorm on the Unity Launcher.

Method 3

This option is built right into PHPStorm. The wonderful people at JetBrains created a handy item in Tools to automatically create a menu item for you. Simply click on Tools->Create Desktop entry…and now you can Lock to Launcher the next time you run it. Start the JetBrains PhpStorm IDE from the Unity Dash you can then right click on the icon that shows up in the Unity Launcher and select “Lock to Launcher”. The icon now stays there, even after a reboot/logout.


Method 4

See comment to this post below by Shinybird on using Ubuntu Tweak. (Not sure if it works, but it sounds good.)