Judging by the many posts in this forum, I must be one of the few people to get the debugger to work! All fairly standard Windows XP with Apache 2 and PHP 5.0.4.

Anyway...

There seems to me to be a HUGE understanding problem here - DBG puts the DBGSESSID details into the GET (and QueryString) lines! This might be ok for some languages, but for PHP and the web it seems quite useless. Unless the PHP code is fairly simple it will almost always use the POST or GET functions to get and pass data. If DBG tries to put its own data in there (as it is doing), it will not allow the PHP code it is trying to debug to work! So what is the point of running the debugger?

I have just spent an hour or so trying to work out why a particualr page will not load - and I eventually found that it was checking the POST line - and then doing a "Switch" based on the contents. But the return value is some long DBGSESSID line! I thought about writing code to remove the DBGSESSID stuff, but that would be a real pain.

Why use POST/GET?? Surely it defeats the whole idea of trying to debug a PHP file?

I am sure the issue is not as simple as this - and that the designers of this program would have thought of this - so what am I missing?

I have not had a problem with dbg once I understood what it expects.

I've had success with both windows and linux, with apache 1.3.x and php4.x and php5.x. Before you make sweeping statements, please consider the impact of your comments to users evaluating the program.

Anyway...

GET works fine, as does POST. The reason it is there is for security and functionality. So we can pass arguments to and from the debugger. Definitely the debugger has to have some way to accept and parse parameters given by the person debugging... If not GET or POST then what? There has to be some method of communication, and it can do it with cookies as well.

Look here at this post:

phped-debugger-profiler-bookmarklets-t1615.html

Could you please be more desciptive on how DBG data would affect debugging your code?
Suppose your script needs two variables passed via GET (or POST). Open Run->Parameters and type variable names, values and their type (GET or POST). That's all you need to get them passed to your script when you run or debug it.
If you need to debug a script that's POSTed from a form located in another PHP or HTML file, you can do it too. See General FAQ, HOW TO run debug session post.

Yes - after some time I also worked out the problem. POST and GET do work fine - as long as you extract individual variables (as you normally do). The problem, as it was in my case, was that I was also using $_SERVER['QUERY_STRING'), and that is where the real problem is. This variable will no longer work, so if your code uses it, then you will have to change it!

And by "not work", I mean it will have your stuff in there PLUS all the DBGSESSID stuff. This can be a real problem if you are not a PHP programmer, and are just trying to get free downloaded scripts to work! But then, if you were not a PHP programmer, why would you be using PHPEd? I had two free scripts that did not work at all in PHPEd, but did outside of the editor. Once I worked out the QUERY_STRING problem, I modifed the code and it all worked ok.

The thing was - this took me half a day to work out - it would be good to mention these very real issues in the documentation somewhere, especially as it goes to the very core of how DBG works..

Probably you have to read php manual first. All variables are extracted automatically and are in $_GET and $_POST arrays.

If you're not programmer, you would not need php debugger. If you need to get a script to work, you're either a programmer or need to hire a programmer.

Experience is not a simple thing to get

Well, reading the PHP manual is out - who does that? I work in half a dozen languages, how can I learn all of them intimately? But you are wrong there, I think. I have worked in PHP on an off since PHP 3, I think, and these superglobal arrays are only recent innovations. Indeed, as of PHP 4.1.0 onwards according to the manual.


But a few words in the documentation would have saved so much time. The thing is, it is not for me - I have already worked it out - all the other new people out there will have to work out exactly the same thing, which is a big waste of time.

I think that is the good thing about these forums - new users (or even inexperienced ones like myself) can look around and see if other users have the same problem, and what they did to fix it.

I agree , new or unexperienced people would look around and see if solution is already found and published in the forums.