I have several responsive sites in progress at the moment, but this week marks the official launch of the first fully-responsive design I have coded, and I’m absolutely delighted with how it turned out.  It’s for a new company called Answers in Hand, which facilitates providing information to cell phones via NFC and QR codes.  The fantastic graphic design is by George Guy of Warp Graphics.

So go visit Answers in Hand, and then resize your browser – as it gets bigger and smaller, the hand holding the phone changes orientation so that it always fits on the screen.  Once you get down to mobile phone size, the hand holding the phone disappears (since you’re already looking at it on a phone in your hand).

I’m not usually a fan of one-page websites, but this is a case where I think it works really well.

From now on, I’m making sure that all of my sites are at least a little bit responsive, and you’ll see some more fully responsive sites from me soon.

It is fairly easy to just set them up on the same virtual host as your main site, but that (likely) means you will have two sites with duplicate content, which Google really doesn’t like.  So you want to provide a 301 redirect for the mis-typed domain to the correct one.  You could create a whole bunch of 301 redirects for each individual page, but if you’re dealing with dynamically generated content, that really doesn’t work. Luckily, the Apache web server has the RewriteRule, which can be used to redirect everything that comes after the domain name to the new domain name.

I typically just do all the re-directs from within Apache’s VirtualHost directive–this way I don’t have to create anything else or worry about dealing with .htaccess files. An example is shown here that redirects the extra domain example.net to the real site, example.com completely within an Apache VirtualHost:

<NameVirtualHost *:80>
<VirtualHost *:80>
ServerName example.net
Options +FollowSymLinks
RewriteEngine On
RewriteCond %{HTTP_HOST} ^example\.net
RewriteRule (.*) http://example.com/$1 [R=301,L]
</VirtualHost>

This 301 redirects anyone who goes to http://example.net/ to http://example.com/ . It also preserves anything they may have typed after the / , so http://example.net/page1.html is redirected to http://example.com/page1.html .
But, if a visitor types in www.example.net, the above won’t work. We could fix it by adding .* in front of the example\.net in the RewriteCond, but it gets further complicated if you have multiple sub-domains, and you want to redirect to their corresponding sub-domains on your main site.

Say you have www.example.com, pics.example.com, wiki.example.com and blog.example.com, each on it’s own separate server; you would need to set up each sub-domain separately with a 301 redirect. If you have multiple domains you are redirecting for, you would have to set up each of the sub-domains each time for each additional domain.

Luckily, Apache RewriteRule does support parsing the hostname, but it took me a little effort (as by default the RewriteRules work on everything after the hostname) to find the correct method. Now, RewriteRules can be used to redirect for any number of sub-domains. The following VirtualHost below does just that for all sub-domains for example.net:

<NameVirtualHost *:80>
<VirtualHost *:80>
ServerName example.net
ServerAlias *.example.net
Options +FollowSymLinks
RewriteCond %{HTTP_HOST} [^.]*example\.net$
RewriteRule ^(.+)                  %{HTTP_HOST}$1   [C]
RewriteRule ^(.*)example\.net/(.*)$ http://$1example.com/$2 [L,R=301]
</VirtualHost>

Unfortunately, I haven’t been able to get a single RewriteRule to work for all domain names, so you would need to create a virtual host for each additional domain you wish you redirect (though you only need one NameVirtualHost for all the VirtualHosts).

Shane isn’t a programmer, so he didn’t realize that a lot of what he was asking for on his website can get very complicated: e-commerce, ComicPress, different layouts and navigation for different kinds of content, different headers on different pages, and a very different look for the webcomic pages.  Any one or two of these things wouldn’t have been very complicated by themselves, but added all together, it made for a very complex site.

So here are some technical details about the site requirements and what I did to create this site to Shane’s specifications.

First of all, the biggest requirement for the site was ComicPress, a WordPress theme for webcomics.  ComicPress actually feels more like a plugin than a theme: it adds all sorts of extra functionality, like the ability to bulk upload comics and instantly create posts for them.  ComicPress does some impressive stuff, but it also has some limitations: for instance, if you have a blog on the home page, it can either show posts in the comic category, or posts in all other categories: if you have a bunch of categories and only want to show one of them on the home page, you’re out of luck.

