I use WP-CLI from time to time to do maintenance on my WordPress sites that I host on a DreamHost VPS. But today I tried to run the search-replace function and found that wp wouldn’t run. Instead I got this error:

Fatal error: Call to undefined function apply_filters() in /path/to/wp-includes/load.php on line 317

It didn’t take long to confirm that WordPress 4.6 had changed things around, breaking the version of WP-CLI on my server. As it turns out, WP CLI 0.24 fixes this, but DreamHost is running 0.24-alpha.

So I tried installing the current version locally on my account, only to get a different error:

Fatal error: Class 'Phar' not found in /path/to/wp-cli.phar on line 3

I found this article very helpful for enabling PHAR support on a DreamHost VPS. I went into ~/.php/5.6/phprc (create this file for your version of PHP if you don’t have it) and added:

phar.readonly = Off
phar.require_hash = Off
suhosin.executor.include.whitelist = phar

Once I verified that it would work by running /usr/local/bin/php-5.6 wp-cli.phar --info, I took the opportunity to (a) override the wp command with the local one and (b) make sure it used php 5.6 by adding the following alias to my .bash_profile:

alias wp='/usr/local/bin/php-5.6 ~/bin/wp-cli.phar'

This won’t be needed once DreamHost updates their WP-CLI package, but for now, it solves my problem faster than waiting for a response from tech support.

As of last week, this site is being served to you by a shiny new SSD-backed VPS at DreamHost. I was hoping it would be running NginX as well, but try as I might, I couldn’t get WordPress in a subdirectory to play nice with NginX. Speed Force worked fine, but it’s at the top level of a site. Ramblings and Re-Reading Les Misérables aren’t.

Fortunately, the new virtual servers are faster and cheaper (newer hardware, after all), and with the rest of my sites running NginX I end up with about the same overall memory footprint for two VPSes so that I could put this back on Apache. I suppose that saved me time converting the zillions of .htaccess rules I’ve amassed over the years. And with the faster systems, they’re able to handle more complex/simultaneous actions without timing out or spiking memory.

When I started the category clean-up project a while back, I decided to start monitoring 404 errors on the blog to see if I missed any incoming links that needed to be redirected. I was surprised to find that the logs showed no 404 errors at all from within the blog structure. Images, sure, but no articles, no tags, no categories. This seemed a bit hard to believe.

I tested it by deliberately hitting a non-existent page, and was dismayed to find that Apache logged the hit as 200 (OK).

Crap! a WordPress update must have broken 404 handling! How long had this been going on? I’d better manually insert a header in the 404 page!

That seemed to work, as far as Chrome’s Developer Tools and curl -I were concerned. I didn’t have time to follow up on the logs right away, so I checked back later…and the logs still showed 200 OK, not 404.


It turned out that, when served through WordPress, Apache was sending a 404 code to the browser but logging a 200.

Probably a plugin, right?

Not so. I installed a fresh copy of WordPress on a test site and discovered something interesting: 404 codes were logged correctly when using the default /?p=123 permalink structure, but if I changed it to anything readable like /yyyy/title or even /title, the problem recurred.

A little more investigation: I skipped WordPress entirely and just hit a PHP page that served up a 404. When I hit it directly, it logged correctly. But when I used WordPress’ mod_rewrite rules to send a hit to that page, it logged a 200.

So clearly, it was something about mod_rewrite. I don’t run my own Apache server these days (my department at work is mainly a Windows shop), but I was pretty sure it didn’t work that way back when I did.

So I did some testing of different configurations at home and on my webhost. Direct hits always logged the correct status, but with a rewrite rule, here’s what I found:

FastCGI & CGI on DreamHost show 200/404.
mod_php on home box shows 404/404.
mod_php on DreamHost shows… 200/404.

At this point I figured there was no point setting up a CGI or FastCGI-based PHP environment on my home box, because it was clearly something about Dreamhost’s Apache configuration.

It does log correctly if you use ErrorDocument directive to point 404 to a PHP script. But IMO that’s abusing the error handler mechanism to do something it wasn’t meant for. (Not that I haven’t done it myself, but only on older IIS servers where ISAPI Rewrite and URL Rewrite weren’t available.)

I’ve added a custom logging snippet to my WordPress 404 page. There are other ways I can capture the data, but that seemed like the least overhead for now.

After a list of companies publicly supporting SOPA (the censor-the-internet-in-the-name-of-stopping-piracy bill) went public last week, the complaints started rolling in…but the biggest target, at least in the circles that I frequent, was GoDaddy. People organized a boycott, transferred their business elsewhere, and GoDaddy eventually reversed course, but it was too late to stop a massive outflow of customers.

But why was GoDaddy such a target? And for that matter, why did so many people follow through, rather than just rant about it on the internet?

I think there are several reasons.

  1. The tech industry is mostly opposed to the bill on technical reasons. Pick a random hosting provider and chances are they’re officially against it. That made GoDaddy stand out in a way that a random movie studio doesn’t.
  2. They provide a service, not content, and there are many competitors who provide the same kind of service. (And it seems like they all came out with discount codes to encourage people to switch to their company.) With content, you can choose to read a book from another publisher, or watch a movie from another studio, but if you want to watch a particular movie, you can’t get it somewhere else. There are lots of comics publishers out there, but if you want to read Spider-Man, you can only get it from Marvel.
  3. Public opinion of GoDaddy was already low. For some it was their sexist ad campaigns. For some it was the CEO bragging about shooting elephants. For some it was their incessant email marketing, or focus on upselling unneeded services to people who didn’t understand what they were, or the fact that their website is such a %^$^@#%& pain to use. They’re cheap, and they’re well-known, which means a lot of people used them…but they weren’t that well-liked. Supporting SOPA ended up being the last straw.

As a result, you had a company that was tolerated at best painting a target on themselves, and a relatively easy way for people to vote with their wallets and not actually give anything up other than the time and money needed to make the transfer.

Full disclosure: I used to have about 10 domain names registered through GoDaddy, plus a few at DreamHost and one at Network Solutions. (Yes, Network Solutions.) GoDaddy was annoying, but cheap, and it was easier to renew than move. This week I consolidated them all at DreamHost, where I’ve had my websites hosted for the past year. DreamHost is offering a discount code for new customers who want to switch: SOPAROPA. I don’t get anything for telling you that, but if you sign up and list me (kelson – at – pobox – dot – com) as the person who referred you to DreamHost, I’ll get credits that I can apply to my hosting bill.

After years of piggybacking on employers’ web servers (with permission, of course!), I’ve moved my personal websites to a third-party web host. It’s kind of weird to be dealing with a web server that I don’t fully control, but DreamHost is really flexible and (most importantly) specifically supports WordPress.

The only thing I’ve really missed so far is Apache’s mod_speling [sic], which will automatically correct any one typo or capitalization error when trying to reach a file. It’s nice to have, but far from critical.