debugging php across multiple webpages

Hi Ethan,

I'm using similar setup myself. The only thing that is missing is to have some sort of browser extension (or bookmarklet) that will help you with setting the debug trigger (I mean this: "XDEBUG_SESSION_START=PhpStorm1"). Once you trigger the debug mode using such extension, it will send that "debug_this_page" command for every page you browse on that site until you deactivate it. If you have no breakpoints setup in the files that being executed it will run as normal (unless you select "Break at the first line" in PhpStorm).

Here are few extensions that will do the job:

• Google Chrome: Xdebug helper -- https://chrome.google.com/extensions/detail/eadndfjplgieldjbigjakmdgkmoaaaoc
• Mozilla Firefox: easy Xdebug -- https://addons.mozilla.org/en-US/firefox/addon/58688/
• Different Xdebug extensions overview/list: http://derickrethans.nl/new-xdebug-helper.html

• Xdebug bookmarklet: http://pollinimini.net/blog/xdebug-bookmarklet/

If you search for xdebug topics here on forum you will see that lots of people mentioning using them.

After installing such extension just configure it with proper IDE key (in your case it will be PhpStorm1) and add your domain to allowed list (required for Chrome extension).

There has to be another way.

We use Netbeans as well, and we can change pages on it and it works fine (and that querystring variable is not passed, except to the first page.)

You do not see it -- but it is passed (I assure you) -- just because it can be passed via query string as well as via cookies. The browser extensions mentioned are sending it via cookies.

Ok, then it's just broken, cause it don't work.

What exactly does not work?


Xdebug checking for appropriate cookie (XDEBUG_SESSION) first. If it is not present, then it does check the query string/post data for XDEBUG_SESSION_START parameter. If none of them present then xdebug does not initiate connection to debugging client (PhpStorm in our case). When Xdebug sees XDEBUG_SESSION_START parameter, it creates cookie XDEBUG_SESSION which has value that was assigned to that parameter. Such cookie life time is limited to 1 hour.
http://xdebug.org/docs/remote

There is possibility that when you initiate debug session (with XDEBUG_SESSION_START parameter), session cookie set by Xdebug may get lost. For example:
* initial request was not completed fine -- you interrupted/aborted/closed debugger, the connection get dropped, browser may not receive cookie
* you are doing some specific cookie/session/headers manipulations which prevents (somehow) Xdebug cookie to be saved/passed back to browser.

The above is one of the reasons why I do not rely on XDEBUG_SESSION_START parameter usage -- browser extension works directly with XDEBUG_SESSION cookie.



This is how I do it in PhpStorm (I did almost the same when was using phpDesigner) -- it allows me to debug any page when I need it:
1) Create appropriate debug configuration (if not created yet). I have only 1 configuration for whole project (for index.php) -- it will works for every page (if following all the steps).
   * Important note: I'm using "Wait for connection with ide key: PhpStorm1", not the "Open web page in browser" in Run/Debug Configuration -> Debug Tab -> Advanced
   * I'm not using "Match local path" like Ethan does -- I have "Custom web path: /index.php" option selected.
2) Select it in that dropdown list (if not selected already) and click "Debug" button. It will launch debugger which will say "Waiting for connection on port 9000 with ide key PhpStorm1" (port number and ide key may differ)
3) I assume that you already have breakpoint(s) set up.
4) Tell Xdebug that we going to debug next page request (using browser extension).
5) Click on the page/link you want to debug in your browser -- Xdebug will see cookie and will initiate connection to client:
  * if no connection can be established (misconfiguration or forgot to activate debugger in IDE) it will run in normal way
  * if client (PhpStorm) accepts connection then it will execute it in debug mode (stopping on breakpoints/first line if required).
6) Debug your application
When debugging is no longer required (you fixed the issue and now want to see how it will run "naturally") deactivate cookie  (using browser extension).

Yes, you can use "Open web page in browser" option instead of "Wait for connection with ide key" -- I'm not using it because it is just not good for my setup. But I have tested it before .. and did just now -- it works fine for me on latest EAP build PS-98.458 (after finishing with initial request you can debug another link/page -- as long as appropriate cookie was set by Xdebug).



I have not used NetBeans that much (tried few times over half an year ago when find out about PhpStorm) so cannot tell how exactly does it work.

I can put screenshots of my debug configuration setup if required.

EDIT: Here they are, see attachments.

thanks for the info, this is a good start.  one thing I'm confused about, though.  after I start a debug session, either via 'wait for connection' and putting the XDEBUG_SESSION_START param onto the query string myself or via the 'open web page' method, I have an XDEBUG_SESSION cookie.  I can see it in firefox; it has the correct ide key and isn't expired.  however, the debugger only seems to break on the initial request (the one that had the XDEBUG_SESSION_START query string param in it).  if I click around, it won't break even though I have the XDEBUG_SESSION cookie set.  why is that?  isn't that all the browser extension does - make sure the cookie's set?

