I’ve had a string of technical difficulties lately, some with regard to my website, some with regard to my on-going backup efforts.

On Monday my webhost upgraded the version of PHP running on the server. Unfortunately one of the plugins (not the one I wrote, phew) I was using was incompatible with new PHP. It was relying on a technique that was so insecure, the new compiler catches identifies the problem and refuses to execute the script. The problem is, this effectively brought down my blog.

Even though I had plenty of warning, I didn’t get around to checking my blog until yesterday.

Ouch. Those stats do not make for a happy Sarah.

At least it’s back up now. The offending plugin has been removed.

The other technical battle I’ve been fighting is getting my backup system setup.

The first problem was with our ISP. Our download rate dropped to 2.5 mbs (megabytes per second), a mere 5% of the promised rate. As much as I would love to blame my ISP, I’m not sure it’s entirely their fault. Living in an apartment in the heart of silicon valley, I’m sure there are a number of start-ups within 50 feet of our apartment. One of them could be saturating the line. Of course the onus is still on the ISP to deliver what’s promised, so they’re not off the hook either.

What does a cruddy internet connect have to do with transferring files on a home network? I’m glad you asked that question! Apparently in order for our home network to work (also set up by our ISP), our modem needs to connect to the outside world. That’s a bit like living on an island, and driving over the bridge to the mainland and then coming back any time you want to go anywhere else on the island. It’s that stupid. With our connection being so slow it would time out, and with the bridge to the mainland down, those files weren’t going anywhere.

The second issue I had was with crash plan itself. I’m using multiple external hard drives for my backup. All hard drives have a UUID (Universally Unique Identifier). It’s a way of identifying the drive. Crash plan identifies a drive not by it’s UUID, but by the drive letter the disk has been mounted to. The problem is the drive letter can change and is usually assigned in order of the drive’s being mounted. A system restart can change those drive letters! That’s like running a pizza delivery place and identifying your customers with phone in orders based on their arrival time rather than their name.

This last one was fixable by manually assigning the drive letters, it just took a while to realize what was wrong. At least I’m making progress. I finished sorting through one external hard drive. Four more to go through.

In my never ending quest to learn about the business of blogging I recently stumbled onto FTCs rules for .com disclosure. I had previously setup a disclosure page, and often mentioned the types of revenue from my blog (namely Adsense and Amazon Affiliate links), but I realized I could do better.

The basic premise from the FTC’s release is that any visitor should know a link is sponsored, before viewing said link, regardless of what device they’re on.

With roughly 300 posts I didn’t relish the idea of labeling every post or link by hand. Manual processes like these are prone with errors, and I was sure to make one. A better solution was a plug-in to automate the process. Since I only use one affiliate program, it’s a pretty simple to automatically parse my blog posts looking for affiliate links. Alas, the only affiliate plug-ins I found were designed to cloak (i.e. hide) the fact that a link was an affiliate link – the exact opposite of what I wanted to do! I finally had an excuse to write my own plug-in.

Writing the plug-in ended up being easier than I thought it would. The harder question was coming up with a labeling scheme I liked. I didn’t want anything to interrupt the prose of the post. I decided to go with an “affiliate link” title to all affiliate links’ <a> tags. Now when you hover your an affiliate link, you see a little pop box that properly identifies the link. I’ve seen this method used before, namely by babycheapskate.com. I’ve verified the title also appears on my blog posts in bazqux.com, and feedly.com.

There is just one problem.

The devices used to view my blog in 2013

Over half of my web traffic is coming from a mobile device or a tablet and there is no concept of “hover” on such devices. Affiliate links are still unlabeled on these devices. Since I wanted to minimize the time I was not compliant with the FTC, I decided to bite the bullet and add a disclaimer to the top of each blog post using my plug-in. I hope to come up with another solution in the future.

Side note: Apparently there’s a belief out there that search engines will demote pages with affiliate links, hence the prevalence of affiliate link cloakers. While I have no first hand knowledge of the truth of this, it feels like an old wives tale to me. In fact, cloaking is probably counter productive. It’s trivial for a computer program to find where a cloaked link leads. If there’s one thing I’ve read about SEO time and time again, it’s engaging in deceptive practices, like cloaking, will eventually negatively impact your ranking.

In what I am sure is mostly boring website news, the first cut of a mobile theme for my blog is now live.

One of the nice things about wordpress is the availability of plug-ins. There’s a plugin for just about anything. Problem was, non of the plugin’s did exactly what I wanted. I decided to go with mobile-smart since it got me the closest to where I wanted to be.

The key functionality I wanted included:
– Have two themes, one desktop one mobile ( ✔ )
– Allow mobile users to switch to the desktop theme ( ✔ )
– Allow mobile users to switch back to the mobile theme ( ermm…)

So what’s a computer scientist to do? Crack open the code of course!

Original code (paraphrased) for creating links to switch between themes

$is_mobile = $this->switcher_isMobile();
if ($is_mobile || $options[‘allow_desktop_switcher’]) // (1)
{
    …
  if ($is_mobile) { // (2)
    … //(code to write button/link to switch from mobile to desktop)
  } else { // (3)
    … //(code to write button/link to switch from desktop to mobile)
  }
}

The function $this->switcher_isMobile(); returns true if the user is currently viewing the mobile template. The parameter $options[‘allow_desktop_switcher’] is a flag indicating whether any user is allowed to switch to the desktop version from the mobile version.

Since I don’t want desktop users switching to the mobile theme, I need to set that flag to false. That means the only way to enter the first if clause, (1), is if $is_mobile is true. But then there is no way to enter the else clause, (3). A link to switch back to the mobile version is never created. A mobile visitor can return to the mobile version, but only after shutting down their browser and starting a completely new session.

My Change

$is_mobile = $this->DetectIsMobile();
$is_mobile_shown = $this->switcher_isMobile();
if ($is_mobile || $options[‘allow_desktop_switcher’]) // (1)
{
  …
  if ($is_mobile_shown) { // (2)
    … //(code to write button/link to switch from mobile to desktop)
  } else { // (3)
    … //(code to write button/link to switch from desktop to mobile)
  }
}

Green indicates changed lines

In the above code, $this->DetectIsMobile(); returns true if the visitor is using a mobile device, regardless of which version the user is currently viewing. Now, the if clause at (2) is entered if the visitor is viewing the mobile version, and the else clause, (3), if viewing the desktop one.

It’s a very small change, almost not worth a blog post. I know at some point I’ll update my plugins and probably lose my edit. At least now I can easily find & redo what I did!