Category: programming

Redirect visitors to your new Wordpress blog

You moved your blog to a new domain name and want to redirect everything still going to the old location to the new one.

This applies only if you still have some control over the old server and can put a .htaccess file in, via the control panel or FTP.

.htaccess commands apply only to the directory in which the .htaccess file resides, and all the directories under it - so it’s by far the best that it goes in the same directory as your old blog left.

The .htaccess file

A plain text file where server directives are stored. The server reads it before doing anything else like outputting a page and acts on its commands.

No name, just a dot and an extension - some text editors struggle with this. If you are creating a .htaccess in desktop Windows, say, always use Notepad, or something simple. And set your file explorer to display hidden files, while you’re doing it.

The basic command is simple

Redirect /olddir http://www.newdomain.com/newdir/

But this will do a temporary redirect (status 302) which search engines do not like - it’s long been favored by spammers, so we need a 301 status code.

Redirect 301 /olddir http://www.newdomain.com/newdir/

(or

RedirectPermanent /olddir http://www.newdomain.com/newdir/

does the same thing).

Mapping the old domain to the new - mod_rewrite.

This requires the PHP mod_rewrite module to be installed and active on your server. It usually is - you can check the php_info in your control panel, or just try it and see if it works.

Again, in your .htaccess file

Options +FollowSymLinks
RewriteEngine ON
RewriteRule ^(.*)$ http://www.newdomain.com$1 [R=301,L]

You need the first two commands to get mod_rewrite going

The ^(.*)$ is an example of a regex, or regular expression. Complicated things, but this one essentially captures a path, any path, into a reference $ which is then used in the second part of the command as $1

[R=301,L] the redirect is to be a status 301 http request and the L is for last command - we’re finished…

Unless you want to redirect all requests, regardless of the page requested, to the index page of new domain, in which case:-

RewriteRule /.* http://www.newdomain.com/ [R=301,L]

That is it - upload the .htaccess to the old server and see if it does what it’s supposed to. (It probably won’t, these things rarely work first time - but stick at it…).

Related resources:

Megaboring, but total explanation of mod_rewrite

(If you’re looking at this tutorial in 800 x 600px the commands have been kept on the same line with non-breaking spaces where necessary - you might need to go up one resolution)

Ajax - when to stop

ajax.jpgThe issue of Ajax continues. To be honest right at the beginning - I am not a fan of Ajax. Or rather, not a fan of the fashion for Ajax. It’s an easy trap to fall into - Gopher space was fashionable.

The sidebar widgets scheme of WordPress provides a good testbed for the adoption of Ajax - it has all the salient pros and cons.

It’s excellent if all you want to do is fill in text boxes and shuffle things round a sidebar - flexibility within it’s own terms, absolutely. And, to be pragmatic, this is going to suit 80% of WordPress users. Which is why it’s there.

It’s not great if you want to keep XHTML valid at all costs, or if you wish to make any changes to the default sdout (and this is why the old javascript-less sidebar remains).

To be sure, the situation has improved from when the handling of Ajax by browser was sporadic, and when 30% of visitors complained of being unable to use a site properly. Hardware with less competent browsers, ie, handhelds etc, which are supposed to be the scene of expansion, are going to struggle for the forseeable future unless more thought is given to how pages degrade.

Instinctively, I suspect that that’s enough Ajax for now. I quite like pageloads - they do have their advantages, a nice, clean slate to start with.

Ajax remains dangerous and requires to be used with the utmost caution.