Now I have a local web server running on my Ubuntu powered desktop—complete with a local version of my site, and proudly powered by WordPress.

Update: You’ll need to set /var/www folder writable by server: sudo chmod -R 755 www.

Credits: Much of the LAMP installation part was referred from this simple and excellent Howto Forge article. I’ve skipped tasks that are now automated; and added those that weren’t covered in the referred article.

1. Here, username is your login name on the computer; typically username@computer that you see when you open a Terminal window.

I login to my site via ssh, and navigate to the root of my WordPress installation, and run tar to archive (zip) the entire wp-content folder:

$ tar -zcvf allwpcontent.tar.gz wp-content/

This above creates a file named allwpcontent.tar.gz.

Now still over ssh, I start sftp and navigate to the root of my WordPress installation (again). From there, I download the zipped file:

sftp> get allwpcontent.tar.gz

Downloading the entire wp-content by zipping (or tarring) first is so much quicker than downloading the entire folder—file by file; and easy too.

Pre-requisites: You’ll need secure shell access to your host, and your host should have enabled svn client.¹

All bets are off if you don’t backup everything—every file, every customization, as well as your database—first. As an added insurance, go to the WordPress admin Dashboard → Manage → Export, and dump an XML export file. Also, deactivate all plugins. I’m saying this because you won’t regret if things go wrong.

Preparing for svn magic (the first time.)

Login to your host like this²:

$ ssh userid@website.com

You’ll be prompted for the password. Key it in and press enter. If you were able to login, then you’d be in the root of your host. This will typically be like the following or something similar:

/home/userid

Type pwd to know where you are. In most cases, you’ll see a path like the above. Navigate to the folder public_html:

$ cd /home/userid/public_html

In some cases, instead of public_html, you’ll see www or html folder. Let us assume in this case, we have a folder called public_html. List the contents of the folder:

$ ls -al

If you see your wordpress installed files and folders here, then this folder is the root of your wordpress installation.

(If you have it installed in a sub-folder like blog—for example, then further navigate to that folder: $ cd /home/userid/public_html/blog)

Copy entire contents of your WordPress installation root into a folder, say, backup—like this at the prompt:

$ mkdir backup
$ cp -R wp* *.html *.txt *.php .htaccess backup/.

Now in WordPress installation root, run this to remove all the existing wordpress files and folders:

$ rm -R wp* index.php xmlrpc.php readme.html license.txt

Installing a new copy of WordPress using Subversion

Now type this command and hit enter³⁴:

$ svn co http://svn.automattic.com/wordpress/tags/2.3.3/ .

This command “checks out” the release 2.3.3 from WordPress stable repository on to your host.⁵

Now, add all your custom plugins, themes from the backup folder into this checked out release’s wp-content folder. Copy back wp-config.php and robots.txt files from backup folder into the root of your wordpress installation. Note: All this you’ll need to do only once ever.

Upgrading to the latest version

To update your installation, run the following command:

$ svn up

To switch to a newer release, say 2.5 for example—whenever it becomes available in the near future, you’ll only need to run this command—in the root of your wordpress installation—and your WordPress installation will be updated instantly:

$ svn sw http://svn.automattic.com/wordpress/tags/2.5/

To complete the upgrade, run the following in browser’s address bar:

http://yourblogaddress/wp-admin/upgrade.php

Replace yourblogaddress with your actual site address, and your WordPress installation will be updated to the latest release. You may now enable all your plugins back again.

Once you have an svn based install, you’ll only need to the last two steps to upgrade to future latest releases; and it upgrades in seconds!⁶

There are other posts about installing upgrading WordPress via svn—you might want to refer to, notably these two:

• Updating WordPress with Subversion.
• Automated WordPress Updating.

svn rocks. Learn it. Use it. Love it.⁷

