Publishers Shorten Yourself

The Wege pointed me to an excellent article by Joshua Schachter on the issues w/ URL shortening services.

It’s consistent my concerns and my Insecurity of Short URLs post.

As I alluded to that post, I see 3 opportunities for URL shorteners, all of them revolve around increasing trust (branding, security, backup).

Let’s take that first one – branding. Another name for branding is accountability. Who really knows where a tinyurl a similar service will point you, but you can be confident a URL will point you to an article on and a URL will point you to something I authored.

From my perspective there are 3 parties that should have a good short URL corresponding to their identity:

  • the author (i.e.
  • the publisher (i.e.
  • the share-er (imagine a link blog of short urls)

Sometimes all 3 are the same.

Conveniently, as greater accountability is introduced to short URLs, the issues of security and backups address themselves.


Take one step back.

Web publishing engines – like WordPress, MovableType, and all publications engines really – should automatically generate nice long human-readable URLs as well as a short, easy-to-share URLs (at least the URL keys, you can supply your own short domain if you want). (Dave Winer said this last month in “Solving the TinyUrl centralization problemsomething along these lines a few weeks back, but I can find the link right now)

One more step back, and you can see this is only an issue now because of the growing popularity of 1 specific website and an expectation that these short URLs are permalinks. If you don’t have that expectation, shorten with RE07.US

iPhoto to WordPress Ruby Script

I maintain a WordPress blog that’s primarily an extension of iPhoto, and the various iPhoto plugins (Photon by Daikini, Photon by Orby, WordPress Export) I’ve tried over the years seem to have stopped being maintained, stopped working, or both.

Which is fine, they never worked exactly the way I wanted them too anyway.

So, I wrote one.

In Ruby, with some help from rb-appscript

Unlike like the other iPhoto export options, this one lives in your Scripts menu and automatically creates (and opens!) a draft post containing all the selected images.

Download send_selected_photos_to_wordpress.rb

“It’s surprisingly short and effective.” – Peter Cooper

WordPress 2.7 xmlrpc.php Monkey Patches

I’ve been fighting with WordPress 2.7’s xmlrpc.php file for a few days now, and I’ve made 2 modifications that may be useful to you.

If you’re writing new posts via metaWeblog.newPost and the angle brackets from your HTML formatting are being stripped out (as described in this official WordPress bug report) and you’d rather not rebuild PHP on your server (who does?), open up xmlrpc.php and replace:

$post_content = apply_filters( 'content_save_pre', $content_struct['description'] );


$post_content = apply_filters( 'content_save_pre', $content_struct['description'] );
$post_content = str_replace('lt;', '< ', $post_content); $post_content = str_replace('gt;', '>', $post_content);

This should replace the stripped angle brackets with actual, functioning angle brackets.

Secondly, if you’re having trouble uploading files via metaWeblog.newMediaObject, try this fix (big thanks to Keith Garner). In xmlrpc.php replace:
$bits = $data['bits'];

$bits = $data['bits'];
$bits = base64_decode($bits);

WordPress has given me quite a roller coaster ride these past couple years. While 2.7 is a huge improvement over the last couple releases, if I wasn’t so committed, I’d be looking for something much leaner.

Update 30 Dec 2008
Big thanks to Daniel Jalkut for commenting that the reason I needed $bits = base64_decode($bits); was probably due to my bits not being properly encoded. Correct he was. So, rather than a bug in WordPress, this is a bug in Applescript (what isn’t) and in Ruby’s XMLRPC/client for failing the Principle of Least Surprise (if the spec says the tag is <base64>, the tag should be <base64> not <string>).

To get the <base64> tags in Ruby, you need to encode with not simply Base64.encode(the_file)