How can I debug a URL called by a script?

Part of a project I am working on includes a postback URL, let's call it "postback.php".

In the live environment, another server is calling "http://mydomain.com/postback.php?p1=v1&p2=v2".

For testing I set up a simple script, called "test_postback.php".  This script simply provides a form where I can fill in parameters, and then when posted it build the url and gets a response using the file() function.  E.g.

$p1 = $_GET["p1"];

$p2 = $_GET["p2"];

$url = "http://localhost/postback.php?p1=$p1&p2=$p2";
echo "<p>$url</p>";

echo @file($url);

But when I ran it I was getting an error back.  I tried setting breakpoints, and although it broke in "test_postback.php" it didn't break in "postback.php".

I more or less understand why - "test_postback.php" is called from the browser, but "postback.php" itself is called from PHP.

"postback.php" is quite complex and relies on a number of other scripts, so it took me a while to track down the error.

Is there some way that I can get PHPStorm to go into debug mode for this situation?

10 comments
Comment actions Permalink

Hi Jon,

Q: why not debug postback.php directly? -- will be much easier.

In any case ... when debugging, the xdebug cookie (or parameter) needs to be passed as well (I'm assuming you are using xdebug here).

Therefore I suggest:

$dbg = isset($_GET['XDEBUG_SESSION_START']) ? '&XDEBUG_SESSION_START=' . $_GET['XDEBUG_SESSION_START'] : '';
$url = "http://localhost/postback.php?p1={$p1}&p2={$p2}{$dbg}";

Use it with PHP Web Application configuration type (using Debug button).

The problem that I have seen here .. is that it worked for me 2 times .. and then it just stops (no more debugging available) when calling that second page -- don't know what I have done wrong, but that is what I've had.

Another possible approach (worked better for me):
1. Use this code:

$dbg ='&XDEBUG_SESSION_START=PHPSTORM'; // or whatever other IDE Key
$url = "http://localhost/postback.php?p1={$p1}&p2={$p2}{$dbg}";

2. Make sure you have "Break at first line (for external connections)" selected in Settings | PHP | Debug (although this is optional if you are using breakpoints -- it's just a bit more safer)
3. Turn on  "Run | Start Listen PHP Debug Connections"
4. Open that page (test_postback.php) in browser (you can use Run button instead of Debug for the same configuration)
     a) PhpStorm may ask you to debug your test_postback.php file. If so .. and debug halts on that @open() line, just disconnect ("Stop" button) debugger session. For me PhpStorm opens another session just for that included file (postback.php)
     b) If it does not ask to debug the test_postback.php (but you need to debug it) -- then you may need to use bookmarklet or some browser extension etc to set that debug cookie/parameter. If you do not need to debug that file, then for me PhpStorm just offers to debug postback.php straight away

0
Comment actions Permalink

Hello Jon,

Do you still have the issue?

Thank you for feedback!

0
Comment actions Permalink

I haven't tried it yet.

Having to change the code for debugging purposes seems like a bit of a hack.

I would have thought there was some way in the interface to do this, but I guess not.

0
Comment actions Permalink

Jon,

Try to enable 'xdebug.remote_autostart' option (http://xdebug.org/docs/remote#remote_autostart). If this option enabled, Xdebug will initiate a debug session on every connection (so you don't need to enable it through cookie or get parameters).

Thank you for feedback!

0
Comment actions Permalink

You requesting another page not using a browser, but using PHP-own functionality -- you have to somehow tell debugger that you want to debug this 2nd request as well.

The only way of not providing such "debug this" flag (let's call it this way), is to use xdebug.remote_autostart = 1, but this will attempt to debug every single request that will be processed by PHP, which can make your debugging experience much worse (it really depends on your setup and workflow) -- I , for example, did not liked it on mu projects.

EDIT: I'm too slow at posting ...

0
Comment actions Permalink

Andriy,

for example, did not liked it on mu projects.

Please elaborate. Probably we can improve something here.

Thank you for feedback!

0
Comment actions Permalink

Don't think anything can be done here -- it was long time ago (over a year, if I recall correctly) and it was my specific circumstances: while I was debugging some code, the site was used by other people as well (checking pages, adding products etc) -- all on the same dev site as latest code was a requirement ("I want to see progress/changes immediately, very very important" -- this kind if thing). With that xdebug option, I was often interrupted with requests for other pages which I did not do. That's why I wrote "it really depends on your setup and workflow".

I do not have such circumstances any more and have not tested that option since then (everything works just fine without it). But even if I would have the similar circumstances, this time I can create another site just for debugging that code (even if it will take some time) as I have full control over the server (last time it was completely different).

One small thing to add about remote_autostart -- xdebug tries to connect to client on every request, even if there is no client listening. It can wait up to whole second or so (based on my observations) before proceeding with normal page execution. Because of that, the website may look a bit slow, especially if you have few ajax requets etc. In this regard it is much easier just remove xdebug cookie with browser extension or bookrmarklet than edit php.ini, restart webserver all the time when you need to switch between debug/normal run.

0
Comment actions Permalink

Andriy,

Thanks for sharing!

0
Comment actions Permalink

Hello Jon,

Have you tried my suggestion?

Thank you for feedback!

0
Comment actions Permalink

Sorry for the delay in replying, got pulled away onto another urgent project - you know how it is.

I tried using the $_GET['XDEBUG_SESSION_START'] option, but it didn't exist in $_GET, so had no effect.

I tried the XDEBUG_SESSION_START=PHPSTORM too.  It sort of worked, sometimes, and sometimes it just seemed to hang.  It was a bit quirky.

I tried enabling the remote_autostart setting, but that seemed to have no effect at all.

I don't really have time now to look at it in more depth, but you'vegiven me a few things I can try if I need to do this sort of nested debugging again.

Thanks!

0

Please sign in to leave a comment.