Hi All,
Trust me I have tried to read through as many relevant topics before posting this. Remote debugging seems to be such a individual topic related to each installation etc. So here is my situation.

I have phpED 6.2 running on my Win 7 box.
I have installed remote debugging on a Linux vps (all seems to work well with remote debugging of site pages).

I do not get debugger functionality when the remote server receives a request from a second server! Allow me to explain.

Let's call the site that is working fine with PhpED and remote debugging Site A.

Site A also receives information from Site B (a sister site) that is also remote and running on a Linux vps.

I needed to set a break point on Site A in the php code that receives a http request from Site B. I would then go to Site B and cause it to send a http request to Site A where I was hoping the Site A server would stop at my breakpoint. This does not happen.

I can goto Site A and when changing pages etc I can get it to stop at any breakpoint that I set in SIte A, but when a http request is received by Site A from Site B the breakpoints set in Site A are ignored.

For almost a week now I have been trying everything, but without success.
I have the debugger installed on both servers Site A & Site B, although I only have one running at any one time. I have tried reversing the functionality to see if I can get Site B to stop at a breakpoint when it receives a http request from Site A.

I am now lost and would be grateful for any help in getting my debugger working as I outlined above (If what I am trying to do is at all possible!).

I did come across a webcast by Dimitri (I think) where he uses the debugger on 2 sites (client server setup). I suppose this is what I want, but I have tried running my Site B locally (and Site A), but just can not get the client server model working. There was a mention in the webcast of another webcast that would show how to set up a client server model for debugging of both, but at this time I can not find this second web cast.

Greatful for any help.
Jonathan

Is the DebugBreak() statement together with a parameter suitable for what you want to do?

For example, if your PhpED system is IP address 192.168.1.20 then on the web server you could use DebugBreak('1@192.168.1.20')

Bear in mind you may have some firewall settings and port forwarding to do, particularly if the web server is on the internet

Thanks for the response:
I'll be totally honest and say: I've never even heard of this DebugBreak() function! I've just had a quick skim through the documentation fro PhpED within the IDE's help section and there is no mention there either.

I suppose that my next question is: Where is the documentation regarding remote debugging, debugbreak function etc?

The only info I can find regarding remote debugging is related to installing the debugger on a remote server, something that I have done successfully based on the documentation. It's from this point on as in 'how to use the remote debugger' set breakpoints etc. I had just assumed that it was exactly the same as debugging on my local WAMP where I have never used such as DebugBreak().

Has anyone produced a book, tutorial etc and how to use the above? (hint for Mr NuSphere)

I will continue to research on these 'new to me' DebugBreak in the hope that I can develop a better understanding, any links etc would be greatly appreciated.

Thanks again
Jonathan

The built-in PhpED help is a little incomplete to say the least. I originally found DebugBreak() by typing Debug then ctrl+space to see what Debug commands were available.

DebugBreak is actually mentioned in various places on the NuSphere web site, but I do mean mentioned, it isn't as far as I am aware 'documented'.

http://www.nusphere.com/products/php_debugger_advanced.htm

A few notes on using DBG and DebugBreak:

* It is not an official PHP statement, so if you leave it in your code on a server without NuSphere DBG installed, your code might fail.
* Some coding standards disallow use of such statements, due to the possibility of them being accidentally left in the code after release. Using conditionals around such statements can make them much safer.
* Opinions vary on whether debuggers (eg NuSphere DBG) should even be present on a production server in a global configuration. I'm of the opinion they should not. Using something like PHP in suExec mode (PHPsuExec) or suPHP means that the site can have its own PHP process and php.ini, which could make it much safer and I would personally be much happier with.
* DebugBreak acts as a very forceful break including in situations where maybe PhpED breakpoints won't work. Such situations might include where cookies are not being transferred correctly, maybe due to use of Apache mod_rewrite.
* The optional parameter can be debug session information, which can tell NuSphere DBG which debugger client computer to connect to for debugging. PhpED and the PHP DBG Listener must be running on that computer.
* Without the parameter, DebugBreak will break back to the already connected PhpED.

When you start a normal debug session, you see the session information in the URL, which gives you some idea of the format but can have some variable bits:

409554143122900002@debugger-client-address;d=1,p=0,c=1

So that is the debug session id number followed by optional @debugger-client-address then optional semicolon and various options, such as p=0 or p=1 for the profiler.

In a normal debug session the debugger-client-address is normally not used as it defaults to the connected PhpED. Note that it can be an IP address, but from a session on a remote internet server (not on the same LAN) you must use a public IP address (the one from your ISP) and your router will probably have to port forward (normally 7869) to your client computer. Local IP addresses such as 192.168.1.x and 10.0.0.x will not be routed over internet (and in this forum I'm sure some people have indicated they tried that!)

DebugBreak takes essentially the same session parameter, although in the case of DebugBreak you might simplify it to just a session id and a debugger-client-address, plus the session id is not actually always critical unless you are running multiple sessions, so can often be specified as something like 1 to give you:



Another useful command that is under-documented is OutputDebugString(), with a single mention in the help for the Log tab, which is where I originally found it after deliberately searching for the existence of such a command. The help doesn't even say it is a PHP statement, plus it doesn't show with command completion and doesn't even turn blue in PhpED to show it's a valid statement.

The OutputDebugString('hello') command will output a string to the Log tab, complete with timestamp and without corrupting page display and most usefully before page headers are sent; can be quite handy. Probably should be used with the same safety considerations as for DebugBreak.

First off, Thank You very much for your time in helping me with this issue. You have provided a wealth of information that I will use as a start in my research of PhpED debugging (remote / local).
I will attempt to document my findings hoping that they will help others who follow.
I still believe that there is a need for a 'PhpED book' and as PhpED is a very popular IDE that many seem to have documentation issues with (see this forum) I am hopeful that it will not be long before someone takes up the challenge while at the same time potentially make themselves a few thousand dollars.

Once again. thanks
Jonathan

if you have control over server A requests, just add DBGSESSID into URL that server A sends to server B and place there point that server B would connect to.
If you're behind router, you may want to run ssh tunnel to the server B beforehand. In this case your DBGSESSID will be like below:
DBGSESSID=1@localhost
localhost is needed here in case of tunnel. Otherwise you'll need real IP address of your client HOST where you run PhpED.