Modifying the header

The default header was way too large and garish. While having the image change if there’s a featured image is a nice touch, it did not suit my requirement of a more serious and business-like church site. I also wanted to put a Google Custom Search box on the traditional upper right corner of the page, thus the header.php file was the first to be copied over to the child theme directory and modified.

The first thing I did was to get rid of the whole chunk of code which displayed the header image. That left just the site title, pretty boring. It should be possible to just remove the header image using the admin interface, but this left a huge empty placeholder there instead. Thus I had to remove the whole chunk of code which controls the header image.

Borrowing code from the previous project, I used CSS to add a logo to the site title link by setting it as the background. It was set to no-repeat and the text-indent property was used to move the actual text title so it does not overlap the logo.

The CSS for the site description was also modified so it would be on the bottom right hand side of the header. I want the top right hand side for the search box.

Theme setup

My previous theme was done with the thematic framework. This time, for more fine control, I decided to adapt the default twentyten theme for my purposes instead. Just in case the theme gets updated with something cool in future, I decided to make the theme a child theme.

Thus the first thing to do was to create the style.css file with the theme name and parent theme name in the comments. Once that was done, I could then start modifying and adding on to the theme to suit my purposes.

Showcase to the world

Although the development server is primarily meant for my own testing, I do want to get feedback from friends on the layout, readability, colours and other aspects of the design. Unfortunately, a parallel install of WordPress on the live server doesn’t mix well with the existing site, thus both cannot be accessed at the same time. To solve this, I decided to make my private web server publicly accessible.

This seemed like a simple enough task. I expected to be done once I could determine my external IP and then setup port forwarding. However, it was not so easy.

Despite setting up a DynDNS account, I was unable to connect to my server with the chosen address. A bit of hunting on Google revealed complaints from other users that Starhub had blocked port 80, the default http port. My next thought was simply to use another port, but WordPress Multisite cannot work with port numbers in the URL. Luckily, Starhub does not block port 443, so by enabling SSL on Apache and setting it up with a self signed certificate, other people could access the server.

This was where I hit a major roadblock in the process. Even after doing the previous steps, I was still unable to get a connection to the server. The open port utility on DynDNS said the port was open and accepting connections. I finally decided to ask some friends for help in trying out the address. To my surprise, they said they could access the site. Recalling that I had read something about loopback errors on the DynDNS website, I went back to find the information. The problem turned out to be a security setting on the router. The details can be found on this page.

I also discovered that my router has built in firmware to update DynDNS as my external IP address changes. I set up the feature and now no longer have to worry about updating the address manually as it changes. As long as my server is running, others, and myself too, will be able to access the site.

Development Environment

A LAMP server is used for development and testing. The components were installed one by one using apt-get.

The Ubuntu help page at https://help.ubuntu.com/community/ApacheMySQLPHP was the main reference used.

Version control is done with Subversion. The excellent guide at https://help.ubuntu.com/community/Subversion is very easy to follow and helps get Subversion up and running in no time. The command line client is used. The full ebook which explains Subversion and the commands can be found at http://svnbook.red-bean.com/

As I wanted to use version control with the theme’s code, a separate folder was created for this purpose, with the svn recommended structure of tag/ branch/ trunk/ folders. A symbolic link was then created from the wp-content/themes folder to the working copy. Changes made to the code can be seen immediately when the webpage is refreshed. If necessary, the symbolic link can be switched to either the branch/ or tag/ folders.

This post is actually a little late, and at the time of posting, WordPress 3.0.5 has just been released. In the process of updating, I discovered that WP can be updated with svn. The steps listed at http://codex.wordpress.org/Installing/Updating_WordPress_with_Subversion on how to convert a traditional install to svn are very easy to follow. The copies of WordPress on my development server and live server are now setup to use this method.

Purpose

I’m currently updating my church’s website, with WordPress as the CMS.

This blog will document the theme creation process. A child theme based on the default twentyten theme will be used for this.