skip main content

Posts Tagged ‘Wordpress’

RevCanonical 1.2, Customise your link tag plus a little more

posted by Duncan at 10:33 am on April 23rd, 2009

I’ve made a few updates to the RevCanonical WordPress plugin I built. These updates add a bit of extra functionality, and also allowed me to tidy up the documentation, so that people know what they’re getting.

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="" />

but you could customise it to be like this:

<link rel="shorturl" href="" />

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 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 version.

Revcanonical, a rev=canonical WordPress plugin

posted by Duncan at 11:06 am on April 14th, 2009

UPDATE [15:06 April 14th 2009]

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 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="" />

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:

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.

In fact, you would in reality get this:

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, 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.

Deploying WordPress to SliceHost using Capistrano and Git

posted by Duncan at 12:00 pm on February 1st, 2009

Skip straight to the how-to if you don’t care about an introduction.

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:

    + 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, ""
set :user, "websites"

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


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


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!

TweetMe – Another simple WordPress plugin that Twitters

posted by Duncan at 6:37 pm on January 24th, 2009

[UPDATE] Twitter have now turned of HTTP authentication which means until the plugin is updated to use the OAuth, it won’t work. I haven’t got time to update the plugin right now, but will when I do. In the mean while, the plugin code is available on github, so maybe someone else could add this support. Thanks.

[UPDATE] If you install my new revcanonical plugin, then TweetMe will use auto generated short urls from your own website, instead of going to a 3rd party site.

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.

Updated to WordPress 2.6

posted by Duncan at 1:11 pm on August 1st, 2008

It’s that time again. I knew I had to upgrade at some point, due to the fact I was running WP 2.0.2 which is getting very old. The problem was that migrating was going to be a real pain as the DB had changed quite a bit, and there is no export feature on 2.0.2.

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.

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

Deploying wordpress using capistrano

posted by Duncan at 2:47 pm on May 21st, 2006

[update] I have written a new post called Deploying WordPress to SliceHost using Capistrano and Git, which uses new versions of Capinstano and WordPress, and although also now uses Git as the SCM, may still be useful.

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:

  |- 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, ""
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
# 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/" 

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!

back to the top