Debugging PHP on Windows with XDebug and VIM

1211377553 4 Comments , , and

Habari is a sufficiently complex PHP application that sometimes the only way to figure out what is going on is to fire up a debugger. Following a suggestion on #habari and some google searching, I found an article on the Box.net blog on using XDebug with vim. The instructions were for a linux box, and I initially struggled to get things working on Windows (XAMPP). But, I finally got it through digging through the comments on the Box.net article and Vim documentation. I thought it would be useful to gather the required steps in one place, so here are my instructions:

  • Read the Box.net article.
  • Download XDebug and put it in xampplite\php\ext
  • Edit xampplite\apache\bin\php.ini. Add these lines: zend_extension_ts="c:/xampplite/php/ext/php_xdebug-2.0.3-5.2.5.dll" xdebug.remote_enable = 1 xdebug.remote_port = 9000 xdebug.remote_host = localhost
  • Restart Apache. Check that xdebug appears on your phpinfo() page.
  • Download the xdebug plugin for Vim and put it in: C:\Program Files\Vim\vim71\plugin
  • Download and install Python 2.4 (not 2.5). You can see which version of Python your copy of gVim is looking for by looking for the ‘python’ string in the gVim binary (dirty, but it works!)
  • Now you need to modify debugger.py to work with windows paths, so open debugger.py in gVim
    • Change the session file to something reasonable. XAMPP has a directory that already serves this purpose, so you might change self.sessfile to self.sessfile = "C:\\xampplite\\tmp\\debugger_vim_saved_session." + str(os.getpid())
    • Now change every occurance of getAttribute['filename'][7:] to getAttribute['filename'][8:]. Do the same with getAttribute['fileuri'][7:]
  • Open up a browser and append ?XDEBUG_SESSION_START=1 to the end of an address on your local webserver.
  • Open gVim. Hit F5, then refresh your browser page. You should now be debugging!

Fixing CRLF issues when applying patches in a multi-platform environment

1211157565 1 Comment , , and

In my role as a Habari developer, I have been increasing butting heads with the same issue. I do some development on my windows machine at home, create a patch file with TortoiseSVN and upload it to trac. Then, I arrive at my iBook at work and download my patch. When I go to apply it though, I get messages such as this:

physics-2004-19:~/Sites/habari bjohnson$ patch -p0 --dry-run < timelineSearch.patch (Stripping trailing CRs from patch.) patching file system/admin/comments.php (Stripping trailing CRs from patch.) patching file system/admin/entries.php (Stripping trailing CRs from patch.) patching file system/admin/js/admin.js Hunk #1 FAILED at 190. Hunk #2 FAILED at 230. Hunk #3 FAILED at 277. Hunk #4 FAILED at 385. 4 out of 4 hunks FAILED -- saving rejects to file system/admin/js/admin.js.rej

Patch is failing because it is not appropriately dealing with the way that Windows machines and Unix-based machines (including OS X) signify an end of line. On Windows, a newline is specified by a carriage return (CR) followed by a line feed (LF). On Unix, however, a newline is just a LF. The ‘patch’ command is somewhat intelligent in dealing with patch files created on a Windows machine, in that it converts all CRLFs in the diff file to LFs before applying the patch. The problem, however, is that the target file might also have CRLFs in it. This is frequently the case when working in a multi-platform development environment like so many open source projects. The fix: remove all CRLFs from the target files before applying the patch. An easy way to do so is with the ‘tr’ command. For example:

tr -d '\r' < admin.js > temp; rm admin.js; mv temp admin.js

Now apply your patch. Problem solved!

 1

User