Jump to content

Win 7 Installation Can't Find php.ini file


Recommended Posts

I am using Apache 2.2/PHP 5.3.3/MySql 5.1 to do web site development on my local PC. Previously I had installed this combination on a Windows XP machine. I recently bought a new PC with Windows 7 on it. I've downloaded and installed the above packages and have configured them. Apache works. PHP works. MySql works. What doesn't work, however: PHP is not finding the php.ini file.

 

When I run phpinfo(), it tells me:

 

-- Configuration File (php.ini) Path - C:\Windows

-- Loaded Configuration File - (none)

 

Of course, my php.ini file is in C:\PHP, NOT in C:\Windows. I've been tearing my hair out for several hours over this and have so far set up or verified the following:

 

-- My PATH system environment variable contains both C:\PHP\ and C:\PHP\ext\

-- My PHPRC system environment variable contains C:\PHP\

-- My Apache httpd.conf file contains the following lines:

    PHPIniDir "C:/PHP/"

    LoadModule php5_module "C:/PHP/php5apache2_2.dll"

-- I have set up a registry key HKEY_LOCAL_MACHINE\SOFTWARE\PHP\5.3\IniFilePath = C:\PHP\

 

And yes, I've restarted Apache or rebooted the PC multiple times in conjunction with making sure all this was correct I'm a bit unsure if there might be other registry keys that could help. However, so far NOTHING has worked. PHP stubbornly refuses to look anywhere but C:\Windows for the php.ini file. Moreover, even if I copy it into that location, it STILL doesn't load anything.

 

I'm at a loss. I suppose there could be something with Win7 security going on. Any ideas you might offer would be greatly appreciated. Thanks!

 

 

Sorry I can't help, so maybe someone can help both of us.  I am in the very same situation and have spent a similar number of frustrating hours trying to figure this out on my own. 

 

I have uninstalled and reinstalled both Apache (2.2.17) and PHP (5.3.3) multiple times (with the firewall turned off).  Registry settings of c:\php\ or c:\php for PHP as well as PHPRC system environment variables also seem to be ignored.

 

Anybody out there who might have a suggestion for both of us?

Any chance you edited the php.ini using a Windows application and it ended up saved as php.ini.txt but you cannot see the actual .txt extension because it is hidden by default?

 

I don't think so. I did edit it in Notepad, but I was trying to be very careful about that. Still, I'll double-check it to be sure. Thanks.

I did not mention it in my original post, but I made doubly sure doing one of my many re-installations that everything was saved in the original format and not as a .txt file.  That does not seems to be the problem.

 

lehket,

 

I am thinking the same thing as you re: this being an Apache issue.  I am wondering if there is a parameter set in the  httpd.conf file that is currently preventing redirecting to c:\php.  Within the httpd.conf file I can, for example, successfully change where it looks for my website by revising Dcoument Root to point somewhere other than c:htdocs.

 

 

 

Finally!!!  While I thought I had copied and correctly renamed the "php.ini-development" to "php.ini",  it was really saved and renamed  as "php.ini.ini-development".  I did not catch this immediately because I had the "Hide extensions for known File Types" still checked in the Windows 7 View Folder advanced options section.  So, all I kept seeing was php.ini and not the full file name as it was really saved. (Call me stupid for that one also.)  Once I corrected the file name, the php.ini file was immediately found by Apache.  Then again, over the past several days I had already set (and reset) many of the usual places to find the php.ini file (e.g., registry and environment variables to look in the right place -- the file name was simply wrong.)

 

In the first successful execution with the php.ini file, however, mysql and mysqli files were not loaded.  Once I had changed the  extension_dir directory back to the php.ini file recommended "ext" (from some website recommended "c:\php\ext") both of those files were also immediately found.  Running the phpinfo() file still lists the path as c:\Windows, but the next box down indicates that the loaded file is (correctly) in c:\php.

 

I am posting this with the hope that someone else won't burn as much time looking for an esoteric solution to a simple problem.

 

I got mine working last night, too, although my issue is still somewhat of a mystery. I did find a few things which I will mention here in case others are having problems. It might save someone some trouble.

 

First, to determine whether or not PHP itself can find the config file, open a command prompt and type:

 

php -i | more

 

This will give you the same info that running phpinfo() gives you, so you can find out whether or not a config file is being loaded, and if so which one.

 

When I did this, I actually got a CLI error. If I changed the extension of the ini file and ran it again, I was back to having nothing loaded (which makes sense). That told me something was wrong in the php.ini file itself.

 

Unfortunately, I can't say exactly what it was. I had fiddled so much with different versions of the .ini file that I just started over with the copy generated by the installer, used a file compare utility to find the differences between it and the copy of the .ini file I used on my XP box, and made the appropriate changes. Once I did that, both the command line and phpinfo() loaded the correct file with no errors.

 

My next problem was that I wasn't getting a connection to MySql. Turns out I didn't have the loopback address specified in my hosts file (but that's nothing to do with PHP). With that fixed, I finally have PHP communicating with the database.

 

This was a lot harder than when I did it last time, but I suspect it's just because I managed to shoot myself in the foot three or four times along the way. Ouch.

 

 

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.