NuSphere Forums Forum Index
NuSphere Forums
Reply to topic
SRV php.ini location


Joined: 03 Mar 2004
Posts: 40
Reply with quote
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
View user's profileFind all posts by jonphippsSend private message
Site Admin

Joined: 13 Jul 2003
Posts: 8334
Reply with quote
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 Smile
php.ini from its name is a php stuff and php should care Smile
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().

_________________
The PHP IDE team
View user's profileFind all posts by dmitriSend private messageVisit poster's website


Joined: 03 Mar 2004
Posts: 40
Reply with quote
dmitri wrote:
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 Smile
php.ini from its name is a php stuff and php should care Smile
Hence the way it works:
SRV knows where to run php and php knows where to find php.ini.

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...
Quote:
php.ini is searched in these locations (in order):
* SAPI module specific location (PHPIniDir directive in Apache 2, -c command line option in CGI and CLI, php_ini parameter in NSAPI, PHP_INI_PATH environment variable in THTTPD)
* The PHPRC environment variable. Before PHP 5.2.0 this was checked after the registry key mentioned below.
* As of PHP 5.2.0, the following registry locations are searched in order: HKEY_LOCAL_MACHINE\SOFTWARE\PHP\x.y.z\IniFilePath, HKEY_LOCAL_MACHINE\SOFTWARE\PHP\x.y\IniFilePath and HKEY_LOCAL_MACHINE\SOFTWARE\PHP\x\IniFilePath, where x, y and z mean the PHP major, minor and release versions.
* HKEY_LOCAL_MACHINE\SOFTWARE\PHP\IniFilePath (Windows Registry location)
* Current working directory (except CLI)
* The web server's directory (for SAPI modules), or directory of PHP (otherwise in Windows)
* Windows directory (C:\windows or C:\winnt) (for Windows), or --with-config-file-path compile time option

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
View user's profileFind all posts by jonphippsSend private message
Site Admin

Joined: 13 Jul 2003
Posts: 8334
Reply with quote
What I said is entirely true Smile
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.

_________________
The PHP IDE team
View user's profileFind all posts by dmitriSend private messageVisit poster's website


Joined: 03 Mar 2004
Posts: 40
Reply with quote
dmitri wrote:
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.
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. Smile

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? Smile

dmitri wrote:
Have a copy of php.ini in php's process current directory and it will work the best.
I agree.
View user's profileFind all posts by jonphippsSend private message
Site Admin

Joined: 13 Jul 2003
Posts: 8334
Reply with quote
Quote:
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?

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

Quote:
Wouldn't something like this also be useful to SRV, given the number of different ways there are to "screw up the system"?

Isn't it sufficient to have php.ini in php's directory? Just remove PHPRC and remove registry entries Smile
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 Smile or implicit like php.ini in current process directory.

_________________
The PHP IDE team
View user's profileFind all posts by dmitriSend private messageVisit poster's website


Joined: 03 Mar 2004
Posts: 40
Reply with quote
dmitri wrote:
Wouldn't something like this also be useful to SRV, given the number of different ways there are to "screw up the system"?
Isn't it sufficient to have php.ini in php's directory? Just remove PHPRC and remove registry entries Smile

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

Thanks for your help with this!
View user's profileFind all posts by jonphippsSend private message
SRV php.ini location
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
All times are GMT - 5 Hours  
Page 1 of 1  

  
  
 Reply to topic