As a long time user of PhpED, I'm now using PhpStorm - and find it to be a super product
But - after 6 months - I'm still not able to have the debugger up and running - and of that reason - I'm still using the php debugger in phpED.
But running two frameworks like this is silly.
Here is the setting:
Working from windows 7 – and using cvs (ssh) module in PhpStorm to access source code on the remote server.
The server is a linux server – running apache.
Development etc – using the cvs is working perfect.
But – to be able to debug – sett breakpoints etc – I have the PhpED – using WebDrive (also using ssh) – keeping a “local” folder for PhpEd to work from.
I was able to see the PhpStorm debugger in action – when I test run the PhpStorm – using the same WebDrive folder – and a ssh tunnel from the server to my pc.
BTW: I have a script running on the server – getting all “new” code from cvs and deploy into the debug server automatically for me!
So after committing via cvs module in PhpStorm - the server sees the new code and auto deploys to the test web server.
But – I would like to use only the cvs (via ssh) –and not WebDrive – and be able to use the debugger functionality in PhpStorm ?
Is this possible??
I also needs to be able to start debugger from php using something similar to PhpEd’s : “DebugBreak('1@localhost');”
There I'm using the debugger in FF and Illuminations.
Thank you for your help.
Well - after reading my own message - and looking into what's coming for v6 - I found a page giving me a hint on how to remotely debug javascrips.
And yes - it's now working
Now it's only how to enable remote debug of my php files - when I don't have a direct access to them - only using the cvs module in PhpStorm ?
I mean that I normally don't have a local folder mirroring the folders on the server on my pc.
I only use the cvs module (in PhpStorm) to transfer php/files modules to/from the server from the editor.
Sed that - I could use the same folder as I'm using today from PhpED.
This folder (mapped into local drive) dos mirror the folderstructure on the server - using WebDrive.
I hopen to get rid of this WebDrive mapped drive, but if only solution - i will continue to us it.
But I don't want to use this to edit files on the server - as they will be overwritten by others also using cvs.
I do have a script that automaticly updates this folders on the server - from cvs - when something is changed in cvs repository.
Debugging from PhpED is using this mapped local drive as a repository - used only for debugging - not editing.
So - the question is maybee - could PhpStorm use cvs for editing files (using update/commit) and local drive mapped by WebDrive - for only debugging?
Yes - there is a copy of the files on my local drive - as a buffer for the cvs - sure
but I can not run the scripts from there - they have to be on the server ..
To many dependables - like database etc etc.
Did I mentioned anywhere about runing them? I assume you do not know how remote debugging works (in general, not PHP only).
Original file is required so the IDE can show you what line is currently debugged; so it can "navigate" to next line; "jump over" function call; so you can control where to put breakpoints etc etc. Everything gets executed on the server; nothing runs locally in case of remote debug.
If you have problems with settings this up -- you will need to provide some more information, like: that remote server -- is it on LAN or on Internet; is debugger engine (xdebug/zend debugger) properly configured on server etc etc.
Thank you for coming back to me !
Well - I now have everything working - by using the locally mapped drive for debugging.
In "Run/Debug Configuration" - "PHPUnit on Server" -> Server: I hade to make a "server" that under "Upload/download project files" was sett to the localy mapped drive to the folder on server. ??
I could probably use a sftp type server - and not the "Local or mounted folder" type as the one I'm now using ??
Settings -> PHP -> Servers Host is set to localhost, port to 9000 and Debugger = Xdebug
Made a ssh tunnel on port 9000 to localhost from/to server
In Run/Debug Configurations:
Made a new setting under "PHPUnit on Server"
and there using the Servers configured above under the Remote tab - and the local cvs cache directory in Configuration tab - Directory.
Then installed the Xdebug plugin to Firefox - and sett up the Xdebuger on the server.
I'm now able to sett a Breakpoint in the editor - and the debugger is working - nicely
But - enabling the Xdebuger is slowing down the whole server ?
The apache is running some 50 VirtualHosts - and ALL of them are slower by 10 times - even when nothing is in debug modus .
xdebug.remote_enable = 1
xdebug.remote_host = "127.0.0.1"
xdebug.remote_port = 9000
xdebug.idekey = "PHPSTORM"
Is this right - do Xdebug really slow down the whole server that mutch ?
I therefore needed to disable the Xdebuger again - and enable the debugger from PhpEd again - as that one is not slowing down the server.
Tried to enable the Xedebugger from .htaccess only for this test virtualHost by :
php_value zend_extension "/usr/lib/php5/20090626/xdebug.so"
php_flag xdebug.remote_enable on
php_value xdebug.remote_port 9000
php_value xdebug.idekey PHPSTORM
php_value xdebug.remote_handler dbgp
php_value xdebug.remote_host "127.0.0.1"
But that is not working.
I not hade time to really dig into why, but it could the ssh tunneling - that is not really working when the server is not listening on the port 9000 the whole time.
Cannot comment much on this -- never debugged on busy/production server this way + never worked via ssh/xdebug proxy -- always on test server and always directly.
Therefore: the only real idea that I have right now -- make sure that xdebug.remote_autostart = 0, otherwise xdebug will try to debug every single request. You may also try to get rid of xdebug.idekey -- should work without it (it should be passed via cookie from browser extension)
Thank you again!
Well the server is only a developer/test server, but bussy :-)
The debug.remote_autostart = 0 is a interesting one - will look into that one !!!
Again - thank you for all your help - and will continue testing tomorrow