Final To Do List for Site Redesign

Here’s where we are so far in our progress on the earlier established to-do list:

  • Install copy of WordPress on development box
  • Import backup of live site content to provide some content for the development site
  • Create a bare-bones set of template files
  • Review the default CSS before beginning development of custom CSS for new template
  • Setup CSS for basic layout
    • 2-Column wide left, narrow right, approximately 75% – 25% split
    • Site width: 1024px (current width ~800px)
    • This gives almost the same relative widths as the current template, but with an increased overall width, resulting in a wider left column (and right) to give more room for graphics & code as desired.
    • Header will be short, ~ 5% +/- of screen height
    • Footer will be one or two text lines
  • Select color scheme
  • Select photo / graphic / logo for header and develop site-wide navigation in header

I’ve accomplished all the items on the initial plan! Until I was writing this, I hadn’t realized that all the original goals had been accomplished. That’s nice to realize! Goes to show that putting your plans and goals in writing and monitoring them can sometimes lead you to see progress in areas you didn’t realize you were making. That’s a subject for a whole other post. Too much philosophy for this one!

While I have accomplished the original goals, it does not mean that I haven’t changed and/or expanded on them while in progress. Or there may be some minor implementation issues left to finalize.

Here’s what I see still needs to be complete before launch of this redesign:

  • Review plugin use and confirm all are setup
  • Make notes of configuration changes that need to be done inside WordPress admin tool after installation of the template
  • Setup tabs with rounded borders using graphics
  • Check pages for IE support code & GIF graphics for rounded corners
  • Add Latest Posts to sidebar
  • Widen sidebar
  • Finalize color choice in post metadata
  • Consider post date ‘calendar’ format graphic or color change
  •  Expand About page content
  • Posts by Category page needs format still
  • Posts by Date page needs format
  •  Custom Category Templates for each of standard categories (Tools & Techniques) with header lead-in to content
  • Update blogroll and breakdown by category, perhaps using built-in link management system?
  • Add RSS Feed icon & links near top & remove from footer
  • Confirm RSS auto-discovery code is in header
  • About section in sidebar, with photo?
  • Ranking links (Alexa & Technorati)
  • Blogflux links (uptime, directory, mapstats)
  • Feedburner chiclet
  • Stats link codes
  • SEO code
  • Review online version for customizations to back-port to new design
  • Affiliate links (Sedo) others? HitsLink?
  • Last 50 entries on Archive page
  • Mullet Home page?
  • Review for standards compliance

As you can see, even though I have accomplished a lot, there is still much to do. But, most of it is little stuff in general, the details you don’t see or think of, until you get farther along in any project. This is one of the reasons project planning is not an exact science. While an architect can design a house, the carpenter that builds it still have to make a lot of decisions on how to implement the design. Here, I’m the designer and the carpenter.

Creating a WordPress Theme – Part 6, CSS3 Rounded Borders

CSS3 Rounded Borders was a success! Well, for Firefox users anyway! Luckily, I checked my stats and find that 65% of my visitors are Firefox users… mostly v2.0, but a few v1.5 users are still out there. Time to upgrade Firefox folks!

The rounded corners technique using CSS3 method is very easy compared to what I went though to create the graphics for each corner yesterday. Well, creating the graphics wasn’t so bad as getting all the pieces in place to position them properly–and then I still wasn’t satisfied. So, I’m glad I remember this technique existed. After reviewing the sample at CSS3.Info using border-radius for Mozilla & Webkit, I came up with the following:

[image no longer available.]

Note the rounded corners on the post background, the sidebar, and even the tabs. I thought I was going to have to reduce the radius for the tabs, but actually they look good with the same 25px radius the other corners are using. I’ve also got a shot of the middle of the page to show you how I’m separating the posts with the background and a little separation:

[image no longer available.]

OK, OK! You want to know how to do it!

First the rounded corners. Pretty much straight from the page at CSS3.Info:

-moz-border-radius: 25px;
-webkit-border-radius: 25px;
background-color: #003712;
border: 1px solid #CCCCCC;

Works very nicely. The border is just barely visible gray to help blend the edge a little.

The tabs are similar, however I used the specific CSS3 properties for just the bottom-left & bottom-right corners.

