I’ve been doing some work on the starter theme we use for all client projects (more on starter themes & custom work here) and thought it’d be interesting to share the current set of steps necessary to get it set up for a new project.
Also, next week I’ll be launching a limited enrollment beta version of my new online course that teaches whole process in excruciating detail (along with how to actually work and customize with all of the files in the theme itself). Sign up for the WP and/or workshops lists here for first dibs.
Here’s what it currently takes to get the starter theme ready for development:
The theme is hosted as a private Github repository, for easy access across our team. So the first step, then, is to download the theme from Github. I could copy the local directory, but sometimes I mess that up so I just download the zip each time for now.
Next, I do a bunch of renaming, replacing the starter theme name with the project name. The folder itself gets a new name, and I use String Replacer to do a bulk find and replace operation to change function names and other instances throughout all the files.
At this point, I move the theme to the directory where it’ll live while I’m working on it (which is synced with Dropbox), and then I open it in Terminal via drag and drop. I also open the directory in Espresso, which is my text editor of choice, again by dragging the folder icon onto the application in the dock.
Next, I run
npm install in Terminal, which installs all the Gulp dependencies (all the files needed for the tasks we run using Gulp).
One thing that isn’t captured by my bulk find-and-replace is the theme meta information in the stylesheet, so I update that next in Espresso by editing the
/scss/style.scss file. Once that’s updated, I switch back to Terminal and run
gulp to compile the CSS for the first time (getting my main directory
style.css all set up with the new meta info).
Next, I run through a set of steps to set up version control using Git. I’ve historically used Tower, which is a Git GUI, to handle these steps because it’s been easier as I’ve gotten more comfortable with Git. Now that I feel more at ease in Terminal, I’ve done this a few times on the command line as well, just because I’ve been too lazy to open Tower. Either is fine, I try not to stress about the method too much. The general flow is: create local repository (
git init), stage all the files (
git add -A), run an initial commit (
git commit -a -m 'initial project commit').
We use BitBucket for client repositories because they have unlimited free private repos (Github has a limit), so next I log into BitBucket, create a repo there for the project, and add relevant members of my team. Then, I grab the access link and jump back to Terminal to push my local repository up to the remote version (for backup and cross-team access) using
git remote add and
Next, depending on the project we often set up automatic deployment using DeployHQ so that every time we push future commits, the remote server also gets the updates. This is convenient in a development situation but I would not suggest automating it on a live site. The sub-steps for this include getting the theme directory set up on the server, connecting Bitbucket and DeployHQ (really easy – DeployHQ connects right to the Bitbucket account and lays out the steps to take on the BitBucket side), and entering server credentials in DeployHQ.
At this point, I’m ready to work on the theme itself, and all that setup ensures that much of my process from here out is nicely automated (Sass processing, version control, even deployment)!
Clearly, this setup process is not the most efficient thing in the world, although it’s gotten quicker with practice. We’ve been working on automating some of these steps using Yeoman, which I’ll share more about once we get it fully up and running. I’ll also be making my starter open source in the near future, once we’ve done a bit more cleanup.
Update: About all those tools
I realized after writing this post that I name-dropped a ton of stuff without really explaining what it is (Grunt, Gulp, git, etc.) so I wrote a follow up post explaining what they are and why I use them.