I have a really irritating problem with PHP on Windows Server 2008 R2. IIS and Apache are running on the same machine (Apache is embedded with another product and it being there is not my choice).
IIS is configured to be able to use multiple versions of PHP, and none of the PHP versions on there were installed with the Windows installer (so php.exe does not exist in the path).
Apache uses one particular version of PHP (5.2.5 Thread-safe – again I can’t change this as a 3rd-party application has PHP extensions compiled against this version).
If I check phpinfo() in my Apache site it doesn’t have an entry for MySQL, even though php_mysql.dll is enabled in php.ini and it exists in the \ext directory. If I (temporarily) add this version of PHP (same directory, same php.ini) to IIS and set up a test site with phpinfo() it correctly lists MySQL. I know this is not just some strange issue with phpinfo because I have a MySQL-based PHP site running in Apache and it fails with Call to undefined function mysql_connect()
It was suggested that I copy libmysql.dll from the PHP directory to C:\Windows\System32 but this made no difference. As there are multiple versions of PHP on the server I suppose it’s possible that the wrong version of libmysql.dll is being loaded, but the PATH doesn’t include any directories containing libmysql.dll.
IIS and Apache are looking at exactly the same PHP installation, php.ini, and ext directory, but only IIS can load the MySQL extension. Apache is on the default System account as it looks like System has access to all the DLLs.
The Apache logs say nothing about any DLLs failing to load. I’m logging PHP errors in the event log but nothing is reported about those extensions.
After Googling around the issue I found other suddenly-occurring issues in PHP on Windows server but the usual resolutions – rebuilding php.ini, restarting IIS, restarting the server – haven’t helped.
Any suggestions on where to look next are much appreciated!
Ultimately this issue came down to a missing PATH reference. Although IIS doesn’t seem to require PHP or PHP modules to exist in the path it seems that Apache (or perhaps my version of PHP?) does. I am lucky in that I only need to run one version of PHP outside IIS, as I have no idea what would happen if I had multiple Apache instances referencing different versions of PHP and multiple PHP directories in the path – presumably one would always fail.
So far it looks like adding Apache’s version of PHP to the path hasn’t affected the IIS versions of PHP, but I will swear loudly if it suddenly does.