DEV Community

loading...

Why I built my own WordPress theme

Jackson Lewis
A full stack developer, obsessed with performance, loves the outdoors.
・5 min read

With the WordPress eco-system flooded with themes, it's easy to get fixated on the idea that you have to use one that is already out there. But if you think about it, these themes are generic and are made for the general community, and not your individual style. So I took matters into my own hands and built a theme from the ground up, tailored to my own needs.

Let's follow the journey of the decisions made that led to the creation of my own WordPress theme!

Framework's aren't for me

I don't know who needs to hear this, but it's ok to not use frameworks/libraries if you don't like them. For me, I absolutely hated the idea of all the unused code from parts of the framework that I wouldn't plan on using.

Now you may be thinking, "Aren't we meant to be talking about WordPress themes?!". And yes, we are, however a framework is at the core of a theme. So it was a good idea to think about this first when going about creating a theme.

Now that I understood why I didn't want to use a framework for the fundamental HTML/CSS structuring, I began creating my own, but one that would solve the issues I have with existing frameworks.

Understanding what I wanted out of a theme

Moving onto the actual WordPress side of things, this would be where the theme would be tailored into something that could get the most out of. I had lots of ideas for things like helper functions that would reduce repetitive tasks such as calling an image on a template, or pre-built segments of the page such as a site header.

Here's a list of just a few of the things I specifically wanted:

  • Various utility functions for calling images on templates - something that really really bothered me was seeing the exact same code for rendering an image dotted about across various templates for a site. It was clear to me this needed resolving with the help of some nifty utility functions, which influenced shiftr_image() and shiftr_featured_image(), with one for general images and the other specifically for post featured images.
  • Separated configurations for development and production when compiling assets - after some playing around with gulpfile.js, I found that running minification processes on development slowed down compiling times, which lowers productivity. I also felt like source maps are unnecessary in production, and increase the file size of the respective compiled file. So being able to have full control and split particular tasks between development and production environments was a great achievement.
  • Integration with Advanced Custom Fields - every WordPress site I work on uses this plugin, so it only made sense to make sure it would be as effortless as possible to use it. Some of the utility functions as mentioned above, like shiftr_image(), use ACF functions to easily work with a ACF Image field automatically.

I found having a list of ideas like the above very helpful in understanding what the actual purpose of this theme would be, which gave me more motivated to get the damn thing built!

Hello, Shiftr

First off, I am one of those that absolutely loves naming and branding my personal projects, and my own WordPress theme was no exception. Let me introduce to you Shape Shiftr, or Shiftr for short. This is a WordPress blank starter theme built completely from the ground up with its own CSS/JS framework.

The stack

Shiftr has seen a few big updates since its initial release in early 2019, so to keep it simple, I'll just run over the current, more modern stack in use.

  • Gulp (v4)- The task runner used for everything while building, from hot reloading with browsersync, to compiling assets.
  • Webpack - I took the leap and opted for webpack here, so I could utilize ES6 import/exports which has made working with code in multiple files super easy. Some may say I'm crazy, but my love for JavaScript was really taking off at the time so I wanted to be able to use the most modern syntax.

Screenshot from VS Code showing a snippet of the code in the gulpfile currently used by the theme

Top features

What I find most rewarding after creating your own theme is then going onto use it in real projects. To date, Shiftr is used in 12 production sites, all built by myself. So over that time I have been my own critic of sorts, finding anything from bugs to improvements that could be made. I'll walk you through a few of the top features that make a real difference to my day-to-day work while using the theme.

  • Image functions: These are ultimately just wrapper functions to wp_get_attachment_image(), but has made adding images something that I no longer have to think about. I'm just going to quickly say, if you don't have something like this your theme, you seriouslyyyy need it, right now!
  • SEO-ready: I personally feel it is only fair that every website is built on a foundation that can be easily optimised for SEO. Shiftr includes everything from being optimised for performance to correct semantic layout of headings across templates.
  • Flexi template: This has to be hands down the biggest success to come out of the theme. Utilizing the Flexible content field in Advanced Custom Fields, I created a template that made it super easy for content creators to add and reorder sections of a page as they needed. This brought convenience and scalability to a site. It has evolved heavily to the point I dedicated a lot of time working on a great little API of sorts making it super easy to add new blocks to the template.

Screenshot from VS Code showing a snippet of the PHP code that makes up the Flexi template

Staying ahead of the game

As mentioned in the previous section, I've tried to update the theme with new features, bug fixes and general touch-ups at least once every few months. I found it really important to stay on top of these updates, because as and when I would either find a bug or think of a new feature, I would end up just copying directly from one project to another, without ever actually putting the code into the source of the theme where it would be instantly available for future projects.

There can also come a time when WordPress catches up with modern tech. For instance, in WordPress 5.5, the core team brought native lazy loading with some help from the team at Google (I suspect). Now Shiftr already had Google's recommended implementation of lazy loading. So, on the working assumption that Shiftr would only be used with the latest releases of WP, I set about removing my lazy loading, as that can now be handled by WordPress itself.

So there we have it, my journey of developing my own WordPress theme that meets my every need. Feel free to check out the code for yourself over on GitHub, you may use it to find inspiration in creating your own theme. Thanks!

Discussion (3)

Collapse
stefanobartoletti profile image
Stefano Bartoletti

Some of these features seem pretty interesting, I think that I'll have a look at your theme.
I went the same road as you, being unsatisfied with themes but with generic use in mind (and that I needed to heavily cleanup) I built my own starter theme, and after a couple of years of development I released it open in these days :)

Collapse
jacksonlewis profile image
Jackson Lewis Author

Thank you very much. I think in the long-term, it definitely pays for itself! The whole processes almost forces you to understand exactly what goes into making a theme work, from adding theme support to removing unnecessary cluster like emoji's if you don't need them, things you wouldn't know about if it weren't for creating your own. Again, thanks for reading :)

Collapse
stefanobartoletti profile image
Stefano Bartoletti

Totally agree, by building my own starter theme I was also aiming at better understanding the whole WordPress development process, and I ended learning really a lot more than this.
By the way, if you are interested, here is the article where I describe it dev.to/stefanobartoletti/introduci...
:)