Tag: PHP

Posted on
by

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.

Posted on
by

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.

Posted on
by

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.

Posted on
by

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.