Hacking & Bodging a Git Hook + Vagrant + WP-CLI + Bash Local to Dev Database Transfer

Ever since I started using Git to push local website changes to a development server, I’ve been vaguely irritated about dealing with the database in the same manner. For a long time, I used interconnect/it’s Search Replace DB for this side of things, but I was always wondering if I could somehow increase laziness time by automating the process. One hungover Sunday, plus a couple of hours on Monday, and one hacked and bodged success.

This isn’t a “How to do yer Git + Vagrant + local to dev” thing, nor is it a copy-paste, “Works for me!” party. Nonetheless, provided you’re using git-push, and are comfortable with WP-CLI or MySQL command-line, Bash, and generally thrashing small bits of code around, in principle it would work in any situation. And I do feel kinda dirty throwing all this into Git post-receive, but whatever seems to work.

So, here’s what I wanted to do:

  1. Do all my commits, and run git-push and throw all the file changes to the dev server.
  2. Combine that with a dump of the database, then get it to the dev server.
  3. Use something at the other end to import the database, and search-replace strings
  4. Clean up after at both ends.

When I first looked into this, it seemed using the pre-commit Git hook was the most common approach, dumping the database and adding it to the commit. I didn’t want to do this, for a couple of reasons: I do a lot of commits, and the majority have no database component; I wasn’t looking to version control the database; All I wanted to do was push local to dev database with the changed files. Looks like a job for pre-push hook.

Earlier this year, I started using Vagrant, so the first issue was how to dump the database from there. I do commits from the local folder, rather than SSH-ing into the VM, so mysqldump is not going to work without first getting into the VM. Which brought its own set of weirdnesses, and this was the point when I decided to flop over to WP-CLI, the WordPress command-line tool.

I often find solutions to this sort of thing are dependant on the combination of software and commands being used. I use mysqldump on its own all the time, but here, I needed to use Git to set the path for where the database would be dumped to — because git hooks are in a sub-directory of the git folder — and that, in combination with dumping the database inside the VM while within a Git command running from the local folder (yeah, probably should just do all my git via SSH), and hurling it at a remote server, means sometimes things that work in isolation get cranky. And this is a hack/bodge, so I went with:

  1. Set up paths for the database dump with Git, ’cos Git is running this show.
  2. SSH into the Vagrant box.
  3. WP-CLI dump the database to a gzipped file.
  4. SCP that up to the dev server.
  5. Delete all that on the local server, ’cos I’m tidy.

That’s half of it done. I’ve got my pushes working, the database file is up on the dev server, the local server is all cleaned up, so now it’s time for the other end.

In this case, I was doing it for a site on DreamHost, who conveniently give all kinds of fun command-line access, plus WP-CLI on their shared servers. Once Git has finished checking out the new file changes in post-receive, it’s time for frankly bodging it.

My current usual setup is a bare repository on the dev server, which checks out to the development website directory. This means neither the uploaded database, nor WP-CLI and the WordPress root are in the same place as the running hook. No big deal, just use –path=. The next thing though, is cleaning up post-import. Strings to be changed all over the place, like local URLs swapped to dev. And for that we have, wp search-replace, which is an awful lot like Search Replace DB. At the dev end then:

  1. Set up paths again, this time it’s WP-CLI running the show.
  2. Unzip the database then import it.
  3. Do database stuff like search-replace strings, and delete transients.
  4. Delete that uploaded database file on the dev server, ’cos I’m tidy.

I was looking at all this late last night, all those repeating lines of ‘wp search-replace’ and I thought, “That looks like a job for an array.” Which led me down the tunnel of Bash arrays, associative arrays, “How can I actually do ‘blah’, ’cos bash seems to be kinda unwilling here?” and finally settling on not quite what I wanted, but does the job. Also, bash syntax always looks like it’s cursing and swearing.

The pre-push hook:

#!/bin/sh

# a pre-push hook to dump the database to a folder in the repo's root directory, upload it to the dev server, then delete when finished

echo '***************************************************************'
echo 'preparing to back up database'
echo '***************************************************************'

# set up some variables, to keep things more readable later on
# backup_dir is relative to git hooks, i.e. 2 directories higher, so use git to set it

ROOT="$(git rev-parse --show-toplevel)"
BACKUP_DIR="$ROOT/.database"
DB_NAME="database"

# check there is a database backup directory, make it if it doesn't exist then cd to it

