I am using WAMP with Windows 7 on my local PC for testing, and always seem to have an issue with rewrites in PhpED

An example is where part of htaccess is
RewriteEngine On
RewriteRule ^(.*) /en/details.php?C=$1

If I go to Tools - Open URL - and enter http://site/en with "Run Debug session" and "debug sessions" checked, I get a popup "Waiting for debug session", and after a few seconds "Failed to start a debug session" appears, suggesting that you may not have installed the debugger module. But if I call a page that does not require rewriting, it debugs fine.

The page loads if I uncheck the two debug checkboxes.

Can someone give me a clue as to where to find a way to get the debugger to load under these circumstances - or does it just debug in these circumstances?

I doubt it is a debugger issue. Most of the sites that I work with use rewrites.

Is your rewrite rule complete? For example, do you need to specify it is the Last rewrite rule to be obeyed?



EDIT: Previously I had a bold attribute over the [L] but in code mode it was showing incorrectly so removed it.

I understood your L option, and tried it.

It didn't work.

I deleted the L option, so that the htaccess was the same as before.

It started to work!

It worked for everything that I threw at it.

Today, I come to it, and it isn't working again. With or without the L.

I had one setup for another client where:
I visit a page, and it doesn't work.
I then visit the home page. It works.
Then I re-visit the first page, and it works.
Without any code change, and using the same command (tools - open URL)

So, now I am even more confused...

Probably your rewrite rule sends the user to another web where debugger is not installed. Also it's possible that your rewrting rule strips off DBGSESSID from the URL which also may cause debugger failing to start.
Regarding [L] option, I doubt it's alone the origin for the problem. It may stop the other (matching) rules from triggering and that's the only thing it does.

Thank you for your suggestions, Dmitri.

I know that it doesn't go to another site, because it loads the page without the debugger in the IDE, and loads it in an external browser, and I had checked that.

However, the DBGSESSID suggestion seems very promising, as it could explain why it seems to continue to run after one page has worked. I will look into this.

I am also considering creating a simple page that sets this as a SESSION, which may allow the IDE to continue. May not work, but it will be a simple answer.

I'd suggest you to install LiveHeaders and/or HTTPWatch utility. It shows headers and URLs requested by the browser and make debugging web sites much easier -- you'll see what browser requested, what respond was given, etc.

Regarding "another site" term -- I hope you understand that for example aaa.yourdomain.com is not the same site as yourdomain.com or bbb.yourdomain.com although they all may run on the same machine. Similarly http://yourdomain.com is not the same site as https://yourdomain.com, although they may share the same htdocs. Finally http://yourdomain.com is not the same as http://yourdomain.com:8080/ because they use different ports.

As of SESSION, I'm not sure what you mean. If you mean $_SESSION, I have to say that DBGSESSID has absolutely no relations to php sessions.

Again, thank you for your suggestions. I will look into them.

And yes, I was wondering if there were any relationship between $_SESSION and DBGSESSID - it was just a wild idea to investigate, that is obviously not going to work.