http://phpweby.com/tutorials/php/35

Since this took me quite a while to figure out, I thought I’d include the steps here for others.

Installing Xdebug

Over SSH, I ran the following:

$ pecl install xdebug

Configuring Xdebug in php.ini

;;;;;;;;;;;;;;;;;;;
; Module Settings ;
;;;;;;;;;;;;;;;;;;;
zend_extension=/usr/lib/php/modules/xdebug.so
 
[xdebug]
xdebug.remote_enable=1
xdebug.remote_port=9000
xdebug.idekey=PHPSTORM-XDEBUG
xdebug.remote_connect_back=1
 
[Date]

Note the use of zend_extension; as of PHP 5.3, this is the only one that works (extension=…) will appear to function, but never connect!

Also, I used xdebug.remote_connect_back=1 – this allows connections from anywhere. But since I’ve configured my server to load a separate php.ini for each site (sorry, this is outside the scope of this discussion), and the entire site is under development and protected by .htaccess, I didn’t have to worry about other people debugging remotely.

An alternative to using remote_connect_back is to specify the remote_host to your local ip address:

xdebug.remote_host=0.0.0.0 ;your ip address
;xdebug.remote_connect_back=0

 Alternative: Loading via .htaccess instead of php.ini

Alternately, I could have dropped a .htaccess file into my root directory for the virtualhost, if the php.ini for each site were too much trouble:

php_value  zend_extension=/usr/lib/php/modules/xdebug.so
php_flag   xdebug.remote_enable on
php_value  xdebug.remote_port 9000
php_value  xdebug.idekey PHPSTORM-XDEBUG
php_flag   xdebug.remote_connect_back on

Configuring PhpStorm

I followed these instructions to the letter. Make sure you set up the “PHP Remote Debug” and not the “PHP Server” option if you’re using my list here as a guide (both work, I just chose the remote)

Remember to get those IDEKEY values to match up in the editor and on the server!

Configure Firewalls

On CentOS, I use apf, so I configured my firewall by adding port 9000 into the following settings: IG_TCP_PORTS, EG_TCP_PORTS

Then I restarted apf:

$ /etc/init.d/apf restart

At home, I opened a connection in my firewall by adding a redirect for port 9000 to my personal PC.

Starting it Up

Remember to reload Apache’s config!

$ /etc/init.d/httpd reload

Make sure PhpStorm is set to break on first line, or you won’t know if it worked! (you need the debugger to get involved):

Start the PhpStorm Remote Debug:

Make sure to click the “listen for connections” icon!

A quick note on semantics here: It is not technically necessary to have the debug server running and “listen for connections” clicked. Listen for connections will, in fact, start the debugger when an incoming connection is received. However, for initial testing, having the debugger actually ON was very helpful in being sure PhpStorm wasn’t failing to start incoming connections.

Connect to your IP address from the web server to make sure it can talk to your IDE:

$ telnet 0.0.0.0 9000

Add XDEBUG_SESSION_START=PHPSTORM-XDEBUG in the URL of the site to initiate a connection:

Witness debugging in all its glory!

Browser Plugins

There are browser plugins for Chrome and Firefox that make remote connections a breeze; you no longer have to type the parms into the URL. I’ve used both of these with success and highly recommend this simplification.

After about an hour of searching, I discovered that port 80 was in use by Skype. No kidding. There is an advanced setting in skype to “Use port 80 and 443 as alternate incoming connections.” If this is checked (which it is by default) then a service is started on port 80 that blocks Apache. Ungh for bad ideas and even worse defaults.

The “Rewrite” Approach

Here is an approach using a rewrite rule, that preserves files and query parms from the original entry. This takes widgets.mysite.com/files/?id=20 and redirects it to www.mysite.com/widgets/files/?id=20:

RewriteCond %{HTTP_HOST} ^(www\.)?subdomain\.mainsite\.com
RewriteRule (.*) http://www.mainsite.com/subdirectory$1 [L,R=permanent]

%{HTTP_HOST} is an apache variable that refers to the current domain entered in browser.

(www\.) makes it possible to redirect widgets.mysite.com or www.widgets.mysite.com.

/subdirectory is where you specify which directory the redirect drops them in.

(/.+)? bit is what adds on any details after the url.

[L, R=permanent] is based on Apache’s RewriteCond options, and tells apache we actually want to change the url in the browser, instead of just showing the correct page at this url.

The “Redirect” Approach

A simpler approach is to create a hard redirect like the following. This takes widgets.mysite.com/files/?id=20 and redirects it to www.mysite.com/widgets/:

ServerAlias subdomain.mainsite.com
RewriteEngine on
RewriteCond %{HTTP_HOST} ^subdomain.mainsite.com$ [OR] 
RewriteCond %{HTTP_HOST} ^www.subdomain.mainsite.com$ 
RewriteRule ^(.*)$ http://www.mainsite.com/subdirectory [R=301,L]

This goes into the apache config, inside mainsite.com’s VirtualHost directive.

ServerAlias directive allows the main site to also accept queries for the subdomain.
You may also need to add a DNS entry, depending on your setup.

RewriteCond with www.subdomain.mainsite.com is optional and recommended–if you remove it, also remove the [OR].