if [ ! -d "$BACKUP_DIR" ]; then
mkdir "$BACKUP_DIR"
cd "$BACKUP_DIR"
else
cd "$BACKUP_DIR"
fi

# cos this is vagrant, first ssh into it. there will be a password prompt
# using EOF to write the commands in bash, rather than in ssh quotation marks

ssh -t vagrant@172.17.0.10 << EOF

# cd to the new databases folder. this is absolute, cos is vm and not local folder
cd "/var/www/user/domain.tld/.database" 

# then export the database with wp-cli and gzip it
wp db export --add-drop-table - | gzip -9 > $DB_NAME.sql.gz

# exit ssh
exit

# bail out of eof
EOF

# scp the backup directory and database to dev server
scp -r $BACKUP_DIR user@domain.tld:~/

# remove that backup directory so it's not clogging up git changes
rm -r $BACKUP_DIR

echo '***************************************************************'
echo 'all done, finishing up git push stuff'
echo '***************************************************************'

The post-receive hook:

#!/bin/sh

echo '***************************************************************'
echo 'post-receive is working. checking out pushed changes.'
echo '***************************************************************'

# check out the received changes from local to the dev site
git --work-tree=/home/user/dev.domain.tld  --git-dir=/home/user/.repo.git checkout -f


# import the database with wp-cli
echo '***************************************************************'
echo 'starting database import'
echo '***************************************************************'

# setting up some paths
# on some webhosts, e.g. all-inkl, setting the alias to wp-cli.phar is required, uncomment and set if needed
# alias wp='/path/to/.wp-cli/wp-cli.phar'

# the path to wp-config, needed for wp-cli
WP_PATH="/home/user/dev.domain.tld/wordpress"
# database directory, created in git pre-push
DB_DIR="/home/user/.database"