I created a ComicPress child theme, based on the comicpress-blank child theme (I guess that makes mine a grandchild theme).  This meant that I could add files to overwrite any of ComicPress’s theme files, but I was very cautious about doing this – I didn’t want to completely rewrite ComicPress, and I wanted to make sure that Shane can still update ComicPress the next time an update is released.  The biggest changes I made were to the layout of the site.  Another of ComicPress’s limitations is that you can pick one site-wide layout (and there are lots to choose from), but you can’t have different layouts on different pages.  Shane needed different layouts, so I hacked a few of the files to get different layouts on different pages in ComicPress.

The site has several different sections, and each one has a slightly different layout and navigation.   I considered several different ways of doing this, but finally decided it was best to just make custom post types.  This is good because I can make them work the way I want without any hacking/kludging, but unfortunately from the user’s point of view it means there is another procedure to follow: each section of the site requires a slightly different procedure for uploading media.  There are two custom post types: “Portfolio,” which takes care of Comics, Illustration, and Fine Art, and “Video,” which takes care of the Media section.  The Portfolios also have a custom taxonomy, “Genre.”

I also wanted to add a custom meta box to make updating the Portfolio custom post type easier.  I followed these instructions, and couldn’t get it to work (the same code works on other blogs, but not this one).  I think this is just a bug in ComicPress – the action hook that adds the meta box to the editing page never gets called.  Once I realized that action hook wasn’t getting called, I decided that I had already wasted a ton of time on it, so I should to just make hay and use the “add custom field” box, which is less graceful, but less expensive for the customer in the long run.

Shane’s site also requires e-commerce, so that he can sell comic books, art prints, t-shirts, custom art, and other nifty stuff.  I used Jigoshop: of all of the e-commerce plugins I have used, Jigoshop is definitely my favorite, although it isn’t without its quirks.

In addition to the main site at shanewhite.com, Shane also wanted the ability to easily create sites for his webcomics (such as Braun), so that he can add new webcomics whenever he wants.  So I wrote another theme, fairly similar to shanewhite.com, that he can use on all of his webcomics sites: with changes to colors and logos, he can make each site look unique.

Of course, all of this complicated stuff gets complicated for Shane too: in addition to WordPress’s normal posts and pages, Shane has 3 custom post types (portfolio, video, product) and comic blog posts that are different from normal blog posts.  That’s a lot of different procedures for one person to keep track of!  Not to mention the number of widget areas – I lost count of the number of widgets the site uses.  So I wrote extensive instructions, thanks to the WP Help plugin.  Fortunately, Shane is clever, so he has had no trouble figuring all of this out.

Shane was a delightful client to work with through this whole long process.  Naturally it was fun looking at his artwork as I was working, and he was one of those clients for whom I can use Samuel L. Lipsum and know that I’ll get a laugh instead of a disapproving look (it was hilarious when he realized what it was).  He was very patient with me when we ran into problems, which happened frequently – this seemed to be one of those sites where every little step turned into a big complication, and things that should have been relatively easy turned out to be quite time-consuming.  For instance, there were some things in the header that we couldn’t get in the correct position: it turned into a comedy of errors, sending screenshots back and forth showing how even though we have the same operating system and the same version of the same browser, the search box was in a completely different place on our screens.  And, of course, since Shane is a graphic artist, he wanted everything to be pixel perfect.  He was quite shocked when I sent him to Browser Shots to demonstrate how differently browsers render the same site.  I think we managed to get it pixel-perfect in most browsers.

This was a really fun challenge, and I’m happy with what we produced.

When I decide how to code a site, I think constantly about whether someone might want to change what I am coding, and if so, how easy will it be for them to change it?  For instance, most websites have contact information in the footer – phone number, address, etc.  It would be quick and easy for me to just hard-code this into footer.php.  But what if the client moves and needs to change their address?  What if they decide they want to format their phone number with periods instead of dashes?  Instead of hard-coding this information, I create a widget area in the footer so that the client has access to the information in the site’s widgets.  This takes a little more time and effort from me up front, but makes it easier for the client in the long run.

When I code the site layout, I also think about how things might need to shrink or grow.  If a client decides they want to add or remove a link from a navigation menu, will the menu still look okay?  Sometimes this is dictated by the graphic design, but I try to code as much flexibility as possible into the layout.

I also use a lot of plugins and widgets to make things easier for my clients.  I wouldn’t need a lot of these if I weren’t concerned with usability, but they make life a lot easier for clients who aren’t comfortable with HTML.  Some of the plugins I use most frequently are:

