This is the first time I've installed PHP and I am having a problem with getting extensions to work.

Here is my setup:
Win 2003 Server
IIS 6
MS SQL Server
PHP 5.0.2

PHP is up and running, but I modifed to the php.ini file to load the following two extensions:
extension=php_gd2.dll
extension=php_mssql.dll

and I have set the extension path as follows:
extension_dir = "<drive>:\PHP\ext"

But ... nothing. No errors, it just does not work. Also when I run

<?phpinfo();?>

It returns wrong information. It is reporting the wrong path for the php.ini file (I've already verified that I only have one php.ini file on the system) and the wrong extension_path (the path it show does not even exist).

Also, if I run

<?var_dump(gd_info());?>

, I get the following error:

Fatal error: Call to undefined function gd_info()

Which brings up another problem. I've turned short_open_tag =Off, BUT <? still works. Shouldn't this only allow for <?php ... ?> to work?

I've restarted both the specific web site and the IIS services, but neither one seems to read the new php.ini file.

PS we can not run Apache.

Any help would be great!

Thanks

    Hi,

    in most cases php.ini has to be in the systemroot directory (e.g. C:\windows).

    Copy the php.ini file to the directory shown in th phpinfo output.

    Thomas

      tsinka,

      Thanks for the post. Do I have put it in C:\windows if I have set the following reg. entry?

      HKEY_LOCAL_MACHINE\SOFTWARE\PHP\IniFilePath:=<drive>:\PHP

        Ok, I copied the php.ini file to c:\windows, changed permissions to allow IUSR and IWAM READ and EXECUTE, and restarted specific web site ... still did not work.

        Restated IIS ... still did not work

        Resarted Server ... still did not work

        Modified registry entry to point to new ini location, restarted everything ... still did not work.

        And now every time I attempt to run a PHP page IIS locks up and I have to force quit it (which is where I was two days ago before I deleted everything and did a fresh install).

        Anyone have any clues?

        To do the install, I followed theses instructions:

        • Download and unzip latest version (used 5.0.2) to D:\PHP
        • Rename/copy php.ini-recommended to php.ini
        • Add IUSER to Security tab for php.ini with Read and Execute, and Read permissions
        • Download browscap.ini (got it from http://www.garykeith.com/browsers/downloads.asp -
          php_browscap.ini) to D:\PHP\extras\browscap.ini
        • Uncomment and edit the browscap variable in php.ini to point to D:\PHP\extras\browscap.ini
        • Add to the registry HKEY_LOCAL_MACHINE\SOFTWARE\PHP\IniFilePath = D:\PHP
        • Add (and allow) the PHP ISAPI Extension to IIS Web Service Extensions: D:\PHP\php5isapi.dll
        • Right-click on "Web Sites", goto Properties->Home Directory->Configuration...->Application Extensions and add a new extension: .php using D:\PHP\php5isapi.dll; limit verbs to GET,POST,HEAD. This will apply to every website.
        • Restart IIS
        • In one of the websites' home folder, create a new file named test.php with the single line below:
          <? phpinfo(); ?>
        • Point browser there to test.

        which I found in the developer comments section at http://www.php.net/manual/en/install.windows.iis.php

          Ok,

          I had similar problems (lock up) some time ago ... the solution was to enable output_buffering in php.ini

          Thomas

            why are you referring to both c:\ and d:\ drives in your posting?

              tsinka,

              I have output_buffering = 4096 in php.ini. Does this value need to be higher?

              d~l,
              Why am I refering to C: and D: in my posts? You'll notice that I posted the initial intallation instructions I followed which suggested installing everything on D: (I simply copied and pasted the instructions). Then, tsinka suggested, I move the php.ini file to C:\Windows to see if that would improve things, which I did, but it did not help.

              Sorry, I did not think that would confuse anyone.

                Does a simple phpinfo page hang forever, too ?

                Thomas

                  can you run PHP using a command line?

                  I would unwind your entire PHP installation (including registry) and reinstall in c:\ drive .. and forget browscap.ini option until you have PHP working.

                  If you are starting to learn PHP you could install the simple BadBlue personal server .. on a port other than default 80. No registry setup needed. Up and running within minutes.

                  Then when PHP is up and running, map to your IIS server (yes, BadBlue PS and IIS can coexist whilst you are getting started).

                    d~l,

                    I can not install BadBlue as this is a production web server (I know slap my hand for testing in production, but no guts no glory right?)

                    Anyway, I backed the ini file OUT of the c:\windows directory and PHP is running again without hanging IIS. However, I still can not get PHP to recognize any ini file changes. When running phpinfo() it says that the "Configuration File (php.ini) Path " is c:\windows, which is not true since the ini file has been deleted from that directory. So I am assuming that PHP is running without an ini file and is simply loading in some set of default values.

                    I also read on the Zend Tech web site (http://www.zend.com) that on a Windows system you can set ini values in the registry, but I have yet to test this.

                    I'm still hammering away at this thing and I will post my results when I can.

                      Does IUSER have read permissions on the D:\PHP directory ?

                      Thomas

                        Right now, no. But I did at one point and it did not seem to make any difference. I do have IUSR rights on the ISAPI dll file though.

                        Question: If PHP is, in fact, not looking at an ini file, but loading default values, and when I did have the ini file in the C:\windows directory where it was looking for it IIS was locking up, could it be that there are bad values in the ini file causing the problems?

                        I am using the recomended ini file from the default PHP 5 installation.

                          read the conclusion of .. this thread

                          turned out to be file permissions.

                          similar symptoms.

                            YEA! I've got it working! The problem was bad ini values.

                            Here is the scoop:

                            • I removed ALL of the registry entries that I had manually added for PHP (via instructions from several diff websites)

                            • Created a new system environment variable (PHPRC) and set it equal to the path to my php.ini file (not c:\windows, but that will work).

                            • Added the path to the PHP directory to the Windows "PATH" environment variable

                            • Deleted everything in my php.ini file except the specific settings I knew I wanted either on or off and the specific extensions I wanted loaded.

                            • I have IUSR READ/EXECUTE permissions on the php.ini file and the ISAPI dll file.

                            I still do not know which ini values are causing the problems, but I will start working to figure that out.

                            After changing any ini values, I have to stop and restart the IIS service for them to take affect and not just the 1 website actually running PHP (it stinks, but it works and PHP is free so I can live with that - I also realize that it may be because of the way I have it setup, so ... ).

                            I wonder if the guys who followed the instructions I posted from http://www.php.net/manual/en/install.windows.iis.php realize that PHP may be using a default set of values and not their ini file.

                            tsinka and d~l, thanks for all your help and your willingness to stick with me on this!

                              Write a Reply...