Stephen Rushing

I just spent (feels like wasted) 6 hours trying to do a simple Apache/PHP install on a Win2K3 server.

I installed Apache without a hitch. Got the lovely “It works!” page, and then moved on to the PHP install. After trying the auto-install and binary packages, Apache simply would not start and would throw the following error in the Windows Application log:

Faulting application httpd.exe, version 2.2.14.0, faulting module php5ts.dll, version 5.2.11.11, fault address 0×000f330d.

I tried to Start > Run > “cmd” > “C:\php\php.exe -v” [enter] and kept getting DLL errors like “This application has failed to start because xyz.dll was not found. Re-installing the application may fix this problem.” I started tracking down the DLLs, but every one I fixed would expose another missing one.

Finally, I stumbled onto this PHP bug report where bwacker listed some of the same DLLs I was having trouble with. I commented out the lines referencing those DLLs in the php.ini file. The errors disappeared, and Apache started right up!

Here is bwacker’s list. Not all of the references were in my php.ini, but removing the ones that were there did the trick.

;extension=php_ifx.dll 		needs ISQLT09A.DLL
;extension=php_iisfunc.dll	not in /extensions
;extension=php_mcrypt.dll	needs LIBMCRYPT.DLL
;extension=php_oci8.dll		needs OCI.DLL
;extension=php_oracle.dll	needs OCIW32.DLL
;extension=php_printer.dll	not in /extensions
;extension=php_sybase_ct.dll needs LIBCT.DLL and LIBCS.DLL

Obviously, if your application requires any of those DLLs, you will need to resolve the absences, but most of you will not need them.

Hope this saves you some time!

A friend recently told me about the open source e-commerce software, Magento. It looked much nicer than osCommerce and ZenCart, so I wanted to give it a try.

Most of what I found involved setting it up in Apache, but I did come across one well-written guide on installing it in IIS.

I got to page 2 of the walkthrough and read, “There is no need to go into details about each extension, but something worth mentioning is that you cannot have both php_mysql.dll and php_pdo_mysql.dll enabled. Magento uses pdo_mysql, and if you enable both, php_mysql takes presedence over pdo_mysql, so keep this in mind.”.

AH! I just jumped through several hoops to get mysql working for Wordpress. And obviously, the generic mysql extension is required by too many things to disable it. I decided to move on with fingers crossed…
** NOTE: I did not run into a conflict with having both enabled. Maybe this has to do with php_pdo_mysql being declared before php_mysql. **

Also, I did not see an ISAPI_Rewrite tab in my IIS Web Sites properties after installing it; although, there was an entry for it in the ISAPI Filters. I went to the Rewrite Manager in Start > Programs > Helichon, and saw pretty much the same output as the guide’s screenshot.

This tutorial states it assumes we downloaded Magento build 1.0.19870.1, but 1.1.2 was out now, so I went for that instead.

After handling a couple of permission issues (described in the guide), the Magento installer started!

I got to the Configuration section and got thse messages:

• PHP Extension “mcrypt” must be loaded
• PHP Extension “curl” must be loaded

Those extension lines were already uncommented in my php.ini, so I did some searching. This post says to place libeay32.dll and ssleay32.dll in the windows\system32 directory. I did so, restarted IIS, and the curl message dissapeared.

I figured the mcrypt problem was related to the curl and mysql issues I’d had, where I needed to place the dll directly in windows\system32 (still no idea why IIS doesn’t read from the Path environment variable). So, I copied libmcrypt.dll to my system32 dir, restarted IIS, and it worked!

Now, I could browse around the admin area, but all the links on the front end were broken. I noticed the admin area had index.php/ before most of the paths (like my Wordpress blog), but it was missing from the links in the front end. The guide had me add index.php to a config.php file, so I assumed the same had to be done for the URLs on the front end. Sure enough, http://MYURL/customer/account/login/ didn’t work, but http://MYURL/index.php/customer/account/login/ did.

Currently trying to resolve this on the Magento Forums. I’ll update this post once it’s all squared away.

I have found that disabling the URL Rewrites in Admin > System > Web works, but the URLs aren’t quite as friendly.

**UPDATE 8/10/2008**

As excited as I was to get this up and running in IIS, there was too much of a speed issue. I’m giving SimpleHelix Hosting a try, per the recomendations on a Magento Forum post.

I went to install Wordpress, but I got this error when I ran wp-config.php:
PHP has encountered an Access Violation at 0202B75A

A test phpinfo() file also displayed a completely blank page. Even a simple echo yielded the same results. Obviously php was not configured correctly.

Turns out the installer is not the way to go. After checking the settings and reinstalling several times, I followed these steps.

Progress! But I was now getting the following error - clearly a permissions issue:

HTTP Error 401.3 - Unauthorized: Access is denied due to an ACL set on the requested resource.

After setting the basic permissions to no avail, I crawled back to google. After another 30 minutes of searching, I came across this post.

The trick was adding the appropriate users with “Read & Execute”, “List Folder Contents”, and “Read” permissions, then clicking “Advanced”, then checking “Replace permission entries on all child objects…”, then “Apply”. Specific to my server, I gave IUSR_TEMPLATE and IIS_WPG access.

phpinfo() now displayed the php config! Considering it’s been as simple as running the installer for me before, this seemed like quite a hassle.

At this point in my Wordpress installation, I excitedly ran wp-config.php, which abuptly stated, “Your PHP installation appears to be missing the MySQL extension which is required by WordPress.”

Horseradish. Neither extension lines for mysql.dll and mysqli.dll were commented.

Then I found this post, which explains the PHPRC environment variable must be set to your php path. This didn’t fix the error, but since I did notice before that the variable was being created by the PHP installer, I left it.

Next, I found a walkthrough that said to copy the libmysql.dll file from c:\php to c:\windows\system32. He also questions why IIS doesn’t just read it from the php directory, since the dir is in the Path environment variable…who knows. I restarted IIS and HOORAH! As you can see, I’m up and running.