Hello Ethan,

I cannot quickly suggest solution for you case so please provide debugging log.
Collecting WebStorm and PhpStorm Logs

If you do have the cookie set (with correct IDE key) then it should stop (pass control to PhpStorm) on breakpoint (if it can do it fine with parameter passed so should do with cookie as well). Extension just sets cookie when debugging is required and removes it when you do not need it anymore (you have to click on icon/button in your browser to trigger it) -- I cannot guarantee if it actually checks if cookie is still present or not. Because debugger works when invoking with XDEBUG_SESSION_START parameter, then this is not the mapping issue (as I understand you are running on the same computer).


0) Write a very basic script which we will be using for testing. For example:

<?php

$param = isset($_GET['param']) ? $_GET['param'] : 'not found';
$param_up = strtoupper($param);

echo 'XDEBUG_SESSION=', isset($_COOKIE['XDEBUG_SESSION']) ? $_COOKIE['XDEBUG_SESSION'] : 'not found', "<br>\n";
echo "param={$param}<br>\n";
echo "param_up={$param_up}<br>\n";

1) Can you please tell a bit about your setup (PhpStorm version/build; OS; PHP version, Xdebug version etc).
2) Can you please collect debug log and attach here (make a successfull attemp first, then try for the same file but when it fails). You may also want to collect logs using xdebug itself (see docs for xdebug.remote_log option).
3) Can you post your xdebug config (I doubt that we will find anything wrong there)

You said that it works fine in another IDE (I assume it is on the same computer). If so then the next points should not apply to you .. but can you double check them (just in case)
4) I know, I may sound very untrusty, but can you ensure that xdebug cookie was sent (using firebug's Net panel, for example -- just expact page request and see 'Cookies' tab) as well as received (just make 2 copies of test script -- invoke first one with XDEBUG_SESSION_START parameter and second wihout it -- you can use it in #2as well).
5) Maybe it's one of your Firefox extensions that causing problem -- can you test the same in another browser (or empty profile).

well, i feel a bit silly now.  once I turned on debugger logging (brilliant tip; thanks for that!) I noticed that xdebug was passing along the ECLIPSE_DBGP ide key each time I clicked around my site.  digging around in my project files, I discovered a little bit of code I must have added a year ago that sets the XDEBUG_SESSION cookie on every request with the ECLIPSE_DBGP ide key; must have set this up for eclipse debugging back in the day.

I went into my debug config, changed it to 'wait for connection' and put in ECLIPSE_DBGP as the ide key and lo and behold, I can now break anywhere in my project :)

thanks to everyone for all your help!

Andriy,

Thanks for your help!

Wow, that was a an unexpected variant - just overriding the cookie in your code %)

yeah, it's an odd twist ;)  in thinking back on it, I came up with that hack because our site has many domains.  if I had to debug an interaction that required me to click from one site to another, I'd lose the XDEBUG_SESSION cookie.  so, I just added in a bit of developer-only code to always emit that cookie with the same value no matter what domain I was on and presto: cross-domain debugging!

It's all so inconsistent. I was writing a post to tell you that I cannot get it to work once I change pages, as the other gentleman said, and no, I don't have any kind of hack that is causing the problem, but now, I can't get PHPStorm to break on any breakpoints at all. I can get it to break on the first line, but that's it. Even when I get it to break on breakpoints, I can't change pages, or it stops working. Maybe the cookie isn't being said, but how do I know that?

Oh, and I'm using Open web page in browser. I have never gotten the other method to work. I tried again just now, and no go. In that configuration, here is my php.ini:

[xdebug]
zend_extension="c:/php/ext/php_xdebug-2.1.0-5.3-vc9-nts.dll"
xdebug.remote_enable=1
xdebug.remote_host=127.0.0.1
xdebug.remote_port=9100
xdebug.remote_handler=dbgp
;xdebug.remote_autostart=1
xdebug.idekey=PhpStorm1
xdebug.profiler_enable=1
xdebug.profiler_output_name=cachegrind.out.%s
xdebug.profiler_output_dir=c:\xdebug_prof

Ok, yea, I remember now. I have to enable Validate Xdebug configuration before debug for it to work. Yet, this FAILS every time, and I just Ignore and then PHPStorm will stop on breakpoints. However, I still cannot debug across mulitple pages.

To continue my rant about the inconsistency, now, I made some changes trying to get other methods to work.Then put it all back and now the configuration that I just commented about that was working....isn't. Yet, I have another configuration, exactly the same except to a different web page, and it's working fine. One won't stop at breakpoints and the other will.

And now, it's making a complete liar out of me, as the one that works (not the original), will now debug across multiple pages. What the heck????

In this configuration that works, I don't even the the Validate option checked. I don't see how these can be so inconistent. I'm going to create some from scratch and see what happens.

Created a new one and it all works. Strange. Is it possible that the PHPStorm configurations themselves got corrupted somehow?