-moz-border-radius-bottomleft: 25px;
-moz-border-radius-bottomright: 25px;
-webkit-border-radius-bottomleft: 25px;
-webkit-border-radius-bottomright: 25px;
background-color: #003712;
border: 0 1px 1px solid #CCCCCC;

Note, the border being applied only to the left, right & bottom.

I’m still tweaking the size & font on the tabs, as it doesn’t feel quite right. I also took a quick look at it in IE7 to see what it would do with the rounded corners… not pretty! Besides not handling the border-radius property, it also didn’t seem to be handling some of the top margins or something. The first post was shifted up & overlapping the tabs. I’ll have to look into that… though I would rather ignore it! It might be a simple validation issue–I have not been able to validate the page yet since it’s on an internal server. The CSS has been validated by TopStyle, and it doesn’t like the Mozilla- & Webkit-specific properties, but that should not be too much of an issue. They should be just ignored. I hope!

Creating a WordPress Theme – Part 5

Just a quick update on the template progress… I’m working on using CSS to create rounded corner effects on backgrounds that will be used for the sidebar & posts. I got the basic concept from many places, but Adam Kalsey has a good post on the Rounded Corners in CSS technique. Here’s an in-progress snapshot of what I’ve got so far:

[image no longer available.]

Notice the rounded corners on the sidebar background. It looks pretty good here in a low-res snapshot, but I’m tweaking a single pixel border that doesn’t want to cooperate in the right combination with the graphics. It has to be positioned to appear along the top border, between the graphics (there are individual graphics for each of the rounded corners), but not extend out the full width of the enclosing div. I’m trying to avoid using a full-width image to accomplish this.

There is a similar setup at the bottom of the column, however, while I was working on the top, the bottom disappeared! I think it is being covered up by the background of the sidebar, though it shouldn’t be doing that. I’m focusing on one end at a time, and learning more about editing graphics at the pixel level as I go! I plan on using something similar for the separation of the tabs too.

How to Create a WordPress Theme – Part 4

I made good progress on the To Do list last night:

  • Install copy of WordPress on development box
  • Import backup of live site content to provide some content for the development site
  • Create a bare-bones set of template files
  • Review the default CSS before beginning development of custom CSS for new template
  • Setup CSS for basic layout
    • 2-Column wide left, narrow right, approximately 75% – 25% split
    • Site width: 1024px (current width ~800px)
    • This gives almost the same relative widths as the current template, but with an increased overall width, resulting in a wider left column (and right) to give more room for graphics & code as desired.
    • Header will be short, ~ 5% +/- of screen height
    • Footer will be one or two text lines
  • Select color scheme
  • Select photo / graphic / logo for header and develop site-wide navigation in header

Pretty good work!

I want to show you a screen capture of the default starting point for the template, which is the supplied Kubrick template:

[image no longer available.]

Look familiar? That’s what you get after an initial install of WordPress if you don’t make any changes.

To show you just how much work is being done by that default template, here is what it looks like if you remove all the CSS that is being applied:

[image no longer available.]

Not very pretty, would you say? Well, after considering the two, I decided to start with the default template, and then tweak the settings from there.

Here’s a sneak-peak at what I’ve come up with so far:

[image no longer available.]

What do you think? You can see the result of a lot of the design decisions I’m making:

  • Width 1024px
  • Header graphic gives mountain scene
  • Leads to a blue, green, brown earthy palette for colors
  • Drop down tabs from header for page-level navigation (still more work to be done here)

I’m still working on getting the column widths where I would like, so you see the sidebar out of place still. Fonts have not been adjusted at all yet, for color, family or size.

Pretty good start for a few hours work. I think I will make my target launch of May 1 with no problem!

Creating a WordPress Theme – Part 3

I’ve made the decision this morning to target a launch date for the new theme for May 1, 2007. With that in mind, I’ve got 10 days to get it done. To that end, I’ve created a To Do list of items to be completed:

To Do

  • Install copy of WordPress on development box
  • Import backup of live site content to provide some content for the development site
  • Create a bare-bones set of template files
  • Review the default CSS before beginning development of custom CSS for new template
  • Setup CSS for basic layout
    • 2-Column wide left, narrow right, approximately 75% – 25% split
    • Site width: 1024px (current width ~800px)
    • This gives almost the same relative widths as the current template, but with an increased overall width, resulting in a wider left column (and right) to give more room for graphics & code as desired.
    • Header will be short, ~ 5% +/- of screen height
    • Footer will be one or two text lines
  • Select color scheme
  • Select photo / graphic / logo for header and develop site-wide navigation in header
  • Select items to be included in sidebar:
    • About – Should I include picture of me?
    • Search
    • Feeds
    • Email subscription option?
    • Archives – Perhaps better in header site-wide navigation?
    • Categories and/or tag cloud?
    • Blogroll – Move to separate page?
    • Space for affiliate ads
    • Space for site support links (Blogflux currently)
  • Setup footer with statistic tracking codes, etc.
  • Plan post layout and post-related plug-in use.

I’m sure I’ll come up with other details, but that will be the basic flow.

How to Create a WordPress Theme – Part 2

OK, if you look back at Part 1, you will find I listed choosing a Column Layout first on the To Do list. However, do you always do your To Do’s in order? Not me. Well, actually, it’s not my idea. In researching the whole column/page layout concept for today, it was pointed out there were some other important items to consider first. In a recent guest post at ProBlogger, Matt Coddington from NetBusinessBlog shares the Important Elements of Blog Design & Layout.

Matt emphasizes the importance of focusing on Content, User Experience and Compatibility.

Content refers to your actual planned content for your blog. Do you write long posts or short? Do you include a lot of graphics? What size do you use? Then of course you can through in what other gadgets do you want to include in your posts or sidebars? All of this stuff takes up space. Ask yourself for each item included, is it important or can I do without it?

User Experience focuses on user issues. I don’t know about you, but while I like hi-resolution screens to be able to pack more content into a smaller space, I’m getting older… I’ve worn glasses most of my life, and find now that even with a current prescription, I prefer my fonts a little larger. So, do you have young readers, or old? We have to think about accessibility for users using screen reader devices, or screen magnifying devices for limited vision. As well as navigation accessibility considering both the limited vision user and the mobility impaired who may have difficulty using a mouse to navigate.

Compatibility is related to what devices do you want you content available on. In the past, it was difficult to have content appear in a similar arrangement, if viewable at all, by the major browsers without significant tweaking and tricks. Today it is easier thanks to Web Standards, but the problem has not been eliminated. There are also new platforms, such as cell phones and other mobile devices that are being used.

My Analysis

Applying the thoughts above to my plans for this blog, I come up with these considerations.

Content: I feel I need a wider column for my core posts. Many have included code examples, and I’ve had to make notations about wrapping lines and the like that would be clearer when displayed as one. I wold like to use more screen shot examples in a larger format, as long as file size is reasonable–which is based on actual content of the graphic. I tend to write fairly long posts, and having full posts on the home page is something I may need to reconsider. I had long ago come across “Mullet”-style blog layout by Jonathan Boutelle, and was re-introduced to it while researching this entry. (That’s where you have teasers to a few recent entries, with links to full posts, then a long list of the previous posts, say 50+ on the home page.) Then there’s the liquid vs. static layout argument that tends to lean toward liquid for longer posters and static for short. Michael Gray has a nice analysis in a three-part series on Maximizing Profits With Website Design and Layout.

User Experience: I tend to blend this all encompassing term mostly into usability. The personal issues I mentioned above, combined with accessibility & usability techniques must be a consideration in layout and choice of design details, like fonts and their default size. Allowing for the wider column I’ve already mentioned, gives me the flexibility to increase the default font size for ease in reading. I’m liking these choses already! This was a great exercise!

Compatibility: As mentioned, web standards is the only way to fly today. By designing a site that is functional when all the fancy stuff is turned off (CSS,JavaSciript, etc.) you end up with a site that is accessible from a multiple number of platforms. Taking it another level and providing custom CSS for those mobile devices that can use them, just improves the user’s experience.

With those thoughts on our brains, we will move on tomorrow. Perhaps really to thinking about the layout…

How to Create a WordPress Theme

