1

I'm attempting to debug a unit test for a WordPress plugin. The unit test uses wordpress-test (and PHPUnit). However, wordpress-test:

  1. calls system(php ...)
  2. the new external PHP process attempts to connect to the same debugger,
  3. but the debugger is already busy
  4. so both PHP processes hang.

— How can I prevent this?

Details / clarifications:

Initially, when I debug my unit test (like so:$ phpunit --verbose --debug), then phpunit connects to Netbeans on port 9000 and everything works fine. After a while, however, wordpress-test runs a certain bin/install.php in order to setup a fresh WordPress database for the "unit" tests to use.

But wordpress-test runs bin/install.php via a system("php ...") call. And then the external php process attempts to connect to the Netbeans debugger again! This blocks, because the debugger is already busy — the first PHP process is open in the debugger, running the system(...) call.

Issue 1

Why does the second PHP process attempt to connect to the debugger, although I've specified no debug flags? The process is created via this PHP call and there are no debug flags, here is the argument to the system call:

php '/var/www/wordpress/wp-content/plugins/my-plugin/wordpress-tests/bin/install.php' '/var/www/wordpress/wp-content/plugins/my-plugin/wordpress-tests/unittests-config.php'

Issue 2

How can I stop the external PHP process from connecting to the debugger?

(Removing the external system call completely, and including /bin/install.php directly instead, seems complicated — there are errors like Cannot redeclare [some-function])

(By the way, if you'd like to use wordpress-test, then see this SO answer.)

Improve this question
6
  • 1
    PHP debugging, while you might be working with WP, isn't really a WP question ... unless someone can make a compelling argument otherwise, I'm closing this as off-topic for now.
    – EAMann
    Commented Jul 12, 2012 at 20:52
  • @EAMann Would it be more constructive to change the title to 'How to debug a WordPress unit test plugin, written in wordpress-test?', rather than closing the issue? Thanks for cleaning it up so it looks nice — and whilst you were editing it anyway, why not edit it so it's on-topic, instead of editing it and closing it as off-topic? Seems I cannot change the title now after it's been closed, well.
    – KajMagnus
    Commented Jul 13, 2012 at 9:20
  • There are other debug related questions: 18 upvotes, "How do you debug plugins?". "How to debug a plugin with Xdebug?" 7 upvotes.
    – KajMagnus
    Commented Jul 13, 2012 at 9:25
  • Yes. Edit the question and title to make it explicitly about WordPress (rather than about juggling PHP processes and XDebug) and I'll reopen it. As it's written, it's not a WP-specific question.
    – EAMann
    Commented Jul 13, 2012 at 13:54
  • @EAMann Now I've rephrased it
    – KajMagnus
    Commented Jul 13, 2012 at 19:01

2 Answers 2

Reset to default
3

Now I've found a solution [to issue 2 above]: I prefixed the external PHP command with: XDEBUG_CONFIG="remote_enable=Off"
and then it didn't attempt to connect to the debugger.

So, in wordpress-tests/init.php I changed from:

system( WP_PHP_BINARY . ' ' . escapeshellarg( dirname( __FILE__ ) .
    '/bin/install.php' ) . ' ' . escapeshellarg( $config_file_path ) );

to: (note the addition of the XDEBUG_CONFIG line)

$install_blog_cmd =
        'XDEBUG_CONFIG="remote_enable=Off" ' .
        WP_PHP_BINARY .
        ' ' . escapeshellarg( dirname( __FILE__ ) . '/bin/install.php' ) .
        ' ' . escapeshellarg( $config_file_path );
system( $install_blog_cmd );

Update: Now I opened a GitHub issue: https://github.com/nb/wordpress-tests/issues/27

Update: Issue 1, that is, why does the system(...) launched PHP process connect back to the debugger, is probably (?) because in my file /etc/php5/conf.d/xdebug.ini, I have this row:

; Xdebug will always attempt to start a remote debugging session 
; and try to connect to a client, even if the GET/POST/COOKIE
; variable was not present
xdebug.remote_autostart=1
Improve this answer
5
  • A nice catch. I wonder why no more people are complaining about this issue? And is changing the official source code really the only way? Is it possible to solve this in a more clean way be for example checking if xdebug is already opened and if yes, connect to the existing instance instead of creating a new as is attempted here? I suspect if you run this modified source code outside of NetBeans it won't connect to xdebug because we explicitly set remote_enable=off?
    – kjetilh
    Commented Oct 22, 2012 at 17:18
  • Oh, I noticed adding 'XDEBUG_CONFIG="remote_enable=Off"' doesn't really do anything. PHP tries to execute the program XDEBUG_CONFIG and naturally fails. Commenting out the entire system function call gives the same result while avoiding an error
    – kjetilh
    Commented Oct 23, 2012 at 8:14
  • @kjetilh I don't remember this issue particularly well. As far as I can remember, my PHP config file was rather unusual, in that I had configured PHP to automatically connect back to the client. Perhaps your PHP debug config file (xdebug.ini) isn't similar to mine, and hence remote_enable=Off is not needed (?)
    – KajMagnus
    Commented Oct 23, 2012 at 8:33
  • @kjetilh If PHP really tries tot execute a (non-existing) program XDEBUG_CONFIG, then I wonder if there's a typo in your script? (The $install_blog_cmd command clearly executes WP_PHP_BINARY — XDEBUG_CONFIG= simply sets an environment variable (I'm using Ubuntu Linux, the Bash shell). Please note that that line is concatenated with the following line (i.e. the WP_PHP_BINARY line), note the trailing ..)
    – KajMagnus
    Commented Oct 23, 2012 at 8:37
  • ah I totally forgot system() is not OS agnostic.. I'm using Windows maybe that has something to do with it? In Windows (commandline) one sets env vars with SET {VARNAME}={VALUE}. Anywho, I also noticed I've created the database for the WP tests beforehand manually so perhaps that's why I could comment out that line. Arguably not the most ideal solution as I have to write drop/delete statements to clean up integration tests but it works.
    – kjetilh
    Commented Oct 24, 2012 at 11:07
0

For myself, I was missing a define in the config file.

Put this define in your config file in the tests directory and you should be golden:

define( 'WP_PHP_BINARY', 'php' );

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.