1. If you have shell access to your web host, you can check this by typing the following at the prompt and enter: svn --help. If it spits meaningful information, then you’re good to go. Dump those sad hosts that don’t provide you with these basic features.
2. userid and password would be same as those you’d use while using FTP; Replace userid and website.com with your actual userid and your website address.
3. The period at the end is mighty important, or else you’ll end up downloading all the files at a folder named 2.3.3. Presumably you wouldn’t want this.
4. If you prefer the latest “bleeding edge” version, then use the trunk address instead: svn co http://svn.automattic.com/wordpress/trunk/ .
5. Think co as in checking out your shopping cart at a free counter. up and sw are like the store home-delivering you product improvements—again for free.
6. Notice that in this entire process, we have barely used three commands that are needed to upgrade your actual installation, while much of rest is first-time preparation, and a couple of precautionary measures. Once you get the process, you can see how dumb, and disturbingly simple this is in installing/upgrading WordPress!
7. With apologies to Mark Pilgrim.

This to backup¹ all files from my site to my local machine:

rsync -avz -e ssh remoteuserid@mysite.com:remotepath localpath

And from my local machine to my site:

rsync -avz -e ssh localpath remoteuserid@mysite.com:remotepath

remotepath would be something like this: /home/remoteuserid/public_html, and localpath would be like this: /home/localuserid/backup/public_html.

Damn it’s fast.

1. I don’t do a cron job of a file backup and restore—I get knots in my stomach. Call it personal preference, but I prefer it manual; and this is mostly because of my file-scatter, and the state of my files, which are usually in various levels of edit—at any given point of time.

As a little bonus, [version] 2.3.2 allows you to define a custom DB error page. Place your custom template at wp-content/db-error.php. If WP has a problem connecting to your database, this page will [be] displayed rather than the default error message.

It is important to note that the custom db error page file is not under the theme folder, but rather in wp-content folder. Also, it is important to avoid using any template tag (in db-error.php)¹ that queries the database for stored information; because when the database is down, you cannot get a reply back from the database to show the queried info on the error page. Obvious, but if it wasn’t to you, then you know now.

As always, Wordpress team listens—that’s something I really like about them. It doesn’t matter who you are, your suggestions are always considered. That’s the strength of the community.

1. I use plain html/php coded content in my db-error.php file.

While I have no access to MySQL conf on my host to incorporate all the recommended changes, I could still speed this site up a bit just by setting most of the tables to InnoDB engine (with the exception of wp_posts table, which still needs to be set to MyISAM engine due to lack of FULLTEXT index features in InnoDB). In fact, wp_posts table refuses to be set to InnoDB when you try this—at least on my host:

ALTER TABLE wp_posts ENGINE = INNODB;

(Remember to replace the default wp_ table suffix to whatever you’re using; I don’t use the default by the way.)

Honestly, I would be happy to see MyISAM++ out soon and supported on my host¹, now that InnoDB—as a technology—is exclusively Oracle’s baby.

1. MyISAM++ is prophesied to have InnoDB’s features and more.

Much like auto-discovering feeds², an Opensearch-standard compliant browser now auto-discovers the availability of search on this site.

Try loading this site in a supported³ browser. You’ll either notice a subtle search icon highlighted in the default browser theme—suggesting that there’s something you can add to your list of search plugins or more visibly via a “+” sign, if you use a theme like Winstripe. Pull the search menu down and you’ll notice this: Add “ckunte.com”.

Enabling this on any site is easy. You’ll need to add the following⁴ in your site’s header part of XHTML code. I’m using my (this) site’s code for example:

<link rel="search" type="application/opensearchdescription+xml" href="/ckuntecom.xml" title="ckunte.com" />

(I had previously explained the construction of Opensearch XML file—ckuntecom.xml, which enables search auto-discovery.)

As a user, for sites that do not offer this feature, you can always use OpensearchFox. But if you’re a site owner, it is probably a good idea to provide this option to your regular readers and referrers.

1. I am beginning to test Sneha’s patience now.
2. Via the orange feed icon on the right end of the address or location bar.
3. Available in Opensearch supported browsers—Firefox and Internet Explorer 7.
4. Change file location, file name and title as applicable.