I had heard that the template that I am currently using, MistyLook by Sadish Bala, is very popular. however, I had never run into it elsewhere… well, there’s always a first time! I ran into it while researching de.lic.ious WordPress plug-ins on The Partition. Thanks for the inspiration to create my own! I knew I had to do it eventually, but I guess now is the time!

While I like the look of MistyLook very much, I am a firm believer in personal, business & web site branding. In order to create a name for my self, I also have to create an image. When you come here, I don’t want you to be confused where you are! I was the first moment I saw MistyLook on the Partition. It felt kind of eerie…

Step One: The Plan

Before I actually create the theme, which I’m going to walk you through with me step-by-step, I have to plan what I need and want to include. After trying several themes myself, browsing many more, and experiencing those of others I should have a sense of what pieces I might like to include in my theme. I’m talking conceptually here, not literally using someone else’s theme. The best themes out there are done by professional designers. Don’t steal them! That’s how they make their living! Especially custom graphics & images.

If you have not experimented with different templates, or browsed the online theme gallery at, go do so now. While you are there at the Codex, let me point out the bible for creating new themes, the Blog Design & Layout page. Start working your way through the material there. It will help you with the understanding for making everything from minor tweaks in a standard template design, to reworking how the whole page is laid out.

While I could make modifications to the original files, what I plan to do is to develop a true separate theme that could easily be contributed to the community or just shared with a friend. But, it will begin life as my personal unique design.

Let’s start with a To Do List:

  • Select a page layout (1-, 2-, or 3-column?)
  • Color scheme (there should be an overall consistent use of color in the design)
  • Header & footer (content & design)
  • Multiple column contents (if more than one, what’s in them?)
  • Post structure & design (how is the post heading, content, metadata, tags etc. organized & displayed)
  • Archive page layout
  • Category page layout
  • Tag page layout

That should get us started thinking. As I go along, I may add specific areas that are needed, or expand on the one’s listed. We’ll take it one step at a time.

Using Subversion for a Web Site – Part 2

I need to clarify one thing from my earlier post. I demonstrated how to create a subversion repository on your local computer. Note, this was for demonstration purposes only. To get maximum advantage from using a subversion repository, it needs to be located on a networked server that all site developers can access. OK, you are thinking, “I’m only one person, why do I need to do it this way?” Easy answer: Backup! Not to mention the advantages of using the entire concept of source code management to develop your site.

So, if your repository is on a different server, how do you work with it on a daily basis? That’s what I’m going to describe today. Keep the two locations in mind as the remote server Repository, and the local Working Copy.

Last time when we parted, we had just checked out a local copy from the repository. (Just imagine that repository was remote rather than local to your computer.) Let’s pretend you quit at that point for the day. This is the point you want to be at whenever you quit working–synchronized with the repository. You should never quit working without doing an UPDATE & COMMIT of all of your work. We’ll cover those details momentarily. By doing this, you will always have a backup of your work, as well as have it stored remotely in case you edit from multiple computers and/or locations. For example, I might do some work at my office, and then come home and feel like doing a little more… or end up wanting to work from home the next day. Having the files in the repository allows me access to the current files from wherever I choose. Just connect from the alternate location, and UPDATE.


OK, what exactly is UPDATE? With the UPDATE function subversion compares the files you currently have locally, with the remote copy on the server and downloads files from the server, if they are newer. Note, this is one-way updating. If you have edited any of your files and want to upload them, you do a COMMIT–we’ll cover that in a minute. During an UPDATE there are a few possibilities:

  • No changes–your local files are already up-to-date with the server
  • Newer files on server–none of your copies of the files have been edited locally
  • Newer files on server–some of the same changed files have been edited locally also, but in unrelated ways
  • Newer files on server–changes in files are in the same area as changes made locally

No Changes

While this may seem an obvious answer, it is important to recognize you are at this state. Especially if you are in a multi-developer environment. In this case, no changes will be made either on the server or locally, and the current Revision Number will be displayed.

Newer Files in Repository, No Working Copy Files Changed

In this case, the newer files on the server will be copied to your local working copy. You will see a list of the files that have been updated, as well as what the status of each file is–note each of these possibilities we are covering occur on an individual file basis, so what happens per file might be different. The current Revision number will be updated.

