You are currently browsing the HTNet archives for January, 2006.

Upgrading ApacheMySQL and PHP on Windows is a bitch. That’s the lesson I learned last weekend.

I decided to be extra helpful and upgrade the existing installation of these three apps, which powers our corporate CMS. The only reason I proposed this idea (yeah, nobody asked me to do it, I volunteered) is because the previous installation is quite dated. PHP was the worst, it was running 4.1.x.

Apache installation went without a hitch. It was done in a matter of seconds. Next was PHP, so I grabbed a copy of version 4.4.2, extracted the archive to C:\PHP and moved the files in C:\PHP\dlls to C:\PHP. Nothing difficult about that. However, when I restarted the Apache service, it failed. To cut a long story short, this was because php4ts.dll and libmysql.dllfrom a previous installation being in C:\WINDOWS\SYSTEM32. Deleted those two, and wallah! Apache can now be started and phpinfo() shows that I’m now running PHP 4.4.2.

Next came MySQL… the absolute major source of my pain. Well, looking back, I guess it’s mostly a compatibility (incompatibility?) issue of MySQL and PHP (more on this later), rather than solely a MySQL problem. Who would’ve thought that upgrading from 4.1.12 to 4.1.16 could be such a pain in the ass?

To be honest, I’ve used Apache, MySQL and PHP for more than five years. However, this experience is primarily on Linux. And let me just say this, for all the noise that the Windows fanboys are making about how easy it is to install software on Win32, installing the said three apps on Linux is much easier!

OK, to cut the story short, here’s the error that I got when trying to run PhpMyAdmin#1251 - Client does not support authentication protocol requested by server; consider upgrading MySQL client.

I literally went “WTF?!”, it’s not that I don’t understand what the error means, it’s the fact that I’m using binary builds of PHP and MySQL… and that there’s no way in hell I can compile it manually because the server hosting the CMS doesn’t have Visual Studio. Furthermore, the PHP connector DLLs downloads on the MySQL web site are just for PHP5. Yet another stumbling block, because I’m afraid that XOOPS which is what we used for the CMS, might probably be incompatible with PHP5.

Although dazed by all these complications, I proceed to download PHP 5.1.2, after confirming that XOOPS can run on PHP5. Initially, I was quite a happy guy considering that I can see the front page just fine. I proceed to click on the most frequently used module on the CMS, which is our Project Management module. It’s a highly hacked version of WebSlave Project… *bam!* blank page! Arrrgghhh!

In the end I did get PHP 4.4.2 and MySQL 4.1.16 to play nice with each other (old connector DLL and all) by adding the following line in the my.ini file’s [mysqld] section:


Hell, that thing doesn’t even look like an INI file directive (which usually come in pairs; eg. variable=value)! This particular post by Mark Rosenthal in the MySQL forums pretty much sums up my frustration with this whole damn exercise.

Painful lessons learned:

  • Never assume upgrading/installing open source software on Windows to be easier or as easy as on Linux.
  • Always make backups of existing data files regardless of how easy you foresee the upgrade/installation to be.
  • Take more than five minutes to google for potential problems.

In my post Common Web Site Structuring Mistakes, I did mention that robots.txt tend to deceive its function of restricting access to certain areas of your web site by search engine crawlers, more commonly known as robots. Instead, the robots.txt file might actually do more revealing rather than restricting. In light of this, is there any other way to get the function of robots.txt without actually revealing too much information? Lucky for you, there is.

Say hello to the robots meta tag… Same functionality as robots.txt, but far less obvious. Here’s how one would look like:

<meta name="robots" content="noindex,nofollow">

As with all meta tags, the above would go in the <head> section of your HTML. What that particular line does is to inform the robot that the particular page which has this meta tag should not be indexed, and the links in this page should not be crawled. This will effectively cause compliant robots to virtually ignore the existance of this page.

Yes, I did mention “compliant robots”… and the last time I checked the robots/crawlers from major search engines such as Google, Yahoo!, MSN, Altavista, etc. do support the robots meta tag as well as robots.txt. Heck some of the more “evil” robots don’t even follow the robots.txt rules, these robots are often used as email address harvesters by spammers.

Another item you might want to consider adding to your robots meta tag is noarchivecontent. This tells compliant search engines not to cache the contents of the page. Thus if your page appears on, let’s say Google’s search results, pages with the noarchive directive won’t have a Cached link under it.

So in summary:

<meta name="robots" content="noindex">
This tells the robot not to index the page.

<meta name="robots" content="nofollow">
This tells the robot not to follow links on the page.

<meta name="robots" content="noarchive">
This tells the robot not to archive the page.

<meta name="robots" content="noindex,nofollow,noarchive">
Multiple directives are possible and the options should be separated by commas.

A final caveat: Just as not all robots obey the rules of robots.txt, the same thing applies to using the robots meta tag. There’s no 100% sure way to exclude your pages from being found, other than not to publish them at all, of course.