Community
Participate
Working Groups
Created attachment 114360 [details] screenshot showing the mapping in question Build ID: M20080221-1800 Steps To Reproduce: I have the following configuration: some vhost definition: [...] DocumentRoot /some/where/over/the/rainbow/ [...] eclipse workspace /home/udo/wa/foo project location inside workspace barProject/src and finally a symlink from /home/udo/wa/foo/barProject/src to /some/where/over/the/rainbow/bar like below: % ls -l /some/where/over/the/rainbow/ lrwxrwxrwx 1 udo prog 39 2008-09-24 21:05 bar -> /home/udo/wa/foo/barProject/src/ Inside barProject/src there is on file named "test.php", so that a valid URL on the vhost would be: http://barVhost/bar/test.php Now I have configured Xdebug to debug scripts on the vhost, with the following URL mapping (see also the attached screenshot): Server /bar => Workspace barProject/src When I finally right click on test.php and choose "Debug As => PHP Web Page" a completely wrong URL is suggested, despite the mapping configuration: http://barVhost/barProject/src/test.php This is quite annoying if you have to debug many individual scripts (like I have). More information:
The Path Mapper does not map between URL and local resources. It maps from local file name to remote file name, which is not a part of URL. For example: /barProject/src is mapped to /var/www/bar, but /var/www/bar has nothing to do with URL.
Hmm, so it is a pretty useless feature then? How would I use it in a reasonable way (I honestly can't think of a way do so)?
There's a help page in PDT called "Path Mapping". Please read it. Thanks! (In reply to comment #2) > Hmm, so it is a pretty useless feature then? > > How would I use it in a reasonable way (I honestly can't think of a way do so)? >
well, I already RTFM :-) So I am reopening the case and changing the severity to "enhancement". It just would be nice to have an URL<->FS mapping feature.
I don't think that the solution 530834 does fit this issue. The solution layed out in 530834 is about handling SWT.OpenUrl events that come in from the operating system
Xdebug Exception prints produce in browser links like "xdebug://file_path:line_num", If user click in browser I'll be able to handle it, so I think bug is correct.
(In reply to Dawid Pakula from comment #6) > Xdebug Exception prints produce in browser links like > "xdebug://file_path:line_num", If user click in browser I'll be able to > handle it, so I think bug is correct. OK. That sounds reasonable.
so the uri scheme handler extension point and the operating system registration via the preference page was merged today. So you could start to implement a handler for your use-case
Just a short heads-up. The uriSchemeHandler extension point is part of eclipse platform 4.10 (2018-12 SimRel). Any new on this bug? You could not consume the extension point and add handling of xdebug:// URLs.
New Gerrit change created: https://git.eclipse.org/r/155200
Gerrit change https://git.eclipse.org/r/155200 was merged to [master]. Commit: http://git.eclipse.org/c/pdt/org.eclipse.pdt.git/commit/?id=1fe8ce5428540c3c55a3a7d6b5286666d78268b0
Now (after over 11 years) PDT support: xdebug.file_link_format=xdebug://%f@%l and: xdebug.file_link_format=xdebug://%f:%l
