Created: 2014 December 28 20:40
Time to read: 3 minutes
I have moved my site from one domain to another. I was using Wordpress on my old site and was happy. Adding pages was a thing of beauty. Configuring was a dream. Then I wanted to modify my theme. Then I wanted to use some fun HTML5 tags. Then I wanted to minimize hacking vectors. Then I realized that I was sacrificing performance to use a database that I was merely using to dynamically create static content... why?
If only Wordpress were as performant and easy to theme as the first blog I cobbled together using static PHP files back in the early aughts. Ah, that first blog was easy to add funky HTML syntax and add features; but each new page required editing 3 PHP files so the menu, archive, and each individual page would use the new content. At one point, I figured out that if I used a common naming structure, that I could tell the menu to dynamically build by looking at the file structure — thereby reducing the need to edit the menu.php file. Success!
I muddled through with Wordpress (did I mention the constant need to stay on top of updates and patches for Wordpress and associated plugins?). Then I discovered Sculpin.
The immediate benefits to Sculpin that I could see were:
In other words, the benefits are that I can utilize it now and benefit, I learn its components now and I can utilize that knowledge later (CSS, Bootstrap, twig, HTML5, etc).
As I started to play with Sculpin, I kept thinking back to my original blog and how close I was back then to what I am now doing. What I was missing then was the generation of the static HTML files that Sculpin allows.
I spent too much time this weekend trying to figure out how to edit my Sculpin site locally and yet keep that version-controlled via git as well as keeping my production code version-controlled via git. Happily, I believe that I have found a way to do both.
I keep my in-progress code, which includes minor modifications to the blog skeleton, in a Bitbucket repo. I keep my production site, which is generated by Sculpin, in a Github repo, which is actually what you are reading right now. To keep the two segments segregated, I am doing the following:
On my dev machine, I have the following directory structure:
+-ericpoe\ | +-+- ericpoe.sculpin\ | +-- ericpoe.github.io\
ericpoe.sculpin directory, I keep my sculpin blog skeleton and my Markdown source files. I have two remotes:
origin, which points to my draft on bitbucket, and
sync, which points to the source of the Sculpin blog skeleton.
ericpoe.github.io directory, I keep the html files generated by the
sculpin generate --env=prod command.
Tying it all together, I keep three bash files in my root
#! /bin/bash cd ericpoe.sculpin git checkout master git pull sync master
#! /bin/bash if [ $# -ne 1 ]; then echo "usage: ./draft.sh \"commit message\"" exit 1; fi cd ericpoe.sculpin git checkout master git add . git commit -m "$1" git push -u origin master
#! /bin/bash if [ $# -ne 1 ]; then echo "usage: ./publish.sh \"commit message\"" exit 1; fi cd ericpoe.sculpin sculpin generate --env=prod cd ../ericpoe.github.io git checkout master cp -R ../ericpoe.sculpin/output_prod/* . git add . git commit -m "$1" git push origin --all
My workflow now is to:
sculpin generate --watch --server
This simple workflow will allow me to explore other technologies and to concentrate on the topic-at hand while posting about it here.
Corrections or curious to see how this was put together? Check out the latest version of this site at its github repo.