I have just bought 4.6.2 (4632), and I have a problem debugging with the internal SRV. Well, if I set the SRV Port to 80, I can debug perfectly. Everything works just fine. If I leave the Port set to the default of 8080, it does not work. It is prettyu easy to see why, but perhaps someone can tell me why this should be a probem (or is it a bug?)

When I start the debugger, the first page cvomes up ok as something like

http://localhost:8080/file:/C:/apache2triad/htdocs/Securedoc.com.au/catalog/index.php?DBGSESSID=-1

No problems - just what you should see and this works just fine.

Now click on a link on that page - what comes up is the next page, but this is the URL

http://localhost/securedoc.com.au/catalog/login.php?osCsid=19288dcb3ebf87ad37eee540612066db

Notice that the Port has dropped off. The file cannot be found - and indeed you will get a "problem loading page" error.

If I manually edit the URL to include the port, then it works. And indeed I did some debugging quite successfully like this until I realised I could simpy change the SRV port to 80. The problem is that I have an Apache server on 80, so I have to shut it down.

It would be good if I can somehow work out why the port is being dropped from the URL and allow the use of 8080. Any ideas?

Hi there - I just saw your post and connected it with your message on contact_us.
Without going into the problem of losing the port, I will at this moment repeat pretty much what I wrote in respone to your message: my recommendation is to debug with Apache since you have it running on the same machine and that's where you scripts are going to be deployed really. You need to set the Run Mode to 3-rd party webserver and map your project root to remote document root. Our FAQ has an extensive post on Project mappings btw:
howto-set-project-mapping-t2135.html

Many Thanks!

Not so. They are two different issues. The direct email you mention was concerning the 3rd Party server, which I cannot get going. That is my preferred choice, as you suggest, and I will pursue it as I get time.

In the meantime, I tried the internal Server and I eventually got it to work (as per my post above). It was a very frustrating exercise, as I suspect it is for many people that try to get debugging to work with PHP.

Just as some positive feedback for NuSphere. I had to debug about a dozen lines of PHP code. That is all. I am actually a Delphi programmer, and only do PHP quite rarely. I spent about a week trying to get all number of editors to work (EnginSite, Zend, PHP Expert , ActiveState), and NuSphere was the only one that looked like working. ActiveState was fairly close, as was EnginSite. NuSphere finally came through, although only with the internal web server - but that was enough to allow me to finish my project. And I have to say that support has been very good.

Obviously, the link is malformed. If it's generated by your application (script), please check if this script is aware of non-default ports. For example http://somehostname/ means port 80 (default), https://somehostname/ means port 443 (default for SSL), http://somehost:NN/ neans port NN.

BTW, in 99.9% cases you do not need to aware your hostname and port. If you need http://somehost/somedir/somepage.php, it's sufficient to have "/somedir/somepage.php" in the URL and omit protocol, hostname and port. They will be taken from the URL, with which current page is requested. Hope it's clear.

Yes - I understand that port 80 is used by default. I was just assuming that because you set the internal server to 8080 by default, that you had worked out some way of actually using that port. There is no way that I am going to edit my application to use another port - it is bad enough having two configuration files for local and remote MySQL database setups.

It is not a problem - I simply set the local server to 80 and everything works just fine.

BTW - I eventualy got the 3rd Party Server to work as well - I am not sure how exactly, but I am now using that just fine.

Eventually there were no problems with SRV from the beginning.
If your application puts an URL to the output HTML, it's the application's responsibility for correctness.
To me it looks like that your application is hardcoded to port 80 and therefore you need a web running on this port

No, of course not. Who would hardwire links to port 80 on a hosted system? But anyway, this was not done. Most of my internal webpage links are of the form "/somepage.php". This puts the URL at the Document Root - and is of course portable between my local test system and the destination. Unless of course the server is on a port OTHER than the default 80. Well, at least I assume that this is the case, and that was the thrust of my original post.