Moving my photo site to a new URL and server

This post is pretty much just a note to self (I tend to have to relearn how to write Apache rewrites every time I use them), but I thought it might be useful to others as well.

A few months ago I set up a Twitpic-esque WordPress site for hosting my mobile photos. Since then, the shared hosting space where the sites lives has been filling up, so I don’t have much storage left, and I’ve also gotten a sweet new domain name. So this morning I took a few minutes to move the existing WordPress site (, part of a WP network at and to, on another server. Here’s how I did it:

  • Use the WP export tool (Dashboard > Tools > Export) to get an XML of the old site data (on
  • Create a new, empty site (
  • Import the content of the old site (Dashboard > Tools > Import > WordPress)
  • Move my custom theme (and its parent theme) to the new server, and activate it for the new site
  • To make sure that old links to* are redirected properly, put the following in .htaccess on the old server:
    # These two lines have to be somewhere near the top of your .htaccess
    RewriteEngine On
    RewriteBase /
    # Redirect old photo URLs
    RewriteCond %{HTTP_HOST} ^$ [NC]
    RewriteCond %{REQUEST_URI} photos/*
    RewriteRule ^.*${REQUEST_URI} [R=301,L]

Because the main purpose of this site is to post from my mobile phone, I also had to change the settings in my WordPress Android app. It doesn’t look like this app allows you to change the URL of an existing site, so I just deleted the one I already had on the phone and added the new one, being sure to enable XML-RPC access first, at Dashboard > Settings > Writing.

Done with Apple

In my 2010 year-in-review post I made a passing mention to my decision not to buy any more Apple products. Most people who know me can probably guess the reasons behind the decision, but recently I’ve had some discussions that made me think that it’s worth a blog post to spell them out.

First is my ongoing project to move away from proprietary software in general. All things being equal, it’s better to use software whose source code I can view and modify; even if, in fact, I never do these things, the fact that I could is a kind of safeguard against a number of frequent aspects of closed-source software: data lock-in, data rot, restrictions on hardware compatibility, secret surveillance, etc. As the operating system is in many ways the foundation of all other tasks I do on a computer, so it is of fundamental importance to use an open OS.

Second. I believe in the Web as an open platform for communication and expression, and Apple is increasingly anti-web.

You often hear hoopla about how digital technologies can radically democratize and transform x (fill in your favorite x: scholarship, education, publication, politics, etc). The success or failure of these transformations is tied up with the Web’s openness as a platform: open standards like TCP/IP, enablers of decentralization like distributed DNS, free software like Linux and Apache to run servers. Putting any of these technical details under the control of a single agent, especially a corporate agent that answers only to shareholders, threatens to limit free expression and disenfranchise vulnerable groups of potential users. If a robust, widely-used, open Web is important to the future of equality and democracy, and if such a Web can only be defended by keeping out proprietary interests, then it’s important to fight against interference from those interests.

I take it as fairly obvious that Apple (and not only Apple, though they seem to be the trendsetters) is anti-Web. Consider their distribution models. iTunes makes it so that you have to buy apps, music, and movies through an application, rather than through web pages. Know that annoying “feature” where, when you click on an iPhone app link on the web, you get a page informing you that you’ve clicked on an iTunes link, whereupon iTunes proceeds to open? That’s anti-web. The increasing focus on “apps” is a more troubling anti-web move. As was nicely illustrated by an article I read a while back (can’t find the link), you can spend a whole day doing stuff on an iPad – using Twitter, Facebook, WordPress, Yelp, email, Google Maps, etc – without ever viewing a web page (though they all use web services that use HTTP as a transport). In this way, Apple is doing an end run around the web.

The nature of the end run is particularly troubling. Apple is the arbiter of the software that runs on its devices (completely, in the case of iThings; increasingly, in the case of the AppStorified Mac). This creates unnecessary bottlenecks when it comes to bugfix or security releases. It creates a single point of failure for apps and therefore for devices; if Apple goes under tomorrow (or, more likely, changes their mind completely about whatever they please), how will you continue to update your apps? Worst, it puts Apple in the position of policing for content, which, whether driven by a well-intentioned desire to avoid offensive content or by a malevolent puritanism, is a Bad Thing.

Anyway, all of these points have been made over and over again, by many different people. My own bottom line: I believe in the value of the open web to such an extent that I’ve devoted my career to it. Thus, it feels wrong to keep using, and indirectly encouraging the use of, technologies like Apple’s. That goes especially for iOS and its devices, the area where I think the threat to the web is worst. But it extends to the Mac as well. Even if you maintain that the Mac will never merge into iOS (a position I find disingenuous), there’s no question that spending money on Mac hardware is a way of indirectly feeding the beast. Next time I buy a laptop, I’ll be sad not to be getting a pretty MacBook, but, on balance, I feel more comfortable giving my money to a hardware manufacturer that’s less pernicious.

For what it’s worth, I don’t think that mine is a decision that everyone must, or even should, make. Using Apple products brings pleasure to a lot of people, even people who largely share my ideologies about the free web. It’s perfectly legitimate to decide that the benefits you get from using those products outweigh the downsides. But, for me, it’s past the tipping point, which is why I’m done buying Apple products.

Shorten your own dang URLs

In my last Project Reclaim post, I talked about using WordPress as a Twitpic-like personal mobile photo service. When the ultimate goal of the photoblog is to send a tweet, it’s almost always necessary to use a URL shortener. But trusting your URL shortening to a free service is a dangerous move. If that service goes out of business, or if they decide to take down the database for some reason or other, the links in those tweets will break. (This problem is delightfully called “linkrot”.)

So, while URL shorteners are sometimes necessary, they’re also an obvious instance for reclaiming your data. Moving to your own URL shortener means that you control the domain, you control the content, you can back up the database however you’d like, etc.

I went with a piece of software called YOURLS. It’s written by Ozh Richard, a WordPress developer, and there’s a slick WP plugin that makes it a great choice for use with my WP photoblog. Here’s a short walkthrough of how I set it up.


  • Get a domain. Something short is nice, obviously. I just started typing two- and three-letter domains into my domain registrar’s search box (I use Dynadot), which showed me the top-level domains available, until I found one that was easy to look at and remember ( Make sure you do whatever setup your registrar requires to get the domain working – probably as simple as setting the nameservers to your host’s NS addresses.
  • Install YOURLS. The instructions provided at the YOURLS site are pretty concise, but here’s the gist: upload the software to the server, create a new database, copy the sample configuration file to user/config.php, and fill in the configuration file with the proper database info, etc. You can get more YOURLS config info here.
  • Configure an Apache virtual host, if necessary. If your hosting provider doesn’t have cPanel or some other tool that easily lets you point your new short domain to a subdirectory, you’ll need to do it manually by creating a new Apache virtual host file and activating that site. This website has a pretty good explanation. But essentially, just copy the default configuration in sites-available (likely at /etc/apache2/sites-available) and change the info in the VirtualHost section.
  • Install the WordPress plugin. The YOURLS: WordPress to Twitter plugin is easy to install and set up. Once the plugin’s installed, go to Dashboard > Settings > YOURLS and fill in the necessary information. Setting up the Twitter bit is a pain, thanks to Twitter’s requirement that you get a developer’s key, but it’s easy to do. Just follow the on-screen instructions.

At this point, everything should be set up. Send a test post or two to try it out.

Bonus! Use me with Tweetdeck

YOURLS has a REST API that can be used with a bunch of applications. For instance, I’ve configured my TweetDeck installation to do its URL auto-shortening with Go to Settings > Services and choose Other from the URL shortener dropdown. Your endpoint will look something like You’ll have to replace with your own URL, of course, and the XXXXXXX signature with a custom YOURLS signature password. You can get it from the YOURLS admin screen ( > Secure passwordless API call)

Here’s the great thing. There’s no reason why a couple people can’t share a single YOURLS installation. In fact, I’ll put my money where my mouth is, and start my own URL shortening co-op. I’ll give usernames/passwords to to the first couple friends who want in. Send an email to boonebgorges at gmail if (1) you are my friend, (2) you want in on, and (3) you promise to actually use it and break the habit.