First update, is the ability to customise how the link tag is constructed within the head of your page. This is due to the large amount of people who have contacted me, asking why I choose to use rev=canonical and not rel= shorturl, rel=shorturl or rel=short_url etc. As I told them, the reason I chose rev=canonical was to be honest simply because I liked it, and many of my peers were already using this method on their sites. Simple.

So currently with the plugin you get this out of the box:

<link rev="canonical" type="text/html"  href="http://your-domain.com/p12p" />

but you could customise it to be like this:

<link rel="shorturl" href="http://y-doma.in/p12p" />

The reason for this extra customisation is to try and stop people being distracted by the what attribute should I use conversation, and start getting them hosting their own short links they can use. This at least starts solving one problem. When a general consensus, or in deed a standard appears about the attributes, you can simple update and you’re good-to-go.

At the moment the only place you can see the shortened url is either by looking in the source, or using a bookmarklet like the one Simon wrote. I guess I could of injected the url into the admin interface somewhere, but I generally don’t want to see it. The idea is, it’s there for machines to see if they need to, and if I really need to pass it around I’ll just use the bookmarklet.

If you want more flexibility, I have added a of a couple of tags you can use in your templates. These simply let you display the shortened url for a specific post.

# echo the shortened url to the screen
<?php get_revcanonical_shorturl($post_id); ?>
 
# assign the shortened url to a variable
<?php $url = revcanonical_shorturl($post_id); ?>

Oh and finally, just a reminder that this plugin plays well with the TweetMe plugin I wrote that tweets to Twitter.com when you publish a post, and will check to see if you have the RevCanonical plugin installed. If you do, it will use your own shortened url instead of the bit.ly version.

Revcanonical is a WordPress plugin that creates localised shortened urls, and adds support for the rev=canonical link tag.

Revcanonical came about after seeing a post on Mr Willison’s website a few days ago. I’d seen mutterings around the web from Joshua Schachter, Dave Winer and Chris Shiflett about how url shortening services are not great for the web for amongst many reasons, the persistence of the link becomes questionable, because you are relying on that service actually being around in 20 years.

It seems that clever people have taken the conversation further and have actually started to come up with possible solutions. One such solution is rev= canonical, and is the one I liked and hence wanted to implement into my site. In fact, some of the big players have already added rev=canonical to their sites. Flickr, Dopplr and php.net already have pages that use it and there’s even a rev= canonical web service. That’s millions of pages already out there.

By default, once you install the plugin to your WordPress blog, you will get a tag added to the source of your page that will contain a shortened version of the url for the page it sits in.

<link rev="canonical" type="text/html" href="http://whomwah.com/p12p" />

That’s it! You can now, not only use this url in sites like Twitter without having to go via a url shortening service, but services or people that understand the rev=canonical link tag, will be able to use this shortened version over the longer canonical version. For example, Simon has build a great bookmarklet that does just this. You can use it when you are on a url you’d like to share. It will return the shortened version of the url if it’s available, otherwise it will use a shortening service as a last resort. This means that if I go to this page:

http://whomwah.com/2009/04/14/revcanonical-a-revcanonical-wordpress-plugin

And I want to share this link on Twitter for example. The bookmarklet would see I have implemented rev=canonical and would fetch the shortened url.

http://whomwah.com/p136

In fact, you would in reality get this:

http://littl.me/p136

as the plugin allows you to add your own shortened domain (and I bought one). It’s up to you though point this new domain to the right place.

So, this means that I still get a short url to share, that works on my website, but also means that it’s persistence is down to me, and not to a 3rd party. It also means that if people to http://littl.me, it redirects to my website, so hopefully there’s a little more trust in the shortened url final destination.

Some final tech bits. It uses a base36 encoded post ID (made sense and was simple to implement) in the shortened url with the letter p to namespace. It also creates a 301 as the general consensus agreed.

Oh and if you use the TweetMe plugin I wrote then I’m just in the process of deploying a new version that will use your localised shortened link if it’s available.

[UPDATE] I’m getting lots of people asking why I went for rev=canonical and not rel=shortlink etc. The truth is no particular reason, other than more people I knew and trusted have gone for the former. There appears to be no definitive correct way yet as far as I can see, so until there is I’ll have to make an executive choice.

This post has been in my drafts folder for about 6 months, and I intended to be much more detailed, but I don’t think I’m gonna ever get round to it, so here is the shortened version.

I did a post a while back on how to deploy WordPress to TextDrive using Capistrano, which people seemed to find useful. I still use WordPress, and I still find Capistrano perfect for deployment in this situation. They’re the only two constants though, as I have now changed hosts, changed source control systems, oh and Capistrano has jumped up a major release and many minor releases, so the interface is slightly different.

I moved over to SliceHost because I wanted the control that virtual hosting gives you, and those guys are cheap, as well as having an awesome service thus far.

The actual installation of Apache, MySQL and PHP is quite simple through YUM and well documented via the Slicehost support area so I won’t repeat this. I also moved over to Git a while back, after researching distributed source control systems, and playing with Mercurial for a while. Git just seemed to tick more boxes for my current needs both at work, and home play.

1. Assumptions

I have based the post on the fact I choose to put all the sites I deploy in a my home directory. Some other assumptions are:

• You have Apache, MySQL and PHP installed
• You have an account on the machine with sudo access
• You have a Git installed on the machine you will be deploying from

Now you need to organise your wordpress source into this structure:

README
Capfile
public/
    + index.php
    + wp-admin/
    + wp-xxxx
     etc ....

2. Configure Capistrano

You can download my basic Capfile that should help get you started. The only things you will need to change are :domain and :user. For example, for my site I may use:

