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.

After switching one of my self-hosted WordPress blogs to all-HTTPS, I ran into an odd problem: Jetpack Related comments stopped working after a while.

After going back and forth with Jetpack support and my web host, it turned out the problem was with the SSL configuration on my site. Jetpack has to download a copy of your posts in order to calculate recommendations, and it uses libcurl to do that. Curl has stopped supporting the RC4 cipher in SSL connections because weaknesses have been found in it…and that’s what my server was using! (Ack!) I assume it was an old compatibility setting that never got updated.

Jetpack needed to reindex the site, but couldn’t retrieve anything, so it got stuck on “Indexing request queued and waiting…” Disconnecting and reconnecting didn’t work. Jetpack thought it was connected, so it didn’t report an error. (I assume it uses a different library for some things.) Pages were loading the script and the placeholder, but didn’t have suggestions to put there. And of course it wasn’t done indexing, so it didn’t offer a reindex button on the debug page.

What to do:

SSL ciphers are a server configuration setting, not a problem with your SSL certificate, so you don’t need to revoke and reissue the cert. If your hosting provider manages your server, you can ask them to disable RC4. If you run your own server, you’ll need to look up how to disable RC4 on IIS, Apache, NginX, etc. You can verify your site’s settings at Qualys’ SSL Server Test: Look for RC4 in the results and see if it’s labeled Yes or No.

If Jetpack doesn’t start indexing after you change your config, try turning off the Related Posts module and turning it back on. It only took a few minutes before recommendations started appearing on the site again.

There is one downside, which is that some older browsers (specifically Internet Explorer on Windows XP) may not be able to connect. As always, it’s a trade-off.

Ah, memories! These days, setting up hardware on Linux is often easier than it is in Windows. Lots of drivers are built-in and auto-detected, and many are provided through a distribution channel that makes it almost as easy.

Wireless networking, however, is a bit of a throwback to the old days. Half the hardware doesn’t have Linux drivers, and half of the devices that do require you to hunt for the driver — based on the chipset, of course, not on the name or model number on the box — and compile it yourself. (At least these days, you can sometimes run a tool to adapt the Windows drivers if there’s no native Linux option.)

The steps I actually needed to take to set up wifi on my Fedora 13 desktop probably only amounted to about 10 minutes. Unfortunately it took a lot of false starts to get there. I had installed a Zonet ZEW1642 PCI card, which my initial research suggested would be supported by the built-in rt2860 drivers. As it turned out, it wasn’t that simple. Continue reading

The Social Homes plugin for WordPress displays a list of icons linking to your various social networking profiles* as a sidebar widget. When you update your list of sites, it calls out and automatically detects the location of each icon.

Unfortunately, the detection doesn’t work on LinkedIn, leaving your blog with a broken image, empty square or text label, depending on the visitor’s web browser. The plugin developer is aware of the issue, but several months have gone by with no fix.

So I’ve fixed it. Here’s how you can fix it on your blog.

Technical Details

First, some background. The problem is that Social Homes is expecting to see this pattern:

<link rel="shortcut icon" href="/path-to-icon">

But LinkedIn is using this equally valid pattern:

<link href="/path-to-icon" rel="shortcut icon">

This would be okay if it simply failed to find the icon, because it would fall back to /favicon.ico … which happens to be correct for LinkedIn. Instead it’s skipping past the end of the tag and picking up the next reference, which is currently a stylesheet.

The Fix

The simplest fix** is to just make sure it stops at the end of the tag, and let it fall back to favicon.ico.

Here’s what to do. Open up social-homes.php and look for the section titled, “Social Homes service parser.” The function you want is called widget_socialhomes_parse_service

Look for the section labeled, “grab the favicon” and find these two lines:

$tmpIcon1 = split('"shortcut icon"', $contents);
$tmpIcon2 = split('href="', $tmpIcon1[0]);

Add the middle line below, and change tmpIcon1[1] to tmpIcon1a[1] in what’s now the third line:

$tmpIcon1 = split('"shortcut icon"', $contents);
$tmpIcon1a = split('>', $tmpIcon1[1]);
$tmpIcon2 = split('href="', $tmpIcon1a[0]);

That’s it! All you have to do now is go back into your Widgets config, open up the Social Homes widget, and re-save it!

*Technically, you can link to any website, whether it’s a social networking profile or not, but that’s the original intent.

**A more proper fix would be to change the way Social Homes looks for the icon so that it doesn’t depend on the link attributes being in the same order, but this is a simpler change.

Sometime last week I noticed that I hadn’t received some alerts sent by text message to my phone. I figured it was probably a transient problem with the email-to-SMS gateway and didn’t think much more of it. Then on Sunday I added a contact to my address book in Gmail, and it still hadn’t synced to my phone a half-hour later. Again, I figured it was just a hiccup.

Yesterday, some more email-to-SMS texts vanished into the ether. I figured something must be up with the gateway, so I changed the alerts so that they would also send to my Gmail account, figuring that if the text messages failed, I’d still get a notice.

They didn’t show up either.

That’s when I realized that nothing on the phone was actually syncing: Not Gmail, not the contacts, not the calendar…and it just wasn’t receiving text messages at all.

I tried turning sync off and back on, manually syncing, restarting the phone (both a hard reset cycling the power and a soft reset, sort of the Ctrl-Alt-Delete equivalent using the green, red and menu buttons together), even clearing all the local data for Gmail, Gmail storage, and Calendar storage.

Well, none of that worked. It marked all the apps for syncing, but wouldn’t actually start.

So it was time to backtrack: What had I changed recently?

Well, I’d updated several apps. Off the top of my head I could think of Twidroid Pro and the Weather Channel, but I couldn’t remember what else.

I’d also installed a new app, Layar, an augmented reality app which I’d seen in an ad for some other phone last week, but hadn’t actually gotten around to trying out. Adding it triggered a low space warning, but the phone still had 6.8 MB free, which ought to have been plenty.

Curiously enough, the last successful sync was right around the time that I installed Layar. Hmm…

Okay, what the heck. I uninstalled it. Within seconds, the phone bleeped and picked up the test messages I’d sent to Gmail. Within a minute, several text messages arrived, including my test from this morning and two alerts from last night.

Well, that was certainly suspicious.

So I installed it again, and this time actually opened the app to try it out (making it display the location of pizza places as seen from my desk), and sent myself a test message at Gmail. I can’t say I was surprised when the test message showed up on my desktop, but not on my phone, even when I manually refreshed my inbox in Gmail. Within a minute of uninstalling the app again, the message showed up.

So, no Layar for me. I don’t know if it doesn’t work with the G1, with Android 1.6, or with something else I have on the phone…or if it’s not Layar at all, and the phone just needs more space to sync.

The message is clear, though: If your phone stops syncing, or stops receiving text messages, look at what’s changed. There’s a good chance that the problem is related.

Update: It’s been about half an hour, and the voice mail notice just popped up…for a couple of messages I received on Sunday! It looks like the problem was blocking everything that used the standard sync/notify system on the phone. Twidroid was working, so I guess it must use its own system.

Update 2: I’ve confirmed that it’s just the low space, not the particular app, that causes the problem.