Newer Files in Repository, Unrelated Working Copy Changes

The important thing to ask in this case is, what is an ‘unrelated change’? The key here is that you may have edited a file in one area, say lines #5-10. But, the changes in the repository file–compared to a common base–are in an entirely unrelated area of the file, say lines #50-55. You can probably see that as long as each individual change is in entirely separate areas of the file, with no overlapping, that it is possible to merge the changes without much thought. Note, even if lines are inserted in one location or the other, the context of the surrounding lines identifies where they are in relationship to the base file.

It is important to note that this merging of changes can only be done with text-based files. And while binary files, such as images, can be maintained in subversion, they cannot be merged.

In the no conflict case such as this, subversion will automatically merge the files for you, updating your local copy. In the list of files with changes you receive at the end of the update, you will see a code G next to them indicating a successful automated merge.

Newer Files in Repository, Conflicting Working Copy Changes

As you may have guessed, in this case subversion can’t automate the change. But, it helps! You will be advised of the Conflict, and several copies of the file in question will be put in your local working copy. Your original file will be renamed: filename.mine, there will be two other files with a Revision number appended: filename.r<old rev #> and filename.r<new rev #>. The old rev number is the one you had before you started making changes, the new on is from the server copy. The original file will contain special marks in the file showing both revisions to enable you to compare and figure out which changes should be used, or if you can manually merge the two changes. There are several convenient tools available to ease the process of this editing.

Once you have edited the original filename to contain the changes you really want, you should do an UPDATE (to make sure no more changes showed up while you were working on it!) and then a RESOLVE in order to let the repository know the conflict has been resolved and which changes to keep. Then COMMIT your changes as usual–see below.


Commit is simply the process of uploading your changes to the repository. Remember, as mentioned above, if you have been working for any significant period of time since your last commit and your are in a multi-user environment, do an Update as described above first before doing a Commit. It will also be easier to merge changes if you do an Update on a regular basis to get new changes from the repository even if you are not ready to commit your changes.

When a commit is done, all changed files are updated in one batch. So, best practice is to keep related changes together. If you have to modify a form to be displayed and update it’s related processing code in a separate file, make the changes and commit them together. Every commit will require a Log message, so it makes it easy to describe the related changes and see them together when looking at historical changes.


To wrap things up at this point, I want to point out a couple of resources you can use for the details I have not include here, but will in future installments. The easiest, and free, resource is the online version of the Subversion Book. Several versions are available, including a download PDF. If you are like me, you may like to have a paper reference of it, and the authors would appreciate the purchase of it as well, it is published by O’Reilly Media and is available from Amazon: Version Control with Subversion.

Another good book is the one I use personally, and is part of the Pragmatic Starter Kit Series: Pragmatic Version Control: Using Subversion (The Pragmatic Starter Kit Series)(2nd Edition). This book is a little over 200 pages, and I was able to read it cover-to-cover in a little over a week in my spare moments. Many great ‘pragmatic concepts’ to be learned and applied in the future.

Well, that about wraps it up today. Next time, I will get into explicit demonstrations of these steps. I’ll give you the command line techniques and demonstrations, as well as snapshots of doing the same in TortoiseSVN. Stay tuned!

Managing Web Site Content with Subversion

As I have previously mentioned, I am a big fan of managing code changes with Subversion. Here I’m going to describe the process of creating your own local repository for managing changes. Think of Subversion as you own personal time machine for your content.

My basic setup will be to have the repository (where subversion stores all of your changes) on a secondary partition on my laptop’s hard drive. While I had considered having it remotely on my server, I want to have it local so I can manage my content when I am off-line traveling. I will also use backup routines to have copies on external drives. While I prefer to work in Linux, I also work in windows, so I will describe the setup from a windows point-of-view. However, the files for the repository are on a shared partition of my hard drive so I can access the repository not matter which OS I’m using at the moment.

The basics steps are these:

  1. Install Subversion & optionally, TortoiseSVN for windows
  2. Create directory to store repository
  3. Create repository with svnadmin
  4. Import web project
  5. Checkout working copy of web project

Install Subversion & optionally, TortoiseSVN for windows