I've already learned :p that the best answer for such questions is to ask for debugging logs in PhpStorm (or/and using xdebug.remote_log). As you can see yourself it can help resolve quite a lot of situations relatively quickly.

When "Validate Xdebug configuration" fails, what does it say (what are the messages) ?


[Offtopic]
I don't really think that having debugging session + profiler ON at the same time is really a good idea (at least it was not recommended for pre 2.1 builds).

You do not need to have it constantly ON (with xdebug.profiler_enable=1), instead you can use xdebug.profiler_enable = 0   &   xdebug.profiler_enable_trigger = 1, and then trigger profiler externally (with browser extension, for example).


P.S.
You are progressing with your situation so fast, that I cannot even decide -- should I post or just watch how you resolving it yourself :)

Bazzik wrote:

I've already learned :p that the best answer for such questions is to ask for debugging logs in PhpStorm (or/and using xdebug.remote_log). As you can see yourself it can help resolve quite a lot of situations relatively quickly.

When "Validate Xdebug configuration" fails, what does it say (what are the messages) ?


[Offtopic]
I don't really think that having debugging session + profiler ON at the same time is really a good idea (at least it was not recommended for pre 2.1 builds).

You do not need to have it constantly ON (with xdebug.profiler_enable=1), instead you can use xdebug.profiler_enable = 0   &   xdebug.profiler_enable_trigger = 1, and then trigger profiler externally (with browser extension, for example).


P.S.
You are progressing with your situation so fast, that I cannot even decide -- should I post or just watch how you resolving it yourself:)

Thanks for the tip on the logs, and yes, sometimes I just need to hammer it out in public to solve the problem.

The truth is, we find using debuggers with PHP such a huge pain in the !$#$, that we don't use them. I mean, I do, as the senior developer, but only when all else fails or we're debugging something that is just ridiculously complicated.

I know that probably appalls some people, but I've been down this road so many times, and there are several reasons why we won't use it:

• Having XDebug turned on slows the performance of the app down way too much (I don't mean using it, I mean loading it) so...
• I wrote an AutoIt script that enables and disables the extension via the php.ini file, but that takes a 30 seconds to load and unload
• The script times out too fast (PHP), even though I have our time out set to 2 minutes, it won't stay running that long
• XDebug tends to crash when watching complex arrays or objects (mainly objects, any ideas on that?)

So, we debug manually. I'm pretty darn good at it and have built many tools into the code itself for debugging. We're an all Intranet site, so I can afford to do that.

As for the profiler, you are probably right, but as I said, we use the debugger so infrequenlty.....

In this tread you have mentioned that PhpStorm maybe corrupting some files. And now this broken/corrupted debug configuration. Maybe you should test your PC memory (RAM) -- it can easily corrupt files when copying/saving them. I have experienced such behavior myself (corrupted files out of nowhere) almost 4 years ago, just a month after I bought new PC.

1) Which web server do you use? As I understand from your xdebug config, you are running non-thread safe version of PHP. Maybe it is IIS?

2) Try Zend Debugger (works on all platforms, FREE) -- for some people it's much better (there is one ticket on issue tracker, he works on Mac)

3) Since you do debugging manually -- do you use FirePHP, very handly tool (especially for debugging Ajax requests)

1. IIS (6 on production - Server 2003, 7 on development - Windows 7)
2. I've tried ZD in the past, but couldn't get it to work at all....still, I am thinking about giving it another shot. We area actually about to let 3 licenses for Zend Studio expire, due to the poor support and product that has become less and less relevant (we switched to Netbeans, and not PHPStorm...well, we use both NB and PHPStorm.)
3. Never heard of FirePHP...I'll check it out!!!

Ugh, I didn't realize FirePHP is a Firefox. We are strictly an IE camp here (Windows, IIS, Authentication, and all that.) Still, our site is about 95% FF compatible (don't have to worry about cross browser compatibilty when you are the IT Director and manage the whole site )

The script times out too fast (PHP), even though I have our time out set to 2 minutes, it won't stay running that long

Well, you debug your scripts on development server, not production. So IIS v7.5 (on Windows 7), I assume it is done via FastCGI (not normal CGI).

If so:
1) Launch IIS Manager
2) Go to FastCGI Settings
3) Select your PHP installation, Right click -> Edit...
4) Now increase values for these parameters:
Activity Timeout
Request Timeout
(I'm not sure if both are actually required, but that's what I did).

This will prevent IIS from killing PHP scripts too early. You will have like 700 seconds (over 11 minutes) if you do similar setup (see screenshot attached).

Ugh, I didn't realize FirePHP is a Firefox. We are strictly an IE camp here (Windows, IIS, Authentication, and all that.) Still, our site is about 95% FF compatible (don't have to worry about cross browser compatibilty when you are the IT Director and manage the whole site ;) )

But that does not mean that you cannot use Firefox, at least for debugging purposes (Firebug extension is a way too good to ignore. Add FirePHP here ... ). At least give it a try.