How does the SRV server know which php.ini to use?

I have Apache running on port 80 and it has xdebug enabled. I have the SRV server (Build 5020) running on 8080 with dbg enabled. They're also running different versions of PHP.

If I run http://localhost:80/phpinfo.php I get the Apache version of PHP (5.2.0), and the Configuration File Path is "C:\PHP\php.ini"
If I run http://localhost:8080/phpinfo.php I get the PhpEd version of PHP (5.2.1), but the Configuration File Path is still "C:\PHP\php.ini"

The problem... I can't run dbg in SRV unless I change the configuration for Apache too.

I tried copying the nusphere php.ini into the same folder as the SRV server, but this had no effect.

This seems like a new problem, but it's been a while since I used this exact config and I may have changed other things (like environment values or my video driver) in the interim.

Is there a way to explicitly tell SRV to use C:\Program Files\nusphere\phped\php5\php.ini?

Thanks,
Jon

SRV does never care if there is a single copy of php.ini somewhere in the world or not. It's just not what it is supposed to care of
php.ini from its name is a php stuff and php should care
Hence the way it works:
SRV knows where to run php and php knows where to find php.ini.
You may want to check with php manual or just work with php.ini located in php (php5) subdirectory in c:\program files\nusphere\phped
To make sure what particular php.ini is used you need to run phpinfo().

This isn't entirely true. The location of php.ini is determined by a number of different factors.

From the PHP manual at http://www.php.net/ini...

Note the very first entry -- "SAPI module specific location (PHPIniDir directive in Apache 2...)". I guess that I assumed that the SRV server would have a similar directive.

I'm also going to guess that the location of the php.ini that the nusphere php found (currently wrong) indeed changed when PhpEd started shipping with PHP 5.2.x, since the order of locations searched changed with that version.

I'm going to go tinker with my environment variables and registry settings and see if I can't get the Nusphere copy of PHP to find it's local copy of php.ini. It's fortunate that my Apache/PHP and SRV/PHP aren't the same versions and I can modify the registry to associate a php.ini with a specific php version. I believe that the new PHP Windows installer makes some of these changes to the registry too.

It might be worthwhile to provide a way for the SRV server to explicitly direct php to the correct php.ini location in some way, since with more than one php on a windows system the Nusphere php is currently unlikely to use the php.ini that's located in the Nusphere directory. Especially given that it's sometimes useful to have different debuggers loaded in different PHPs for various purposes.

Maybe compiling PHP with the "--with-config-file-path" compile time option pointing to the Nusphere PHP folder would do it too.

--Jon

What I said is entirely true
SRV has no relation to php at all, just like Apache or any other software that do no bind itself to php directly.
SRV may run a CGI executable for handling certain file types according to configuration.
How this CGI executable works and if it works at all does not matter for SRV, that's what I meant. Hope I made it clear enough.

Regarding php and how it finds its php.ini, you're correct and there are some different ways to screw up the system.
Instead of the ways "allowed" per manual, I'd recommend not to use any one of them. In other words, do not use PHPRC, do not use registry.
Have a copy of php.ini in php's process current directory and it will work the best.

I (obviously) have no idea how Apache interacts with PHP and apologize for suggesting that what you said might not be 'true' or even correct -- I'm clearly in no position to make that kind of judgment.

So please help me understand...
The PHPIniDir directive in Apache 2 is passed through to PHP in some way by Apache when it invokes the SAPI module, even though it's not bound directly?
Wouldn't something like this also be useful to SRV, given the number of different ways there are to "screw up the system"?
Should I make a feature request?

I agree.

Apache provides a way for its modules to read configuration.
php5apache reads and validates this PHPIniDir.


Isn't it sufficient to have php.ini in php's directory? Just remove PHPRC and remove registry entries
With SRV + php.exe, it's not clear how to pass php.ini path to php.exe. There are no other ways but still those PHPRC and path in the registry or implicit like php.ini in current process directory.

Yep! I was just fishing for something I could 'set and forget'.

Thanks for your help with this!