It’s an Emacs weekend here at blog.arithm.
I was recently asked if it was possible to do remote PHP debugging with Emacs. We’re talking about Emacs, so the answer is: Of course! How to do it:
- Grab Tohru Fujinaka’s GEBEN library. It’s an aging alpha release, but works fairly well.
- Make sure you also have CEDET installed. I’m using the 1.0 pre4 release.
debugclient somewhere in your path. (Here Emacs is running on Windows, so I just threw it into the
C:\WINDOWS\ directory.) Make sure the executable is named “debugclient” and not “debugclient-0.9.0” or whatever.
- If you’re using the standard xdebug port 9,000 (recommended), make sure that port is open on your firewall. For most folks these days that means opening up the default OS firewall as well as forwarding a port from the router. See the exceptional portforward.com for more information on router port forwarding specifics.
Now, assuming you already have xdebug plugged into PHP, modify php.ini or an .htaccess file with the following settings:
xdebug.remote_enable = true
xdebug.remote_handler = dbgp
xdebug.remote_host = your_client_ip
For security reasons it’s wiser to do this via .htaccess on directories that permit only authenticated access.
To debug, ask Emacs to listen for connections by going into GEBEN Mode with
Meta-x geben. You should see “xdebug started.” in the status row at the bottom of the Emacs window.
Run your PHP script with the xdebug switch on, eg.
If everything is setup correctly, Emacs will load the source of script.php (be wary of security!) and allow you to step through the code.
Available commands are:
spc step into/step over
i step into
o step over
r step out
b set a breakpoint at a line
u unset a breakpoint at a line
Some gotchas: I’ve noticed the GEBEN expects the first keystroke to be “space”; often it will freeze otherwise. GEBEN may also run into problems on certain session-related PHP commands.
In order to run Windows commands via PHP functions such as
open_proc(), apparently one has to grant read/execute permissions to the account under which IIS is running (usually IUSR_<servername>) on
C:\WINDOWS\System32\cmd.exe. Be sure to do this for web apps that rely on external commands.
This of course took me an eternity to figure out. I was only able to piece together WebSVN‘s bizarre Windows mis-behavior after scouring through the remnants of forum posts limboed in Google cache. PHP.net of course has no proper details on this, though I do now better understand what
proc_open‘s obscure and undocumented
bypass_shell parameter might be about.
Ah yes, PHP on Windows. Obscure and irritating.
Kind of like me. Not that that makes it any better.
Ugh. As usual, more weird problems while trying to upgrade PHP on a Windows box. Are we having fun yet?
If you find that the MySQL extension won’t load, then probably a previous PHP installer has placed a version of
libmysql.dll somewhere else in your path. Look in
The problem is almost certainly the reason for the following obscure comment
Although copying libmysql.dll to the Windows system directory also works (because the system directory is by default in the system’s PATH), it’s not recommended.
in the PHP MySQL documentation.
Make sure your home PHP directory is in your path, and that its finding
libmysql.dll there and only there.
If you are using Zend’s installer to upgrade PHP on Windows, the installer will probably break your file type mappings. Double check to make sure that .php points to the correct ISAPI dll in IIS.
(IIS -> Home Directory -> Configuration… -> Mappings)
Ugh. Nobody seems to know what this thing is, though it seems to be some kind of PHP worm roving the internet looking for phpMyAdmin exploits. It appears to have been around since 2005 and searches for an exploit in the
phpMyAuth class of older phpMyAdmin distributions.
I’ve seen it knock one of my servers on three seperate occasions; this from the first:
[05/Jul/2007:20:26:42 -0500] "GET /mysql-admin/main.php HTTP/1.0" 404 280 "-" "pmafind"
[05/Jul/2007:20:26:42 -0500] "GET /phpMyAdmin-2.5.6/main.php HTTP/1.0" 404 285 "-" "pmafind"
[05/Jul/2007:20:26:42 -0500] "GET /main.php HTTP/1.0" 404 268 "-" "pmafind"
[05/Jul/2007:20:26:42 -0500] "GET /phpMyAdmin-2.5.1/main.php HTTP/1.0" 404 285 "-" "pmafind"
[05/Jul/2007:20:26:42 -0500] "GET /phpMyAdmin-2.5.4/main.php HTTP/1.0" 404 285 "-" "pmafind"
[05/Jul/2007:20:26:42 -0500] "GET /phpMyAdmin-2.2.3/main.php HTTP/1.0" 404 285 "-" "pmafind"
[05/Jul/2007:20:26:42 -0500] "GET /phpMyAdmin-2.2.6/main.php HTTP/1.0" 404 285 "-" "pmafind"
Interesting that it looks for specific versions of PHP. And odd that it announces itself by specifying a user-agent. (“Hi, worm here. Please let me in. Got a bit of infesting to do.”)
Deadmoo has a good, recent-ish post about it, though mostly Google just returns random posts and stats pages listing the pmafind referer. Where do these things come from?