Tag Archives: PHP

Using WP-CLI with WordPress 4.6 on DreamHost

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:

extension=phar.so
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.

Weird 404 logging error with PHP and mod_rewrite on DreamHost

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.

WTF?

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.

What’s Dynamic About It?

In my post on Webslices, I mentioned that the home page of my Flash site uses server-side includes instead of a static HTML file. But it doesn’t really update that often: maybe 3 or 4 times a month. Is it really worth building that file dynamically? Should I switch from SSI to something more powerful, like PHP, that will let me add headers so that repeat visitors won’t have to re-download the whole page except when it’s actually different? Or should I switch to a static file, with the same benefits but simpler? What am I actually building, anyway?

Looking through the code, I find:

Browser upgrade banners. People using old versions of Firefox (currently 1.5 or older) or Internet Explorer (currently 5.5 or older) get an “Upgrade to Firefox 2” banner instead of the thumbnail of the current issue of the comic. This is just as easily done with JavaScript—and is done with JS elsewhere on the site. (I used to make some minor adjustments for other versions of IE, but I converted them all to conditional comments a while back.)

Last-modified date in the footer, pulled from the actual file. I’ve already got a script to update this in the static files, so it’s just a matter of adding it to my general update script. A two-minute, one-time change and I’ll never notice the difference.

Latest posts from this blog. Probably better done with an iframe, or maybe using AJAX. Drawback: either method would mean an extra request from the client. On the plus side, repeat visitors would be able to re-use the rest of the page, and only download the 5-item list.

Unique-per-day spamtrap addresses, hidden where harvesters might pick them up. But only a few of them still accept mail and feed it to filters. Mostly, they just waste spammers’ resources. I could easily either get rid of them or change the script to generate a new address with each update instead of each day.

So really, there isn’t much stopping me from using a static file for the most-viewed page on the site, with all the attendant savings in system resources, bandwidth, etc.

On the other hand, I keep contemplating switching to a database-driven system for the whole thing, which would make any changes now meaningless. But since I’ve been thinking about that since around 2000 or so, and haven’t changed it yet, that’s not exactly a blocker!

Update (March 30): I’ve made the conversion to a static file. The blog posts and browser upgrade banners are now done client-side (and run after the rest of the page is loaded), the last-modified date is part of the pre-processing script, and I just removed the daily spamtrap addresses. Now to see whether it actually improves performance.

Patch…Friday?

I suppose it’s best to release the security fixes when they’re ready, because any time you pick is going to be inconvenient for someone, but lately it seems like Friday is suddenly in style.

Last Friday saw the release of PHP 5.2.4, on the Friday before—in the US, anyway—a 3-day weekend. This morning Apache released security updates for all three supported branches of their webserver. And this evening—yes, Friday evening—WordPress 2.2.3 came out.

Which reminds me, I’m going to have to start looking at the betas for WordPress 2.3. I think it’ll be a good time for a redesign. Maybe pick a new theme and tweak that one, maybe try my hand at actually designing one. I wonder if the new tagging system can import Bunny’s Technorati Tags.

Automattic Stats, or PHP 5.2.2 vs. WordPress XMLRPC

Experimenting with the new Automattic Stats Plugin that uses the WordPress.com statistics infrastructure to track traffic. So far, so good… except for one problem. Titles and links are missing from all the “most visited” posts. They’re just listed as numeric IDs.

Update: Actually, today’s posts seem OK. The plugin seems to just send the blog ID and post ID. I’ve been trying to figure out how the central server is retrieving the permalink and title. It doesn’t look like Bad Behavior is blocking it. And it doesn’t seem to be using the RSS feed, since posts that are still on the front page (and presumably still in the feed) are also showing up as numbers. *grumble*

Update 2: I just noticed that all of the number-only posts show the same placeholder graph showing “Region A” vs. “Region B” for 2003-2005.

Update 3: It’s a problem with WordPress’ XMLRPC interface, and affects other uses (like connecting with Flock). I’ve got a workaround, though (see comments).

Update 4 (May 10): Thanks to the pingback below from dot unplanned, it’s confirmed to be a bug in PHP 5.2.2. With any luck, the workaround will cease to be necessary when the next PHP bugfix is released.