I recently ran into some issues with installing PHP on an IIS server, and, in the process of tracking down the problems, came to the conclusion that the PHP Group doesn’t do enough (any?) release testing, and still treats the Windows platform (regardless of whether or not Apache is used) as a second-class citizen. Why? Let’s see:
- The installer will allow you to install modules for which you don’t have the prerequisites installed. This wouldn’t be an issue if the PHP interpreter handled this gracefully, but it doesn’t — it simply spits out a bunch of dynamic link errors and self-combusts. I agree with the last comment in that bug report — it may be a case of “pilot error,” but the expectation on the Windows platform is that, barring any warnings or errors that are clearly explained to the user, a complete install should just work.
- The current released version of PHP was completely busted on Windows Server 2003 — it doesn’t read its configuration file correctly. (For the benefit of those who may be Googling for a similar problem, this would result in Drupal, a CMS I was installing, reporting that “Your web server does not appear to support any common database types.”)
- Separately from that, the released version of PHP also didn’t set itself up correctly in IIS as a document handler. For some unfathomable reason, it used 8.3 file names, which have not been necessary in the last 13 years. This would cause the document type handler to fail, and 404s to be returned when accessing a PHP file through IIS.
- The documentation for the mysqli module (as well as the similar-but-different mysql module) recommends adding the PHP directory to the Windows PATH variable, for the express purpose of getting the libmysql DLL bundled with the installer to load correctly. This is terrible advice, in my opinion, because, depending on where the user adds the path, the bundled version may take priority over a more recent libmysql installed by MySQL itself. There are additional DLLs in the PHP directory, too, for SSL support, and the same situation could arise there.
While the library vendors may not have a side-by-side versioning scheme for their DLLs, it’s still no excuse for advocating a dangerous practice.
For a product that is so widely used, these kinds of problems are really inexcusable, and only contribute to the flaky reputation PHP has.