Workflow for Setting Up a Custom WordPress Theme Project

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.

NOTE: I am just running through the steps in this post, not so much going into what each component or tool is or does. I would love to know which pieces don’t make sense or aren’t familiar to you so I can elaborate on them in the future.

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.

New theme ready for set up in Terminal and Espresso

Ready for more set up!


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 git push.


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)!

Improving Efficiency

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.

Considerations (Beyond Licensing) When Picking a Web Font

While licensing is a great place to start when picking a web font for a project, there are a few additional considerations to keep in mind before you hit the “buy” or “download” button.

Font Family Considerations

One of the first things you should look into when picking a web font is whether it’s available in the various weights and styles you’ll need for your particular use case.

For body text, you’ll need a font that at least has a normal weight along with italic, bold, and bold italic versions in the family. That set of four takes care of all your basic text formatting needs.

It is NOT a good idea to use a font that doesn’t have those four basic styles unless you will have absolute control over how the font is implemented (not usually the case with body copy that is editable via a content management system such as WordPress).

You do not want to allow a browser to fake any of those styles as the results from faux-italics and faux-bolding are just not the same.

Faux vs real font style and weight demo

Demo of faux styling vs real font styles, screenshot from Chrome 32 for Mac

Beyond how the quality of the typography, some browsers actually make the faux-bolded text look blurry or as if it’s got a distinct shadow which can make it illegible in certain applications (or, best case, really bad looking).

Browser Rendering Considerations

It’s a good idea to have a conversation early in the design phase about how web fonts are going to vary a little bit in how they look across browsers, which is ok within reason.

This can be especially hard for designers and clients with backgrounds in print to wrap their heads around, but still better to discuss it early rather than face disappointment in the end when we just cannot adjust fonts to be exactly the same in every browser and context.

There are two main consideration with regards to font rendering on the web:

1. How does the font render on the web compared to design files?

Fonts tend to display heavier on the web than in design files. If you want minute control over the weight of your type, you may want to choose a font that has multiple available weights. I sometimes find that using a weight one thinner/ lighter online than the one specified in the PSD or AI design file gives me better visual match, but it depends on the font, the size, the color, etc.

Additionally, depending on the context the display in Chrome specifically is a bit off, erring too heavy. This can sometimes be adjusted using -webkit-font-smoothing: antialiased; as shown in this extensive demo:

-webkit-font-smoothing demo

Font-smoothing demo by Christoph Zillgens, screenshot taken in Chrome 32 on a Mac

Weight is one specific concern, but there are other inconsistencies in font rendering which brings us to the next consideration:

2. What about across different browsers and operating systems?

Beyond the weight, the way a font looks in terms of letter forms, spacing, and legibility, can be inconsistent across browsers. This is often true with fonts that have had less time and attention put into the design and technical file creation, and occurs more often at small sizes than at display/ headline sizes.

Some font sites have tools that let you preview a particular font at various sizes:

You’ll want to actually open that preview in various browsers to check it out, especially if it’s a font you’re going to use for body copy at smaller sizes.

A little variation across browsers is okay, but you definitely want to pick fonts that are legible at the sizes you need.

A Note About Tracking

This is not really specific to choosing a web font, but I also think it’s helpful for designers to know that letter-spacing is not as refined tracking (the desktop program equivalent), and is inconsistent across browsers.

For more on this, check out this explanation, which is a bit old but has good infomation and links to this demo where you can compare Photoshop text and HTML text in real time using any browser:

Letter-spacing demo comparing Photoshop to HTML/ CSS

Letter-spacing demo by Justin Marsan, screenshot taken in Chrome 32 on a Mac

In general, it’s another place you’ll need to be careful with when designing and accept that your web font display will probably never be exactly the same for all browsers and devices. Which is not to say we can’t get really close if you’re thoughtful with your designs, because we can! Just not identical across all contexts.

More on Web Fonts

New to web fonts, or just looking for more info (including how to actually work with the files once you’ve got them)? Check out my Learn Web Fonts page, a compilation of great articles and resources on the topic.

Survey Says More Coding

Survey says "I heart you all"

Thanks to all 52 of you who filled out my survey on what you want to learn this year!

It was so fun hearing from you and I was completely blown away by all the nice things you had to say. Looking through the results was a truly lovely way to start my Valentine’s Day!

About You All

The breakdown as far as who self-identified as what was pretty much along the lines I expected:

Reader jobs and roles from 2014 blog reader survey

