[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Newsgroup Home]
[news.eclipse.tools.pdt] Re: PDT / Xdebug / Multiple sub domains

Hi Shawn, a good bit of detective work there. You may want to see what the author of xdebug thinks. Suggest you go over to http://www.xdebug.org which should give details on the xdebug mailing list as well as how to raise bugs and feature requests for xdebug.

Would be great as well if you could report back on how you got on with the xdebug firefox extension.

Regards
Dave Kelsey

Shawn Clark wrote:
Just tested and it is indeed a problem with the cookie. Within my application I have some site wide cookies setup so that the host is .domain.com where the first . is to signify all sub-domains. What I did was edit my XDEBUG_SESSION cookie once it was created to add the . in the front and now I can debug all sub-domains.

So my question now is can one or the other of the following be made available:

- Can a flag be set within the Xdebug php.ini settings to allow a wild card sub-domain cookie instead of the domain itself
- Can a URL argument be passed along with the XDEBUG_SESSION_START to state that it is for all sub-domains
- With this option a setting would need to be added to the Xdebug server configuration within PDT to tell which PHP server configurations can pass that argument


If time is of concern then I can look at making the change to PDT if someone is able to help with the Xdebug side of things. I did notice there is a Firefox add-on to enable Xdebug for a specific page. I am going to look at extending that add-on to do multiple sub-domains as well as an interim solution.

--
Shawn Clark


Shawn Clark wrote:
Ah... that is sort of what I was thinking but it wasn't working and now I think I understand exactly what the problem is and it isn't so much a problem with PDT as it is with Xdebug.

When Eclipse loads the URL in the server configuration for the debug session it passes along the information which Xdebug then puts into a session cookie for the browser. The thing I am guessing is happening is that the cookie is only for the current domain and not any sub-domain of that domain. So when I am going to a sub-domain the cookie isn't being passed to Xdebug and as such Xdebug isn't relaying the absolute path information to the IDE.

I am going to test now and will see if that is the case. I will just watch where Xdebug tells the browser to assign the cookie. I am guessing it is just for the main domain that is for the URL that is set in Eclipse.

--
Shawn Clark

Dave wrote:
Hi Shawn, I am not sure I fully understand the problem. The xdebug implementation doesn't make use of urls for path mapping. The only time the url is used is when you launch the debugger for the first time. This then invokes that url and turns on the xdebug cookie so that the browser is then in debug mode. All interaction between xdebug running in the web server and PDT is done by absolute file name and this is what the path mapper uses. So you map the absolute path in the web server to your workspace path in PDT.

When you set a breakpoint in PDT, it can translate that to the correct absolute path in your server and define the correct breakpoint in the server. So if it is all the same code then that breakpoint will fire and PDT will break.

PDT autogenerates a path mapping based on the file you specify in the web script launch and the file that gets executed when the url is invoked. You can of course create your own path mappings when you define the server.

I hope this explanation helps.

Dave Kelsey


Shawn Clark wrote:
Hi,

I am wondering if it is possible to setup a PDT debug session to respond to multiple sub domains?

I am working with an application that has ServerAlias' within a virtual host such that any number of sub domains call the same code so if I setup a breakpoint on a line of code it should break on any of the sub domains.

Currently it doesn't look like it is possible due to the fact the the PHP Server configuration has a URL like http://domain.com/. What I would be looking for is something like http://*.domain.com/. Then in the path mapping it would just be one entry.

--
Shawn Clark