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.

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.

Following this, I wrote a few connected posts: Why phishing works, Clarity of links and Pharming on the web using blogs. The point is—if you make publishing online your business, then there are no excuses for not making its security your business too.

Here’s what I do to ensure my site’s relative security:

• I choose a host, first based on recommendation, good track record.
• I keep my (blogging, content management) software up to date.
• I use sFTP (in passive mode) and SSH to connect to my site for uploading, downloading and modifying things there.
• I use file permissions with care.
• I take weekly backups—all files (at least the modified ones) and databases.
• I avoid inserting unknown scripts (of any kind, particularly javascripts) in my pages. (They pose security threats—open back doors to your site on your server.)
• I pay attention to server logs. (They often have a story to tell. Note: server logs and stat services aren’t one and the same. Usually stat services are unaware of happenings on your server.)
• I pay special attention to modified files on server.
• I hear warning bells when people, security consultants tell me that my site is acting like Paypal’s or some bank’s login. (This is when shit has already hit the fan; and I’ve been there once before.)

Any additional site security tips are most welcome.

Open up your corporate portal and try that search bar for something, anything. And tell me, if all you get is a puke of raw incomprehensible text¹ listing.

The only plausible conclusion I can draw is that people involved in design are either incapable of understanding that their portals are most usable when combined with an effective² search or, are incapable of implementing such a thing. Or may be both.

How should it be? — For starters, how about a readable title followed by a decent two-line summary, list of categories associated (for further narrowing down on similar / related items), date created or updated, targeted for specific groups, department, etc if any.

1. If you don’t, then I’d say you’re truly blessed.
2. I’d say effective, because there are tons of crappy options (as in software, services) that only give you a search bar and no results; or give you a myriad of options, as filters, that you don’t want or don’t know how to choose from, for the fear of not finding anything.

If you’re on a dial-up (or even connecting via a decent broadband), then the best and painless way to upgrade is via SSH. (Subversion is a far cooler method, but your domain server needs to be set-up for this.)

I use a combination of Smartftp and PuTTY (the SSH client). SmartFtp to upload the tar file to a temporary folder on my host. PuTTY for extracting the tar.gz file archive and writing over old wordpress files. Detailed instructions on howto do this are on Codex.