Now with Sculpin

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:

• Static file generator
• Files are created using Markdown, which means I can add funky HTML tags when necessary.
• The base project is written in open-source PHP, which means that I can bugfix and extend the source as I see fit.
• Theming is done via twig & CSS (currently using bootstrap)
• No performance loss due to dynamically generating a view via database lookups.
• Nice community (a huge bonus!)

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.

Making it work

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\

Within my 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.

Within my 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 ericpoe directory:

sync.sh:

#! /bin/bash
cd ericpoe.sculpin
git checkout master
git pull sync master

draft.sh:

#! /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

publish.sh:

#! /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:

1. create a new Markdown file with the yaml tuple draft: true
2. create my text
3. test my text via sculpin generate --watch --server
4. make any changes needed
5. backup the draft by running draft.sh
6. if I feel ready, remove the yaml tuple draft: true
7. publish to my site, which is hosted by github, by running publish.sh
8. every now and then, when the need strikes, update the core code by running sync.sh

This simple workflow will allow me to explore other technologies and to concentrate on the topic-at hand while posting about it here.