To put some numbers on that chart, of the 67% of respondents that identified as a developer, the majority are beginners. In fact, about 56% of the people who took the survey consider themselves beginning developers.

A whole lot of you (~63%) are web designers and way more freelancers/ small business owners than people who work as employees for others (which I think is interesting as someone now in a position to be hiring employees).

Favorite Types of Posts

I’m not sure the ranking format was the best choice for the question about types of posts, but regardless I was pretty surprised to find that long coding tutorials are by far the favorite:

Item Total Score Aggregate Rank
Coding tutorials (long ones) 244 1
Business posts (process/ workflow/ running a business) 189 2
Code snippets (short, less explanation) 187 3
Case studies of recent projects 168 4
Resource posts (lists of resources/ links) 168 5
Posts about managing sites & content (non-code) 136 6

I’ll certainly work on writing more of those, although like a few of you pointed out they are pretty time consuming to put together.

Things You Want to Learn

While there was a wide variety of stuff you all shared about where you are in your careers and what you’re interested in, there were also some definite trends. Themes included:

Coding Basics: HTML, CSS, PHP, jQuery, Javascript; GIT; how to put all that stuff together into a website

WordPress: WP and subdomains; site migration; custom theme building; development sites & multisite; security; theme options; plugins; site strategy

Shopify: getting started with Shopify theme development

Specific Coding Tutorials: ajax; different kinds of menus; customized comment areas; slideshow galleries; one page websites

Development & Designing: responsive web design & designing/ coding for various screen sizes and devices; collaboration with designers; coding best practices (what works/ what doesn’t); web design do’s and don’ts; trends in web design/ development; more process posts (especially details about various parts of the process)

Business & Marketing: starting out as a freelancer and/or developer; maintaining & building a business; efficiency tips; case studies; process details; marketing my/your self

Clients: client education/ training; finding your niche & building up a client base

A few people also expressed interested in online and/or video tutorials or classes similar to the classes I’ve taught here in Philly (and on additional topics), which is certainly something I’m considering!

I’ll definitely be keeping all of your suggestions in mind as I plan out my content over time – there are a lot of great ideas and questions in there. At the same time, these responses point out a need for me to continue figuring out how to best organize my existing content so it’s easy to find so I’ll be working on that as well.

A Little Thank You

I decided up the “prize” factor, so instead of one 45 minute one-on-one, I’ve randomly selected two people who’ll each get 45 minutes of my time to ask me anything (except for work time on their websites).

To make these selections, I exported the entry data from only people who opted for the chance for the time (33 people in all) and opened it as a spreadsheet with 33 rows. Then I used the number generator to generate two random integers between 1 and 33, which ended up being 14 (Demoree) and 26 (Shivani).

For Everyone

While I can’t promise individual answers for everyone, there are three ways to get your questions in front of me for possible answers:

  1. For super quick questions, I’m on Twitter more than is probably advisable
  2. For longer questions, you can contact me with your question and I’ll consider turning it into a blog post or shoot you an email response if I have time
  3. You can also book hourly consulting time if you have big questions and want to invest in dedicated time to talk things through. Use the general inquiry form to request time and be sure to give us an overview of how much time you’re looking for and generally what types of questions you have.

Thanks again for reading my blog, I can’t tell you enough how much I appreciate it!

Project Flow: Inquiry to Live Site

FYI: This is a completely rewritten update to a post originally published in March 2013, revised to reflect adjustments I’ve made to my processes over time.


In my current project management workflow, there are 8 phases that my assistant and I track projects over:

  1. Initial Inquiry
  2. Quoting & Estimates
  3. Confirmation/ Scheduling/ Paperwork
  4. Design Phase
  5. Design Transfer
  6. Active Development
  7. Testing
  8. Site Completion/ Wrap Up

We use a Trello board with the ultra-creative name “Project Status” to keep an eye on where things are:

Trello project status board

Click to enlarge

If you look really closely at those tiny little columns, you’ll see that there are actually 2 more columns than phases, which I’ll mention further as we get to those stages.

Read the rest →

Understanding Web Font Licensing Structures

font licensing options from

Screenshot from, where licensing is relatively clear

As a follow up to last’s week’s non-technical introduction to web fonts, I’m back on the Aeolidia blog today going into more depth on licensing structures for web fonts.

I’ll tell you straight up – web font licensing is very confusing. There are a lot of different types of licenses, many of which require that you know about how many pageviews per month you’ll have. A particular font may be available from multiple places with different licensing terms.

Hopefully this post will shed at least a little light on what to look for and keep in mind as you’re font shopping.

To the Post