• Contact Form 7: This is an easy-to-use contact form, and their website has excellent documentation and tutorials
• Image widget: This widget makes it really easy to upload an image into a sidebar or other widget area, and link the image to any URL
• Rich Text Widget: This widget lets you use the WordPress WYSIWYG editor to edit widgets: very handy if you want to put a link or formatted text into a sidebar
• TinyMCE Advanced: TinyMCE is WordPress’s WYSIWYG editor, and this plugin adds a few more features to it to make it a little more user-friendly
• WP Help: With this plugin, I can write documentation and instructions for my clients, and it will show up in their dashboard.

All of this effort at making things easy to edit is for naught if I don’t tell my clients how to edit their site.  I provide a customized manual for each site, explaining how to edit anything the client might want to edit.  I also provide an in-person training session for any client that wants it.

This all takes some extra time on my part, but it is worth it in the long run if my clients can be self-reliant.  They have the ability to take care of their own sites without worrying about my availability, and that’s good peace of mind for all of us.

It gives me something fresh and new to work on.  When I code my own designs, I find my own work predictable, since, of course, it comes from my own head.  When I can code someone else’s design, I have something new and interesting to work with, and other designers end up doing things that I never would have thought to do.

It might seem that once the graphic design is done, the creative part of the process is over and writing the code is just busywork.  On the contrary, I actually find that writing code requires a great deal of creativity, especially when it is someone else’s design.  I have to figure out how to write a bunch of text that the computer will translate into the images I see.  Not only that, but I always try to write websites so that they will be easy for the site’s owner to update themselves, so sometimes that requires a little bit of extra creative thinking.  It’s a fun problem-solving exercise, and it often requires thinking outside of the proverbial box or approaching the problem from several directions at once.

Coding for graphic designers has also made me a much better designer myself.  I have to examine the work of several different designers in minutia, and looking at how they put their designs together has taught me a lot about what I need to do when I create websites.

It might seem like writing WordPress themes over and over based on someone else’s designs would get boring, but I really enjoy it. I find it to be creative and stimulating work.

I recently upgraded to Mac OS X Lion, and things have been mostly positive.  I really love the option to “Reopen windows when logging back in.”  In terminal, that means I get all my windows back! I do still have to reconnect to all the machines, but at least I can see where I was connected, and pretty much what I was doing.  I use screen extensively on  the servers I connect to, so I frequently don’t even lose what I was doing.

The only problem is that when Mac OS X boots back up and starts Terminal.app at login,ssh-agent is not started before Terminal.app starts, meaning I can’t log into servers using my SSH public keys.  Further, if you quit Terminal.app, and re-open it, it won’t reliably open ssh-agent (I’ve had it happen a couple times out of the many times I’ve tested).  The only surefire way to get ssh-agent to start is to close all your windows and then quit & restart Terminal.app with a completely blank slate.

That is a problem as it undoes all the good that saving all my windows did.  I wanted to find a way to get ssh-agent started before Terminal.app opened.  I added it to my Login Items without any success, and even adding a LoginHook to /etc/ttys did not make it start before Terminal loaded.

But, there is a workaround  in that if I have ssh-agent start at login, I can quit & restart Terminal.app and it always connects, so that is what I have done.  The probably more correct place to do is to add it to my Login Items.  To do that, I opened a Terminal window & created a symbolic link from ssh-agent to my home directory.

ln -s /usr/bin/ssh-agent .

Then I added it to my Login Items by pressing the + button and selecting it from my home dir.  I can then remove the symbolic link I created, as Login Items is smart enough to link to the actual ssh-agent program.

So now after bootup and login, if I quit Terminal.app and restart it, it always connects to the ssh-agent and I can go about my passwordless logging in to all my servers.

However, I did run into a weakness of ComicPress pretty quickly.  The comic artist for whom I am writing this theme wants different pages to have different layouts.  This is a pretty standard feature of WordPress sites: sometimes you want one page to have sidebars and another none, or some pages with sidebars on the left and some with sidebars on the right.  In ComicPress, on the other hand, you can’t do this.  ComicPress comes with several choices of layout, but once you make your choice in the ComicPress admin area, you’re stuck with that layout on every page.

Fortunately, I found that it is actually pretty easy to make different layouts for different pages with ComicPress, if you don’t mind tinkering with the code.  I’ll show you how I did it.