set :domain, "whomwah.com"
set :user, "websites"

This would mean that I can normally access my server using:

ssh websites@whomwah.com

3. Initialise your Git repo

I kind of expect you to have already done this, but if you haven’t, change into the root directory (The one with the Capfile in it) and run:

git init
git add .
git commit -a -m 'initial import into Git'

4. Deploy

You should now have enough initial information to let Capistrano deploy WP to your server. First though, you need to run the Capistrano setup command to stick a bunch of folders on your server ready to hold your site. This is a good test command too as it lets you know if you have setup your :domain and :user ok.

cap deploy:setup

If that went ok, then you can now run the mighty:

cap deploy

That’s it! you should now have your blog deploying to your server.

5. Apache setup

All you need to do now is setup Apache to point to the folder. You can use this vhost file. Rename it and edit it’s contents to suit your site, then stick it in your

/etc/httpd/conf.d/

folder. Restart Apache:

sudo /sbin/services httpd restart

Now browse to your sites url and to the admin area and setup your blog as per the WordPress instructions. Best of luck!

I’ve written a simple little WordPress Plugin to get me moving again. TweetMe posts a tweet to Twitter when you publish a blog post.

If you do a search on Google there are loads of similar plugins out there. The problem is after trying a few, none of them did what I wanted, and many of them seemed far to complex for the task in hand. I simply wanted this. Nothing more, nothing less:

• I enter my Twitter credentials once and they get validated.
• I decide how I want my tweet to look.
• When I publish a new blog post, it gets sent to Twitter.
• If I update that post, I don’t want it resent, unless I choose.
• That’s it….

So that’s all TweetMe does.

• Visit the TweetMe project page
• Download TweetMe from wordpress.org

Anyway, it’s done now, and I’ve given the site a bit of a refresh and dressing down. I liked the new look straight away, which is a change. The theme is available to download (v1.0.1) from gitHub.

You can get the scripts I used to upgrade if you like. They are not supported and might not make too much sense, but they might be a good starting point if you need to do a similar migration.

• Migrate wordpress 2.0.2 to 2.6 scripts

Any comments about the new design, or bugs etc, duncan @ the name of this site

So I was running typo up until last week. I was gradually getting more and more hacked off with it’s problems, and decided to change over to WordPress. I feel like I’ve ran every blogging tool out there, but WordPress is the most polished I’ve seen so far, and I’ve a PHP background which helps.

Don’t get me wrong, I’m loving Ruby and RoR ( Hell, it’s all I’m doing at the moment at work ) but I just want to post stuff up fast and easily, and also make changes to the blog and post them up fast and easily. After reading this article on nubby on rails, I decided to try it with wordpress. I’d been using Capistrano to deploy my old Typo blog and at work we use it to deploy all our apps. It really is a clever bit of kit and I wanted to continue to use it even though I was not gonna be running a RoR app.

Well, no problem. Although Capistrano makes a bunch of assumtions i.e. you are running a RoR app, you are using Fast CGI etc you can overide all this stuff.

First, what I wanted from all this:

1. Easy deploy and re-deploy of my WordPress blog
2. The image uploads when posting stuff to be seperate from the app. This is so I could override the app whenever I wanted without having to worry about overwriting all the images

Step 1.

Created a folder called wp_<app_name> and stick a public and config folder in there. Put all the files and folders that make up wordpress into the public folder. In the config folder you put the deploy script. You can either use one created in a rails app ( this gives you lots of comments on what the various sections do ) or you can just create a file called deploy.rb and stick all the code in Step 2. inside. How I got this file the long was was creating a dummy rails app and running cap -A . inside to get the default deploy.rb created for me in /config/deploy.rb.

rails dummy_app
cd dummy_app
cap -A .
mv config/deploy.rb /path/to/wp_app_name/config/
cd ..
rm -rf dummy_app

Now you should have the file/folder structure as below. This is mine:

wp_whomwah
  |- config
  |    |- deploy.rb
  |- public
  |    |- <your wordpress files>

Step 2.

Edit the deploy.rb file to suit your setup. I changed the information in the various sections as seen below:

set :domain, "www.whomwah.com"
set :application, "wp_whomwah"
set :user, "duncan"
set :repository, "http://#{domain}/svn/repos/trunk/#{application}/"

role :web, "#{domain}"
role :app, "#{domain}"
role :db,  "#{domain}"

set :deploy_to, "/users/home/#{user}/sites/#{application}"
# setting use_sudo to false means you can use
# cap cleanup ok without needing to be a sudoer
set :use_sudo, false

desc "This is here to overide the original :restart"
task :restart, :roles => :app do
  # do nothing but overide the default
end

# create a symlink to where I store all my images on
# the server. 
desc 'Link to central uploads folder'
task :after_symlink do
  run "ln -nfs #{deploy_to}/#{shared_dir}/uploads/" 
    "#{deploy_to}/#{current_dir}/public/wp-content/uploads"
end

Step 3.

You should now be ready to go. Check all this stuff back into SVN and the you should be able to run:

cap setup

You might want to look on your server to make sure capistrano has created your app and all the folders in your :application path as stated above. Once you are happy it’s there and in the correct place you can run:

cap deploy

this should then checkout a copy of your app from subversion and stick it in the releases folder. It will also create a symlink called current, pointing to the latest deployment. It is this current folder that you need to point the server at when displaying your site.
Update: I have stuck up a copy of the deploy.rb file I use. It differs slighly from the one above. When you run the cap deply line it will:

1. deploy app
2. symlink uploads folder
3. dump a backup of the db
4. run cleanup to leave a max of 5 releases

Happy Deploying!