# check there is a database directory
if [ -d "$DB_DIR" ]; then

	# then check it for sql.gz files
	DB_COUNT=`ls -1 $DB_DIR/*.sql.gz 2>/dev/null | wc -l` 

	# if there is exactly 1 database, proceed
	if [ $DB_COUNT == 1 ]; then

		#grab the db name, this way the db name isn't hardcoded
		DB_NAME=$(basename $DB_DIR/*)

		echo 'importing the database'
		echo '***************************************************************'

		# unzip the database, then import it with wp-cli
		gunzip < $DB_DIR/$DB_NAME | wp db import - --path=$WP_PATH

		# clear the transients
		wp transient delete --all --path=$WP_PATH

		# run search replace on the main strings needing to be updated
		# make an array of strings to be searched for and replaced
		search=(
			"local.domain.tld:8443"
			"local.domain.tld"
			"/var/www/user/"
		)
		replace=(
			"dev.domain.tld"
			"dev.domain.tld"
			"/home/user/"
		)

		#loop through the array and spit it into wp search-replace
		for (( i=0; i < ${#search[@]}; ++i )); do
			eval wp search-replace --all-tables --precise \"${search[i]}\" \"${replace[i]}\" --path=$WP_PATH
		done

		# any other wp-cli commands to run
		wp option update blogname "blog name" --path=$WP_PATH

		# delete the backup directory, so there's no junk lying around
		rm -rf $DB_DIR
	
	else
	
		echo 'database was not found'
		echo '***************************************************************'
	
	fi

else

	echo 'database folder was not found'
	echo '***************************************************************'

fi

echo '***************************************************************'
echo 'all done'
echo '***************************************************************'

What else? Dunno. It’s pretty rough, but basically proves something I didn’t find an example of all combined into one: that you can use git hooks to push the database and file changes at the same time, and automate the local-to-dev database transfer process. Is this the best way to do it? Nah, it’s majorly bodgy, and would have to be tailored for each server setup, and I’m not even sure doing such things in a git hook is advisable, even if it works. It does demonstrate that each step of the process can be automated — irrespective of how shonky your setup is — and provided you account for that and your own coding proclivities, there’s multiple ways of doing the same thing.

(edit, a day later.)
I decided to throw this into ‘production’, testing it on a development site I had to create on webhost I’m not so familiar with but who do provide the necessities (like SSH and Let’s Encrypt). Two things happened.

First, WP-CLI didn’t work at all in the post-receive script, even while it did if I ran commands directly in Terminal (or iTerm as I’m currently using). After much messing about, and trying a bunch of things it turned out that this was an issue of “has to be tailored for each server setup”, in this case adding an alias to wp-cli.phar.

Second, having a preference for over-compensation while automating, it occurred to me that I’d made some assumptions, like there’d only be one database file in the uploaded directory, and that hardcoding the filename — which was one of those “I’ll fix that later” things — had morphed into technical debt. So, feeling well competent in Bash today, I decided for the “make sure there’s actually a database folder, then check there’s actually a sql.gz file in it, and there’s only one of them, then get the name of that file, and use it as a variable”. I often wonder how much of this is too much, but trying to cover the more obvious possible bollocks seems reasonably sensible.

Both of these have been rolled into the code above. And as always, it occurs to me already there’s better — ‘better’ — ways to do this, like in pre-push, piping the database directly to the dev server with SSH, or simultaneously creating a separate, local database backup, or doing it all in SQL commands.

Git Hook + Vagrant + WP-CLI + Bash Local to Dev Database Transfer

5-Character Dev Environment

Messing with my .bash_profile this afternoon, post-diving into Laravel and Git (which I’ve been doing much of the last week), I realised I could boot my entire dev environment with 5 letters. Fewer, if I wanted.

So instead of going to the Dock, clicking each of the icons, going to each and faffing around, I could at least boot them all, and set off some commands in Terminal (or ITerm2 as I’m now using).

Weirdly, until Justine gave me an evening of command-line Git learning, and wanted my .bash_profile, “Like so,” I hadn’t realised you could do stuff like that, despite amusing myself with all manner of shell scripts. Now I know what’s possible, I’m over-achieving in efficient laziness.

What’s missing is:

  • Opening multiple windows in ITerm or Terminal and running a different command in each (I don’t want to boot multiple instances of an app).
  • Setting off a menu action in an opened app, e.g. in Transmit going to my work drive.
  • Extending it to boot the environment and then a specific project, e.g. “devup laravel” would open my laravel installation in each of the apps, like opening the database in Sequel Pro; cd-ing to the laravel folder after automatic SSH-ing into my Vagrant box, and so on.

Some of these are probably uncomplicated, but this was a 30-minute experiment that turned out to be very useful.

5-character dev environment
5-character dev environment

Gallery

Neo-Grotesk Crypto-Brutalist emilezile.com

End of March, right when I’m throwing finally together my design portfolio (I swear I resisted, and now love having one), Emile asked if I might want to hurl together something for him. Something Web1.0, something like we’d handcode in HTML in the late-’90s, not quite something MySpace in the days of its browser-crashing gif-frenzy inferno, but definitely something that would be in its lineage; something tuner Nissan Skyline, unassuming on the surface, but all Fast & Furious: Tokyo Drift when you pop the hood. Something Helvetica, Neo-Grotesk, what’s getting called Brutalist right now, though not traipsing behind a fashion; this is Emile and when I was looking through years of his work putting his new website together, he has a deep love and understanding of the aesthetic, and the art and philosophy underpinning it.

First things first:

Emile: I have two websites. Can we make them one?
Frances: Yes!
Emile: Can we do all these other things?
Frances: OMG Yes!

Lucky I’d just done my portfolio, cos that gave me the framework to build on without having to bodge together fifty different functions and stuff. Saves a few hours there, which we made good use of in timezone-spanning conversations on typography, aesthetics, and usability.

First off, getting all those years of blog posts and work projects into a single database / website / organism. I used the hell out of interconnect/it’s Search & Replace DB script, merging, shuffling, shifting, getting rid of old code, jobs that would take a week or more to do by hand, done in seconds. We’d pretty much sorted out structure and functionality in a couple of afternoons; for a website that looks so simple, it was most of two weeks diligent work, back-and-forth conversations, picking away at details, (stripping and rebuilding, stancing, slamming, tuning … we are very good at turning all this into hoonage, especially with 24h Le Mans in the middle).

Obviously it had to be ‘Responsive’, look hella flush hectic antiseptic no matter what device, and for me (recently taking this stuff proper serious) it had to also be ‘Accessible’. I put those words in scare-quotes cos they’re kinda bullshit.

It occurred to me as I was finishing, that for a website to be neither responsive nor accessible — for example it looks crap if the screen size is too small or not ‘right’, or you can’t navigate with keyboard or screenreader — you have to actively remove this functionality. You have to break the website and override browser default behaviour. It’s a very active process to systematically remove basic functionality that’s been in web browsers since the beginning. You also have to actively not think, not empathise, intentionally not do or not know your job. Me for probably all of my earlier websites.

The funny thing is, it’s not really any additional work to make sure basic responsive and accessible design / functionality is present; the process of testing it always, always, always brings up usability issues, things I haven’t thought of, little points that become involved discussions about expectations, interactivity, culture, philosophy. Like ‘left and down’ is back in time, and ‘right and up’ forward; 下个礼拜 / 上个礼拜. Next week / last week. Yet the character for ‘next’ is xià, down, less than, lower; and ‘last’ (in the sense of ‘previous’) is shàng,  up, more than, higher. So how to navigate between previous and next posts or projects turns into an open-ended contextual exchange on meaning.

And ‘responsive’, ‘accessible’? Basic, fundamental web design. Not something tacked on at the end.

Back to the design. System fonts! Something I’ve not done in years, being all web-font focussed these days. Another trip through the wombat warren of devices, operating systems, CSS declarations. It’s crazy impressive how deep people go in exploring this stuff. Emile Blue! A bit like International Klein Blue, and a bit like Web / HTM 4.01 Blue. But not! We worked this in with a very dark grey and very slightly off-white, bringing in and throwing out additional colours, and managing in the end to sort out all the interaction visual feedback though combinations of these three — like the white text on blue background for blockquotes. Super nice.

As usual, mad props to DreamHost for I dunno how many years of hosting (it was Emile who said to me, “Frances. Use DreamHost.”), WordPress for running Emile’s old and new sites (and all of mine), and Let’s Encrypt for awesome and free HTTPS. And to Emile for giving me the pleasure of making the website of one of my favourite artist.

Emile’s new website is here: https://emilezile.com

DreamHost & Let’s Encrypt & WordPress

Mid-last year, Electronic Freedom Frontier announced Let’s Encrypt: free, automated, Open Source HTTPS Certificate Authority for everyone. That’s the padlock in the address bar. Supernaut and other sites of mine have either gone the parasitic paid route, or the “whole day lost and still not working” free route.

DreamHost, who has been my webhost for close to a decade (thanks Emile), announced in December they would be providing One-Click Let’s Encrypt setup for everyone, no matter what their hosting plan. Yesterday it arrived; It really is one-Click! Ok, two clicks, one checkbox, one select. Four things you have to do in DreamHost panel for what used to cost tens to hundreds of dollars/euros a year and hours of pain if you didn’t want to pay.

Awesome. Best thing that’s happened to the internet since ages.

Anyway, this isn’t about all that, it’s about “I have a WordPress site and how do I make the green padlock appear?” Cos that’s a couple more steps. Call it 15 minutes if you’re paying attention; an hour if you’re drinking.

So, you’ve already added the certificate in DreamHost Panel. No? To the DreamHost Wiki! Done that, wait for the confirmation email (might take a couple of hours), and on to your webserver.

I start with getting wp-admin all https-ified. Open your site in whatever FTP client you’re using, open wp-config.php and add:

define( 'FORCE_SSL_ADMIN', true );

Re-login to wp-admin, and check for the padlock in the address bar. Open Web Inspector (command-alt-i), select the Console tag and check for Mixed Content errors. Unless you’re doing weird things in wp-admin, that’s that side of things sorted.

In your site root directory, you’ll see a directory called “.well-known”. That’s added by Let’s Encrypt. Probably don’t want to delete that.

Open your root .htaccess and add two chunks of code:

# force redirect http to https
# ---------------------------------------------------------------

<IfModule mod_rewrite.c>
 RewriteEngine On
 RewriteCond %{HTTPS} off
 RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
</IfModule>

# https security headers
# http strict transport security (hsts)
# X-Xss-Protection
# X-Frame-Options
# X-Content-Type-Options
# ---------------------------------------------------------------

<IfModule mod_headers.c>
 Header always set Strict-Transport-Security "max-age=16070400; includeSubDomains"
 Header always set X-Xss-Protection "1; mode=block"
 Header always set X-Frame-Options "SAMEORIGIN"
 Header always set X-Content-Type-Options "nosniff"
 #Header always set Content-Security-Policy "default-src https://website.tld:443;"
</IfModule>

The first force redirects any requests for http to https. The second does some fairly obtuse header security stuff. You can read about that on securityheaders.io. (The Content Security Policy stuff takes a lot of back-and-forth to not cause chaos. Even wp-admin requires specific rules as it uses Google Fonts. Expect to lose at least an hour on that if you decide to set that up.)

Other ways of doing this are possible. It’s kinda unclear what’s canonical and what’s depricated, but WordPress Codex and elsewhere have variations on these (definite rabbithole, this stuff):

SSLOptions +StrictRequire
SSLRequireSSL
SSLRequire %{HTTP_HOST} eq "yourwebsite.tld"
ErrorDocument 403 https://yourwebsite.tld

<IfModule mod_rewrite.c>
 RewriteEngine On
 RewriteCond %{HTTPS} off
 RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

 RewriteBase /
 RewriteRule ^index\.php$ - [L]
 RewriteCond %{REQUEST_FILENAME} !-f
 RewriteCond %{REQUEST_FILENAME} !-d
 RewriteRule . /index.php [L]
</IfModule>

Then go through the remainder of your .htaccess and change any specific instances of your old http://yourwebsite.tld to https://yourwebsite.tld.

Open robots.txt and do the same, http changed to https.

Now’s a good time to empty your cache and check your live site to see how it’s going. Everytime I’ve done this so far it’s been all green padlock and magic S. But there’s still a couple of things to do.

Off to your Theme directory, open functions.php, and add these chunks of code:

/* content over ssl
------------------------------------------------------ */
 
function themename_ssl_content( $content ) {
 if ( is_ssl() )
 $content = str_ireplace( 'http://' . $_SERVER[ 'SERVER_NAME' ], 'https://' . $_SERVER[ 'SERVER_NAME' ], $content );
 return $content;
}

add_filter( 'the_content', 'themename_ssl_content' );

/* advanced custom fields over ssl
------------------------------------------------------ */

add_filter( 'wp_get_attachment_url', 'set_url_scheme' );

The first one makes sure your old http links in Posts and Pages are spat out as https. (Can probably extend that for excerpts and other things if you’re that way inclined.) The second was for me specifically dealing with Advanced Custom Fields plugin, and is part of a larger issue that’s been bashed around on Make WordPress Core. There’s a few other bits of code floating around for issues like this and the Media Library not behaving properly over https, but the next step I think deals with that, if you want to go that far.

Before that though, go through your theme for irksome hardcoded http strings. If you really can’t use proper WordPress functions (like get_template_directory_uri() or whatever), then change them to https.

Addendum:

Turns out WordPress’ responsive images support using src-set needs its own attention:

/* responsive images src-set
------------------------------------------------------ */

function ssl_srcset( $sources ) {
 foreach ( $sources as &$source ) {
 $source['url'] = set_url_scheme( $source['url'], 'https' );
 }

 return $sources;
}

add_filter( 'wp_calculate_image_srcset', 'ssl_srcset' );

If you fully commit to the next step though, these functions aren’t required.

(End of addendum.)

Database funtime! Backup your database, it’s time to search and replace. I’ve been using interconnect/it’s brilliant Search Replace DB for ages when I need to shift localhost websites to remote. Dump it in your WordPress folder, open it in a browser, and search-replace http://yourwebsite.tld to https://yourwebsite.tld. I do a dry run first, just to get an idea of what’s going to be changed. This step isn’t really necessary, and if you end up going back to http (dunno why), you’d need to reverse this process; it’s probably just that I like everything to be all orderly.

Another browser to make sure crap hasn’t fallen everywhere, and it’s cleanup time.

In wp-admin, check all the settings are showing https where they should (can even resave Permalinks if clicking buttons feels good). If you’re using a plugin like Yoast SEO, then checking the sitemaps are correct is good.

Caching plugins also need to be checked, and caches emptied. If you’re using W3 Total Cache and are manually minifying, check the file urls are all https, for some reason this was’t changed even with the database search replace. Also under Page Cache check “Cache SSL (https) requests”.

Then it’s checking in a couple of browsers with and without caching, particularly any pages that use plugins which embed or iframe content, or otherwise interact with stuff outside your website. Most sites like Vimeo, Twitter, YouTube etc that WordPress provides embeds for are already over https, but that doesn’t mean code in a plugin is up to date.

If you’re using Google Analytics or Webmasters or similar, you’ll need to set things up there for the new https version of your site as well.

Buncha caveats: Do some of this wrong and you will break things. At least backup your database before doing this. Some/all of this might be depreciated/incorrect/incomplete/not the best way to do it. Finding definitive, single ways to do things isn’t really how code works, so try and understand what the code does so you can ask if it’s doing what you want. For me to be able to do this in 15 minutes is because I’ve spent years scruffing around in stuff and breaking things horribly, and the best I can say is, this seems to work and cover the most common issues.

DreamHost. Let’s Encrypt. Excellent!

(I swear this is much quicker than it took to read.)

Categories & Tags Mayhem (∴ SQL)

Aside

I was just about to write on a few things I’m reading – Michel Serres, Black Metal Theory mostly – and suddenly felt an urge to clean up, merge, rename, delete some of the 1300 tags on supernaut, when I noticed something dead weird: some of the tags were simultaneously categories. Much messing around and the inability to edit or change taxonomies caused me to have a look at the database, where I found, horribly, they indeed existed as both. I guess this is either a hangover from the Movable Type port some years ago, or a plugin that didn’t do its job properly around the same time. So I manually deleting 50 or so of these and their relationships. And then did some more merging and renaming. And now I must eat.

misc. supernaut-ing

Aside

Yesterday, I updated to WordPress 3.6 then realised all the Post Formats stuff had been pulled from Core, and mediaelements.js was now in Core, so all my video was borked. Fixed that; discovered supernaut had been hacked back in April. Fixed that; made new favicons. Got annoyed by wp-admin slowness so spent an hour going through database cleaning out the options table (a curse on old plugins which don’t clean up after themselves when deleted). Realised some plugins weren’t working properly, deleted them, unexpectedly seeming to solve months of horribly slow/timing out wp-admin. Wrote a quick function to filter by Post Format in wp-admin. Felt rather pleased with self and taking that as a sign I’ve done something horrible which I’ll only notice in three months when supernaut farts itself and all backups out of existence.

WordPress 10

Aside

Happy birthday to WordPress, which is 10 years old today! I began using it for a site for Gala in 2007, having heard some good things about it and not wanting to torment her with Movable Type, which I was then in the thrall of. Since then, I’ve gone from, “Ooh! Make template changes and don’t have to wait for 1000 posts to be rendered!” to using it for every design project, and because of WordPress, I’ve learnt I know about PHP, CSS, dealing with servers, setting up a (proper) MAMP stack, jQuery, SQL, and all the things that I use to be a designer (currently learning Git, even). So here’s to WordPress, currently running 17% of the internet, and keeping me fed and roofed.

supernaut wordpress

Six months ago, deliriously annoyed with Movable Type, and deeply envious of all those people using WordPress. I install WP, throw a theme framework on top and promptly run away, terrified of what harrowing coding ordeals would ensue when I tried to make new look like old.

I have an end of year list of things to do. Coding for some, editing for others, rsync, asr, and other delights of command line backups for still another. For me, one was to use the brilliant, entirely CSS 100% background image for francesdath.info. That took all of 40 minutes or so, mostly in cleaning out my old junk from when I decided to code that version in an afternoon.

The other, of course, forced me to look at supernaut once more.

I’ve been using WordPress for all my projects lately, and the more I fall into it, the more I love it. A while ago, after much looking around, thinking, reading, and even a couple of trials, I decided on Blueprint CSS as the typographic CSS framework to build sites upon. Rather than lose time that could be spent sleeping…

Blueprint is a CSS framework, which aims to cut down on your development time. It gives you a solid foundation to build your project on top of, with an easy-to-use grid, sensible typography, useful plugins, and even a stylesheet for printing.

— Blueprint

… and a Photoshop layout to build designs upon that then can be transferred ridiculously quickly into a real site.

Of course the limitations are firstly of setting up a WordPress theme with all the necessary IDs and classes. Lucky someone else did that for me. Combining the Sandbox theme framework with the WSB Child Theme

WSB is a Sandbox child theme that provides tight integration with the Blueprint CSS. This is the conclusion of the method of integration discussed here. Using WordPress functions file, Sandbox template files, and Blueprint CSS files creates a excellent minimalist theme that is a very strong starting point for further theme development and customization

— Nedsferatu.com

… I began this afternoon and lazily poked at some CSS, a little hackery in one or two of the functions.php, some shuffling of the Sandbox templates php (which I could have done in css and left all this untouched but I was feeling lazy – much cheese and chocolate). To be pedantic, I began around 18h and it’s now 2315-ish, and with a good hour or more break in that time, so perhaps 4 hours of actual conscious attention, supernaut went from before to after.

(Mostly.)

supernaut before
supernaut before
supernaut after
supernaut after