rajatarya.com website

rajatarya.com website

Summary

This page describes the construction and ingredients involved in this website. It also describes the process I’ve put in place to make the site more modular. The major application on this site is WordPress. Additionally WebSVN provides the SVN viewer and hopefully I’ll have some other fun web applications hosted here soon enough.

WordPress

Plugins Being Used

Akismet – Spam prevention plugin
Deko Boko – Contact form using reCAPTCHA
Google Sitemaps – Generate delicious sitemaps for search engines
Twitter Tools – Shows my recent tweets, yay Twitter
WordPress Database Backup – Creates a backup of the WordPress database
wp-cache – Intelligent caching mechanism for WordPress (come get me Digg)
WP-reCAPTCHA – Use CAPTCHA for comments – fighting the spam commenters one plugin at a time

Let me know if you have similar functionality on your site and are using different plugins. I’m always on the lookout for an ‘upgrade’. Drop me a line at raj...@rajatarya.com or one of the other methods listed here.

Theme

The site is built with a modified TwentyTen theme along with custom CSS.

Site Environment Setup and Deployment Process

After breaking this site for weeks on end by trying out a new plugin and then walking away from my system I got tired of being scared to try new things on my site. That is one the main reasons to have a website so it seemed stupid for me to keep from doing tinkering.

My approach to this problem was to modularize the components of the site so I could work on them in a development environment (playground) that mimicked the production environment and then deploy the site to production when I felt good about adding a feature. I hadn’t read anything about modularizing WordPress or Gallery, but figured they can’t be that hard to modularize (considering they are pretty easy to install).

Path to Modularization:

Backup existing WordPress DB and Gallery DB (I had MySQL as my backend for both of these on Site5, so I had to back them up to move them to Dreamhost anyway).
Backup all files for WordPress and Gallery (for me this meant a cleverly constructed tar statement excluding some cruft I didn’t want to carry forward)
Create an SVN repository for the website project
Remove all the files that you don’t want to make part of the project (especially wp-config.php and gallery2/config.php), but for me that also included: wp-cache cached files, last.fm cached images, unused themes and plugins from both WordPress and Gallery.
Import the file backups to the repository, making sure to remove the wp-config.php and gallery2/config.php files (important!).
Now you have a repository with all the files you would want.
Create a developer environment somewhere (you can use a subdomain if you would like or I recommend XAMPP). Remember to check out the files from the SVN repository for the developer environment.
Import the DBs to the developer environment MySQL. I used different db names to help differentiate things.
Manually copy over the wp-config.php and gallery2/config.php into the developer environment and modify it to point to the developer instances of the databases
If you are using a publicly facing dev environment (like playground.domainname.com or something) then make sure to add a robots.txt that disallows everyone, like the following (look here for more info):
```
User-agent: *
Disallow: /
```
Add an .htaccess file for the directory so that nosy folks won’t be poking at stuff that isn’t ready yet. Lots of docs on how to do this, referring to Dreamhost docs here.
To keep from having extraneous files “deployed” to production I created a “clean” local repository that I used for deployments, meaning that I had the following:
```
playground environment DocumentRoot: #HOME/playground
playground SVN path: $HOME/code/playground/trunk
production environment DocumentRoot: $HOME/production
```
Create some scripts, or use the ones I document below to deploy code changes from the developer environment to the production environment.
Rejoice!

Deployment Scripts Involved

I created two little scripts to help with my setup:

webcompare.sh – compares the playground SVN path with the production site to help me see what files are actually going to get deployed to production with the release, and to make sure something I don’t want to deploy is easy to spot. I also run this after a deployment to make sure I didn’t miss anything.
deploysite.sh – tars up the site from the playground SVN path and then untars it over the production path, and finally tags the release in SVN.

These little scripts are nothing too exciting but they have provided me with enough of a process that I can test/try/play with new features on my site without worrying about breaking existing functionality. It was a little work (especially because my bash programming skills are so weak) but now I am significantly happier with the site’s longevity.

Let me know how you maintain your site to allow for flexibility and feel free to suggest additional ways I can improve this process. Shoot me a note at raj...@rajatarya.com.

The Nitty Gritty

If you want to see the files modified for the site then check out the WebSVN look at the repository below. I have only exposed up the trunk branch because I’m not sure why looking at the tagged releases would be useful to anyone besides me.

SVN: View Code