First of all, make sure that you are working with a ComicPress child theme, and do not edit the ComicPress files themselves: if you do, all your changes will be lost when you upgrade ComicPress.

The files that control the layout of the site are called layout-head.php and layout-foot.php.  Copy those two files into your child theme directory: now you can update them and they will override the original files.

Here is the original layout-head.php that comes with ComicPress:

<?php if (comicpress_themeinfo('enable_caps')) { ?><div id="content-wrapper-head"></div><?php } ?>
<div id="content-wrapper">
        <?php if (is_cp_theme_layout('2cr,2cl,3c,3c2l,3c2r')) do_action('comic-area'); ?>
        <?php if (comicpress_themeinfo('enable_caps')) { ?><div id="subcontent-wrapper-head"></div><?php } ?>
        <div id="subcontent-wrapper">
                <?php if (is_cp_theme_layout('2cl,2cvl,3c,3c2l,v3c,v3cl,lgn') && !comicpress_disable_sidebars()) get_sidebar('left'); ?>
                <?php if (is_cp_theme_layout('3c2l,v3cl') && !comicpress_disable_sidebars()) get_sidebar('right'); ?>
                <?php if (is_cp_theme_layout('2cvr,2cvl,v3c,v3cr,v3cl,lgn,rgn')) { ?>
                        <div id="section-wrap">
                        <?php do_action('comic-area');?>
                <?php } ?>
                <?php if (is_cp_theme_layout('rgn') && !comicpress_disable_sidebars()) get_sidebar('left'); ?>
                <div id="content" class="narrowcolumn">
                        <?php if (is_active_sidebar('over-blog')) get_sidebar('overblog'); ?>

The section of code that interests us is after <div id="subcontent-wrapper">. You can see that there are short names for each layout option, and the code is full of conditional clauses for each layout. So the code says that all layouts show the left sidebar, unless the sidebars have been disabled. The three-column layouts also show the right sidebar. All layouts show the comic area.

I rewrote the conditional logic, as you can see here:

<?php if (comicpress_themeinfo('enable_caps')) { ?><div id="content-wrapper-head"></div><?php } ?>
<div id="content-wrapper">
        <?php if (is_cp_theme_layout('2cr,2cl,3c,3c2l,3c2r')) do_action('comic-area'); ?>
        <?php if (comicpress_themeinfo('enable_caps')) { ?><div id="subcontent-wrapper-head"></div><?php } ?>
        <div id="subcontent-wrapper">

        <?php
                if (is_page()) { ?>
                        <div id="content" class="narrowcolumn"> <?php ;
                }
                elseif (is_home()) { ?>
                                <div id="content" class="narrowcolumn"> <?php ;
                }
                elseif (is_single()) { ?>
                        <div id="content" class="narrowcolumn"> <?php ;
                }
                else { ?>
                        <div id="content" class="widecolumn"> <?php ;
                }
        ?>
        <?php if (is_cp_theme_layout('2cvr,2cvl,v3c,v3cr,v3cl,lgn,rgn')) { ?>
                <?php do_action('comic-area');?>
        <?php } ?>

                <?php if (is_active_sidebar('over-blog')) get_sidebar('overblog'); ?>

Instead of my conditions being based on what layout was chosen in the ComicPress admin options, I wrote conditions based on what kind of page is being rendered, using WordPress’s conditional tags. For pages where I don’t want sidebars, I made a div with class “widecolumn”; for pages where I do want sidebars, the div’s class is “narrowcolumn.”  I moved all references to the sidebars to the footer.

I made very similar changes to layout-foot.php. Here is ComicPress’s code:

                </div>
                <?php if (is_cp_theme_layout('2cvr,2cvl,v3c,v3cr,v3cl,lgn,rgn')) { ?>
                        <?php if (is_cp_theme_layout('lgn') && !comicpress_disable_sidebars()) get_sidebar('right');  ?>
                                <div class="clear"></div>
                        </div>
                        <?php } ?>
                <?php if (is_cp_theme_layout('3c2r,v3cr') && !comicpress_disable_sidebars()) get_sidebar('left'); ?>
                <?php if (is_cp_theme_layout('2cr,2cvr,3c,3c2r,v3c,v3cr,rgn') && !comicpress_disable_sidebars()) get_sidebar('right');  ?>
                <?php if (comicpress_themeinfo('enable_caps')) { ?><div id="subcontent-wrapper-foot"></div><?php } ?>
                <div class="clear"></div>
        </div>
        <div class="clear"></div>
