The other day, the WordPress.com Stats plugin I use to spy on you monitor this blog stopped working. Then I started getting this error from Stats:

Your WordPress.com account [Redacted] is not authorized to view the stats of this blog. Currently access to stats is broken for some users and we are working on fixing this. Your stats are still being counted and will be visible once we restore access for your account.

Fair enough. I waited. And waited. And waited some more. When it became apparent that this wasn’t a temporary problem, I removed and re-added the plugin, and was then greeted with this new, more exciting error:

“The owner of that API Key ([Redacted]) is not on the access list for this blog ([Redacted]). Stats was installed using a different API key. The owner of the original key can add users to the access list, or you can contact WordPress.com support.”

Huh. Well, since that didn’t do it, I did some Google’ing and found out that Automattic just released Jetpack, a collection of plugins that replaces a good chunk of the standalone plugins out there that work with WordPress.com services. People who were getting the above errors reported that the Stats plugin provided with Jetpack worked, so I switched. And immediately received yet another error:

Your Jetpack has a glitch. Connecting this site with WordPress.com is not possible. This usually means your site is not publicly accessible (localhost).

Fantastic. Google once again helped me to find a bunch of other users with the same problem, but sadly, none of the fixes (most of them found in this thread) worked for me. I broke down and contacted Automattic support, and their reply was the following:

It might be the SSL cert that is preventing Jetpack from connecting. Is the site also behind any sort of firewall?

Which, of course, the site is. However, that was the first thing I checked, as my IPTABLES rules are just north of Insanely Restrictive. Sadly, disabling IPTABLES did nothing to help. Additionally, I was able to confirm that outbound SSL access was working by using CURL from an SSH session to grab pages from https://wordpress.com, so that’s not the issue either. I replied back to let him know this, and I’m waiting on a response. Through all of this, the normal WordPress.com Stats Plugin still doesn’t work. So,

My new favourite meme.

yum install php-gd

service httpd restart

And you’re done! …At least, as long as you’re using an RHEL-compatible Linux distro. If not, use your package manager of choice, or manually find and load the php-gd extension!

See that last big dip? Guess when that happened!

So I started looking around the site, and sure enough – the main pages displayed fine, however everything else was broken. In fact, anything with a ‘fancy’ permalink was 404′ing.

Once again, a quick Google search lead me to this thread on the WordPress forums. After digging around, I found the problem – in Apache’s httpd.conf file on my new VPS, I needed to change the following line:

AllowOverride None needed to be AllowOverride All

Note, though, that there are two AllowOverride entries in httpd.conf – one wrapped in <Directory></Directory> tags, and one all by itself. The problematic one is the second AllowOverride entry that isn’t wrapped in Directory tags.

TL;DR Version: If you enable fancy permalinks in WordPress, and start getting 404 errors in Apache even with a proper .htaccess file and mod_rewrite enabled, change AllowOverride None to AllowOverride All in httpd.conf – just make sure you do it to the second AllowOverride entry!

Updated! If you’re using nginx instead of Apache, simply add the following to the location section of your nginx.conf file (or the one for your vhost, if you’re doing that):

if (

    !-e $request_filename) { rewrite ^.*$ /index.php last;

}

Updated again! If you’re using ligHTTPD, you can add the following line to lighttpd.conf (although if you are using your own custom 404 error page, you may wish to find another solution):

server.error-handler-404   = "/index.php"

In other news, I’ll be swapping the hinges and LCD back cover on my wife’s Acer Aspire 9300, with before/during/after photos. The hinges on this model are very stiff and eventually break the plastic case, and then warp themselves rending the laptop a desktop. They’ve already been replaced under warranty, so now it’s my turn to take a crack at it. Also, her hard drive is starting to show signs of immediate-total-failure in the form of disk read errors on boot, so that’ll be swapped along the way.

A quick note about WordPress installations on Windows Server 2003. After installing Apache2, MySQL Server Community Edition, and extracting PHP5 (Protip: don’t use the installer, just download the .zip file and extract it to a folder on your server, eg. C:php), configure the php.ini file in the PHP directory as normal, with the following changes to avoid issues with MySQL not integrating with PHP correctly:

1) Set extension_dir to the absolute path of the extensions directory. So if you extracted PHP to C:php, you need to set extension_dir to “C:phpext”. Do not use relative paths!

2) Remove the semi-colon from the line extension=php_mysql.dll.

3) Set the upload_tmp_dir path to an existing folder. I’d suggest making a new temp folder, such as C:phptemp.

4) Configure mysql.default_port and mysql.default_host with the correct values for your MySQL server.

5) Set the doc_root parameter to where-ever you plan on storing your the files for your site. This needs to be the same as the document_root parameter in Apache2′s httpd.conf.

Now you just need to configure Apache2 to correctly use PHP5. Add the following lines to httpd.conf (note the slashes used – don’t use backslashes!):

LoadModule php5_module “c:/php/php5apache2_2.dll”
AddType application/x-httpd-php .php
PHPIniDir “C:/php”

Even though the installation instructions included with PHP say to use php5apache2.dll, we have to use php5apache2_2.dll, otherwise Apache2 will fail to start. All that’s left now is to copy libmysql.dll and php5ts.php from the PHP directory to C:WindowsSystem32.

With this done, you should be able to restart Apache2, and you hopefully won’t get any errors! To test and make sure that PHP5 is working, and that MySQL5 is accessible, create a new file in your site root (the same folder that doc_root and document_root point to) called info.php, and put the following line in it:

<?php phpinfo(); ?>

Open your webbrowser, and type http://localhost/info.php in to the address bar, and you should get the standard PHP Info page. Do a search for MySQL, and you should have a heading for it. If so, you’re ready to install WordPress. If not, then double-check your configuration.