php.ini - proper location?

[belgarius]

I've a bit of a problem my PHP installation that I've been unable to resolve, and thought that perhaps someone here could shed a bit of light on it.

I'm running under WIn 98SE, using OmniHTTPd Pro 2.09, and PHP 4.1.1. Both Omni and PHP reside on my E drive, with Omni being in the /httpd folder, and PHP being installed into /httpd/php. The php.ini file also resides in this folder as well. Here's the problem. If I leave the ini file in it's present location, PHP appears to work, however, the mail functions do not. I checked with phpinfo, and found that it indicates the path to the ini file is in c:\winnt, and this folder doesn't even exist on my system, and further, the sendmail from shows no value, and SMTP shows localhost. (I've set these values to my email address, and dfxwebs.com, respectively, in the ini file)
Here's where it gets perplexing. If I place a copy of php.ini into the Windows folder (C:\Windows), phpinfo shows me the correct path, sendmail from, and SMTP settings, however, PHP stops working on the pages that incorporate it, and return text errors instead, which makes for unhappy users, and extreme hairloss for your's truly.
What I think is happening, is that when the file resides in the installation directory, it is not being read, and PHP is running under the defaults. When I place it where the docs say it should reside, it is being read, hence the proper settings showing in phpinfo, however, it looks to me as if it no longer knows where to find what it needs to function.
I suppose the question would be this. Is it possible to change the settings in the ini file so that it will load from C:\Windows as it is supposed to, but know that PHP actually resides in E:\httpd\php ?
If so, please enlighten me as to what I have overlooked on this end, while I still have a few shreds of my hair/sanity intact.

Thanks much!

Belgarius

[sayoko]

Well, php.ini usually either belongs to windows or winnt so thats right.
What did you enter for sendmail? On Windows there usually isn´t sendmail installed, so you can enter a smtp host.
Thats what I did, entered the smtphost of my company e.g. smtp.company. de. Works fine, messages get sent.
I have to admit though, I´m using Apache as Webserver.

[belgarius]

If I place the file into the \Windows folder, it shows the correct information regarding sendmail from, which I have set to [e-mail], and SMTP, which is set to dfxwebs.com, and it also indicates that the path to php.ini is c:\windows, which is correct. The problem is, with the ini file in place in the Windows directory, as far as the server is concerned, PHP ceases to work for those users with php pages.
Once I remove the ini file from the Windows directory, and rely on the one contained in e:\httpd\php, the server once more begins to handle php pages with no problems, however, the phpinfo page then indicates c:\winnt as the path, and sendmail from becomes "no value" and SMTP reverts back to "localhost", and the mail functions do not work. I think that what I need to set here, is something in the ini file, that will allow it to be placed in the Windows folder, where it does need to be, but make it see that php is in fact, installed on a different drive.
I don't know if this has any bearing on things, but I installed PHP to c:\php, and made the changes to the server globals to tell it to look there for php.exe, and while the phpinfo was correct, PHP was not functional until I removed the ini, and set the server globals back to look for php.exe in e:\httpd\php
As an aside, I've installed Apache 1.3.23 here as well, and while PHP works well with it, the SSI's flatly refuse to work outside any directory except the first virtualhost container, which is my "main" server.

Belgarius

[Anon]

One of my systems is win2k/IIS5.

I put my php.ini file inside my C:\Windows\System directory. Also make sure your mail parameter in the php.ini file is set to you smtp server.

After making any changes to your php.ini file , you must reboot the entire system.

hope this helps.
-mike

[sayoko]

The fact that no smtp shows up when you place php.ini into the httpd folder, indicates that its not parsed at all.
When you place it into windows it is parsed but there are errory obviously.
Maybe someone can help you out with it, maybe mail() doesn´t even work with your server. Sorry there.

[belgarius]

This is apparently what is happening, yes, since with the ini file in the E:/httpd/php folder, the settings in the ini file are replaced by the defaults, and when it is in the C:/windows folder, the settings are shown as being correct, as far as what I have entered into the ini file. The problem seemingly lies in that once the ini file is parsed, PHP no longer works. What I need to figure out, is what I am overlooking. Here are a couple of other things that may or may not have any bearing on the problem. One, I have not removed the php.ini file from the folder on the E drive, just copied it into the windows folder on the C drive, and secondly, would I need to set doc_root to show the server root, which in my case is the E drive? Also, even though I don't have any uncommented, should I also change the extension_dir from ./ to E:/httpd/php/extensions?
As an aside, I know of others using the same server package and PHP version as I am, and the mail functions work fine. The main difference is that these individuals have everything installed on the C drive.

Thanks for your time and ideas,

Belgarius

Belgarius

[belgarius]

Going by what the docs recommend, I chose C:\Windows, and at least the ini file is parsed from there, or so phpinfo would seem to indicate, as the settings I made are shown in place with the ini file placed where it is supposed to be.

Here's my settings for sendmail:

[mail function]
; For Win32 only.
SMTP = dfxwebs.com
; For Win32 only.
sendmail_from = [e-mail]
; For Unix only. You may supply arguments as well (default: 'sendmail -t -i').
;sendmail_path =

I run my own mail server, and use simply dfxwebs.com as it's address; this hasn't presented any problems in the past. And, I know of others who run the same software as I am, that are not having problems with the mail functions working, but they are running everything on the C drive. I've found with experience that these types of problems are more often than not caused by overlooking something simple, and am hoping this is the case here as well. It looks like PHP is unable to find the components needed to work properly once the ini file is in place, and being parsed.

Thanks much for the time and input,

Belgarius

[sayoko]

Lets see. On Apache I have my template ini file lying around without being affected.
Just in case, rename that file on e: so you have only one ini file on your system.
Regarding ./ as extension dir, I recommend you set it to a valid directory, in your case I think c:\php\extensions

I looked at the other post of yours,
SMTP = dfxwebs.com

Does this host really exist? The usual setting for a smpt host is something like smtp.dfxwebs.com, maybe thats a reason why it doesn´t work

[belgarius]

I'll give renaming the template a try, as well as defining the path to the extensions. Since the actual php install is on the E drive, I'd have to use that path. Would setting doc_root have any bearing, since the user files are contained on the E drive as well?

Yes, actually, dfxwebs.com is a valid host name, and is set as my MX record. I've never seen any reason to add the prefixes, since the mail server has never been a source of trouble. I use Mercury/32 3.12, and only wish all my apps were as well-behaved. I can just as easily add an MX record as not, and it would serve to eliminate the host name as a possible problem.

Not intending to start anything, but I am also giving a great deal of thought to my present OS as well. Win32 seems lacking in ways for personal server work, let alone hosting other users as well.

Many thanks to all for both time and patience,

Belgarius

[sayoko]

Lets see, doc_root. I found this at php.net:
If you are using OmniHTTPd, do not follow the next step. Set the 'doc_root' to point to your webservers document_root. For example: c:\apache\htdocs or c:\webroot
So you can leave that as is

This
http://www.php.net/manual/en/install.omnihttpd.php

and this
http://www.php.net/manual/en/install.windows.php
might be interesting too.

[belgarius]

The section on Omni is also contained in the install.txt file, and now that you remind me, is the reason I hadn't edited the ini file. I chose the recommended ini file, and added only the sendmail from, and SMTP information, and never gave it a second thought, it apparently worked, and there were no user complaints. Now, that I've been looking into why the mail functions do not work, the questions arise. As far as the installation of PHP and Omni goes, that's been working, and is "by the book", more or less.
This brings me to the second mentioned, being the installation method. Since I had originally installed PHP as a part of Omni, I opted to install the update in the same manner. I'd honestly not even read the docs, just trusted the install, and gotten away with it since at least the time of 4.04pl1, which was what Omni installed the first time. This was done with the archive file, not the msi installer.
The thing that keeps nagging at me is this. With the ini file being parsed, as is evidenced by phpinfo, the path to php.ini is correct, and the sendmail from and SMTP setting reflect those I have set. As far as PHP works at this point, the users that have it as a part of their sites, see error texts loaded on their pages, instead of the intended output. If I remove the file from the "system" folder, phpinfo returns what indicates that the php.ini file isn't being parsed, by showing a non-existent system folder as the path to the ini file loaded, and, not showing the settings for sendmail from and SMTP. However, in this instance, PHP functions. If it is allowed to run from what I take to be a "default" setting.
I'm by no means a programmer, or code whizz, but this looks to me as if for whatever reason I've overlooked, or set incorrectly, if the system parses the ini file, PHP no longer knows where it's head is at, so there's the problem, somewhere. On the other hand, if it loads and runs without loading the ini, the user errors are gone, but so are the mail options. What I am missing here seems to be a method where I can assure the ini file knows that while it is being loaded from C:\Windows\, what is expected to happen requires that the executable be looked for on an alternate drive and folder name, in my case, E:\httpd\php\ and points there from. As far as the server software is concerned, it already knows the exact path. This is set as a part of the global settings in Omni. A corresponding MIME type has been set as well, one for each expected extension, so the server knows which extensions to send where for processing.

Again with much thanks and appreciation,

Belgarius

[sayoko]

In Apache you tell in the configuration file where to look for the php.exe or the servermodule dll. The only thing you tell in php.ini, is where to find the extensions, where session variables go and whether php should be locked down to one directory only.
I can remember a include path section in php ini. Maybe try enter there the paths you use.

[belgarius]

Here's the strangest part of all this. I also have a copy of Apache 1.3.23 installed, and have no problems whatsoever with PHP under it, it reads the ini file, in the e:\httpd\php folder, and works fine without having the ini in the \windows folder. Why am I not using Apache, you may ask? Simply because I have been unable to get it to parse SSI for any virtualhost outside of the first one entered.

I'm beginning to think that sending for a qualified priest to perform an exorcism might be my next step. ;o)

Belgarius

[Anon]

This should tell you you should use Apache 🙂 At least you don´t use IIS 😉
Yeah well, did you ever try running everything in one directory? Though I don´t know how that would help.

[belgarius]

Chuckle...

As a matter of fact, I'm in the process of changing over to Apache, now that I've gotten the SSI hangups worked out. I can't say conclusively that Omni has been at fault, but the evidence points in that direction, especially since the same settings that do NOT work under it, work seemingly perfect under Apache. My ini file presently is residing in the \php folder, and Apache has no problem in parsing it, and returning the proper values in phpinfo. That's sufficient proof enough for me. ;o)

A plethora of thanks to all for the invaluable time and assistance!

Belgarius

[sayoko]

Your are welcome 🙂