</div>
<?php if (comicpress_themeinfo('enable_caps')) { ?><div id="content-wrapper-foot"></div><?php } ?>

And here is my version:

                </div>

                <?php if (is_page()) get_sidebar('right'); ?>
                <?php if (is_home()) get_sidebar('right'); ?>
                <?php if (is_single()) get_sidebar('right'); ?>

                <?php if (comicpress_themeinfo('enable_caps')) { ?><div id="subcontent-wrapper-foot"></div><?php } ?>
                <div class="clear"></div>
        </div>
        <div class="clear"></div>
</div>
<?php if (comicpress_themeinfo('enable_caps')) { ?><div id="content-wrapper-foot"></div><?php } ?>

Just like in the header layout, I use conditional tags to render the sidebars only on pages where I want sidebars.

This is a simple hack, and enables you to have different layouts on different pages. Conditional tags can work for just about any conditions you can think of, so this is a great way to make your ComicPress theme more flexible.

One of the things I do in the script is add a new DNS record to a zone file in BIND and update the named server.  (Tiny bit of a background: DNS updating works by having serial numbers be larger that the previous update’s serial–these serials are typically a 10-digit numeric form of date+version (eg, the serial 2011072602 is July 26th, 2011 (20110726) & the (02) 2nd revision for today).) If my shell script needed to update the serial number which was already changed today, it would need to increment the version, which gets read in as a string.  That isn’t a big deal, as you can easily cast a string to be a number by doing $((variable)).  But it needs to be replaced by a 2-digit version again, so I used awk to make sure it was

ver="02"
echo $ver+1
02+1
echo $((ver+1))
03

ver="08"
echo $ver+1
08+1
echo $((ver+1))
08: value too great for base (error token is "08")

Well, the shell is trying to be clever: it knows that numbers that start with 0x are going to be in hex, and numbers that start with 1-9 are going to be decimals, and it thinks that numbers that start with 0 are octal (that is, base 8, or 01234567) so it doesn’t know what the heck an ’8′ is (its like trying to add 3+a in decimal–it just doesn’t compute).  To get around this, I need to force my variable “ver” to be numeric without the leading 0.

I use awk’s printf to do this as it seemed like the easiest thing (I really like awk).

ver="08"
ver2=`echo $ver | awk '{printf( "%d", $1 )}'`
echo $((ver2+1))
9

ver3=`echo $((ver2+1)) | awk '{printf( "%02d", $1 )}'`
echo ver3
09

Feel free to contact me if you’d like a copy of the script.

1) My recipe for Calla Lilies, a swetemete of great delicacye. 2) What geekes did in late mediaeval tymes.

I love that definition of alchemy: what geeks did in late medieval times.  It resonates particularly well with me, since by day I am a web developer and own a company called Alchemy, and by night I am a medieval historian (in an alternate universe, I’m a medieval history professor; in this universe, I’m very happy as a web developer). Naturally, our interest in history was part of the reason that Jonathan and I chose to name our company “Alchemy Computer Solutions.”

Margaret Atwood is spot-on when she says alchemy is what geeks did.  Of course, defining “geek” is tricky, but here I’m thinking of “geeks” as people who immerse themselves in a topic that others find arcane or tedious, and who devote themselves passionately to learning all they can about that topic.  Alchemists were, of course, seeking a way to turn lead into gold using the famous Philosopher’s Stone, but in the process, what they were really doing was trying to understand how the world works.  They were trying to get to the very roots of what is knowable.  In the eras before computers and comic books, alchemy was a good outlet for the kind of people who feel compelled to learn all that they can about a topic.

One of the reasons we chose the name “Alchemy” for our company is that a lot of what we do seems like magic to those who don’t share our knowledge of computers.  When Jonathan fixes a server or I make a website do something nifty, it seems to our clients like we just worked some magic.  But of course, like alchemy, what we’re doing is really a science.  It might look like hocus-pocus to non-geeks, but we geeks understand the underlying code and processes.

What this ultimately means for my clients is that if I am doing my job right, they never know I am there.  Their servers run reliably, and they can go about doing their work without ever having to give a second thought to me or their servers.

I really like this behind-the-scenes nature of my work.  You know how they say that “behind every successful man is a good woman?”  Well, behind every good technology company is a good sysadmin.