A WordPress Theme Development Stack

When building things for the web, we normally refer to “the stack” as the set of software that we use that powers an entire application. Generally speaking, this usually consists of three things:

  1. The database
  2. The application layer (or the server-side programming language
  3. The front-end

Today, there are many different types of data stores available: We can use anything from a traditional database to using a document-based database system, or some type of abstraction provided by another service like Amazon.

For the application layer, we can have Rails, PHP, .NET, Python, and who-knows-how-many-more. And for the front-end, we generally use HTML/5, CSS/3, and JavaScript (and variations thereof).

But if a stack usually refers to a set of languages, tools, or technology that goes into building something, and each area of an application can be further divided into subsets (like with the front-end), does it make sense to have terminology for each of these areas as well?

The Traditional Development Stack

Technically, we do have terminology for each of these areas – they’re listed above – and those who work on all areas are generally referred to as “full stack developers.”

But what if you’re primarily a front-end developer, or an application layer developer, or any-layer developer? When referring to each part of the stack, we usually say that we have a set of tools, frameworks, libraries, or dependencies that we use.

Open The Jar

That makes sense, too. I mean, we don’t want to start overloading terms that generally refer to the full application in the context of part of an application. This is why we have terms like backend-developer, application developer, front-end developer, and so on, right?

Just as we generally have a set of predefined technologies that go into a stack (such as IIS, Microsoft SQL, and NET or Apache, MySQL, and PHP, or Apache, Java, and Server Pages, and so on), what if we were to have a set of common technologies that we use to create WordPress themes?

What’s a WordPress Theme Development Stack?

Though when thinking through this in the context of building WordPress themes (which are predominately for the front-end), does it make sense to have a pre-defined set of tools that you typically use to get your work done?

This is not to say that I think there should be a single set of tools that we all use to build themes – not at all – but for each project, rather than choose yet-another-CSS-framework or yet-another-JavaScript-library, what if we were to, say, spend a year building themes with nothing but a single set of tools?

What would it look like if we were to focus solely on a small set of technologies with which we use to assemble themes for a year?

For example:

And we can take a little bit further and say:

  • Templates will be creating with vanilla PHP (or maybe with something like Timber?)
  • All documentation will be written in Markdown (which variant?)

Maybe we’ll tie it all together with something like CodeKit, Gulp, Grunt, or some other build tool.

Granted, there are far more options than what’s listed above that are available for us to use. These are primarily shared as an example of what could be used. It’s not so much about the specifics of the tools that we choose, but the set of tools that we use and how they interact with one another.

During a time where there are a near-impossible number of things to learn and to use, the idea of doing deep dive with a handful of technologies in an effort to become an expert in each and to assemble a number of products using each tool seems like a novel idea.

It's Not Impossible
Well, it’s not impossible. About as possible as this, I guess.

So say that for one year, you had to pick a stack of technologies with which you’d be building commercial WordPress themes (versus those for contract work). What technologies would you choose and, for fun, why?

7 Replies to “A WordPress Theme Development Stack”

  1. It’s hard to tell what constitutes an asset or library and what a tool to you (FontAwesome as part of a technology stack?). But here’s my every-day WordPress theme development stack:


    Of course, this is all on top of the stack that runs WordPress:


    And here are some of the reusable tools, components and assets I’ve used over and over again:

    Custom gallery code that is part Justin Tadlock and part me, tailored to the needs of Lightbox2.
    Dashicons (Thanks WP core!)
    TGM Plugin Activation
    Easy Digital Downloads – Software Licensing
    Bootstrap’s Dropdown component in conjunction with this navwalker

    1. I generally think of assets as images and fonts that go into a theme and libraries as just that; however, I know people who treat everything as an asset.

      I’m neither really here nor there about it.

      Either way, I still dig seeing some of the things that you’ve shared, especially the NavWalker for Bootstrap. It’s sorely needed.

  2. WP Engine + WP
    underscores.me + Zurb Foundation + LibSaas & Grunt
    Roots.io +Zurb Foundation + LibSaas & Grunt

    Timber looks very interesting…

    How deep do you go?

    Gravity Forms
    Advanced Custom Fields
    Yoast SEO

    Delivering results for clients is much easier when you don’t reinvent the wheel every site. Make some decisions, pick some tools, and go make it happen.

    1. All of these are good. And I really agree with this:

      Delivering results for clients is much easier when you don’t reinvent the wheel every site. Make some decisions, pick some tools, and go make it happen.

      This isn’t a loaded question, but why Foundation over Bootstrap? I’ve used both, so I don’t really have a bone to pick – I just like hearing other developers rationale. :)

  3. SASS

    As for inside WP:
    Advanced Custom Fields

    Work for a digital marketing agency that builds websites and this is what I use daily. Can’t live without SASS now that I’ve used it, and CodeKit just has so many toolkits included (autoprefixer, JSHint, source maps).

Leave a Reply