creating response headers
PHPWeby has a great article on how to create response headers for various means, such as 503, file download dialog, apache authentication, and so on.
http://phpweby.com/tutorials/php/35
PHPWeby has a great article on how to create response headers for various means, such as 503, file download dialog, apache authentication, and so on.
http://phpweby.com/tutorials/php/35
I struggled for several days to set up remote debugging. I wanted to be able to remotely debug a single virtualhost on my CentOS server using my local IDE (PhpStorm) and xdebug.
Since this took me quite a while to figure out, I thought I’d include the steps here for others.
Over SSH, I ran the following:
$ pecl install xdebug |
;;;;;;;;;;;;;;;;;;; ; 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 |
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!
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.
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!
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.
Today I was unable to start Apache using a new install of XAMPP. A quick netstat -o in cmd showed something was blocking port 80.
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.
Wanted to redirect our old standby, pastebin.zentrack.net to the new location, dev.zentrack.net/pastebin. Took a bit of mojo to find the answer to that problem. I decided on using apache and bypass virtualmin’s admin tools.
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.
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].