Subversion & TortoiseSVN are available from the Open Source projects at

Follow the link to the individual download pages and download the current version for your OS. Install in the usual manner! Note, TorotoiseSVN requires a reboot since it integrates with windows explorer.

Create directory to store repository

Hopefully, if you know dos, this will be familiar. Or maybe it won’t if you have never used the command line under WinXP. Since subversion itself is a command line program, creating the repository will be at the command line. so let’s start by using the command line to create the needed new directory. Click Start -> Run… (or Windows-R from keyboard) and type cmdand press Enter. A new window with white text on a black background will open with a prompt showing your current directory. Decide where on your drive, or drives, you would like to locate the repository. Then create the directory with md:

C:> md e:svn-repo

Substitute your own drive letter instead of e: and path of your choice instead of svn-repo.

Create repository with svnadmin

Now that you have a directory to use, we use svnadmin to turn it into a repository for use by subversion.

C:>svnadmin create e:svn-repo

Let’s see what it created for you:

Directory of e:svn-repo

04/01/2007  05:53 PM    <DIR>          .
04/01/2007  05:53 PM    <DIR>          ..
04/01/2007  06:20 PM    <DIR>          dav
04/01/2007  06:20 PM    <DIR>          locks
04/01/2007  06:20 PM    <DIR>          hooks
04/01/2007  06:20 PM    <DIR>          conf
04/01/2007  06:20 PM               234 README.txt
04/01/2007  06:20 PM    <DIR>          db
04/01/2007  06:20 PM                 2 format

Don’t worry anything about the details now, but I just wanted to show you that subversion is doing a lot of work for you behind the scenes.

Import web project

Next step is to import that web site you have been working so hard on! Since we have been working at the command line, I will continue here with that technique. Then I will show you the easy way with TortoiseSVN–a graphical tool to access the power of subversion from windows explorer.

First, locate the directory where you current web site files exist on your drive. If you have multiple sites, I will suggest that you import them as separate ‘projects’ in subversion. cd to the top-level directory you want to import–all subdirectories will be imported also. You should clean them up before importing, removing any test or temporary files you do not want in the repository.

C:>cd htmlcdchase-blog


Next, you will use svn import to pull in all of the content to the repository. Last chance to clean up the directory and sub-folders before importing! Notice the use of -m “Importing project” to supply a log comment. All changes to a subversion repository require a comment describing the change.

C:htmlcdChase-blog>svn import -m "Importing project" .  

You will see all of your files scroll by as they are imported. Eventually, you will get to the last line:

Committed revision 1.

Congratulations! You now have your first project in the subversion repository!

Before we move on, let me point out two items in the import command above. First, the ‘.’ (dot or period): it is how you refer to the current directory as a shortcut. If you were not already in the directory you wanted to import, you could explicitly provide it instead of using the dot. Secondly, the format of the destination: file:///e:/svn-repo/cdchase-blog/trunk. This is the URL format for referencing a local file location. The file:/// replaces the use of http://hostname/ as in a web browser. The remainder is the path to the repository, including the desired project name, cdchase-blog, in my case; and the branch you want to import it to, trunk. More on the use of ‘trunk’ in a future post. The ” at the end of the first line is just to indicated that this line is continued on the next line–don’t type this in windows! The entire command should be one line, without the ”. (Linux users may recognize this as the standard continuation character.)

Importing with TortoiseSVN

As promised, doing the same import function with TortoiseSVN is as simple as right-clicking on the folder you wish to import, and selecting TortoiseSVN -> Import…

(image no longer available)

and supplying the destination path and log message:

(image no longer available)

Once you click ‘OK’ your files will be submitted as in the command line version.

Checkout working copy of web project

Finally, in order to actually use the files from the repository, you must ‘check out’ the files. This must be done to a new directory, so if you want to use the same directory name you imported from, rename that directory first.

C:html>rename cdchase-blog cdchase-blog-old

To do the ‘checkout’ or co:

C:html>svn co file:///e:/svn-repo/cdchase-blog/trunk cdchase-blog

When it is complete, you will see:

Checked out revision 1.

Congratulations! Your files are now under version control!

Tomorrow, we will go deeper into how you use Subversion on a daily use basis.