WordPress themes – rebuilding The Stoner’s Cookbook

Among other things, I’m the CTO of a little website called The Stoner’s Cookbook. This month we released the first major site rebuild in years, and I wanted to post about the experience of building a WordPress theme from scratch. It’s a bit of a cathartic review of the process and illustrates the sort of issues you might deal with as a developer. I’m no expert, and might be (and am quite frequently) wrong, but it’s better to be wrong and learn something than think you’re right all the time.

But first, a little history.

The Stoner’s Cookbook

The Stoner’s Cookbook was a website I started with a friend way back in 2006. We were living in Auckland, New Zealand (where I still am), and where cannabis was, and still is, illegal. However, like most places, this doesn’t stop anyone here enjoying it.

It occurred to us, as I added cornflakes to a bowl of ice cream at 3am, that there was a food subculture for stoners. Much in the way pregnant women are supposed to crave unusual foods, stoners tended to munch on some rather odd and hastily assembled snacks. I almost choked myself after attempting to consume two weetbix, dry, and then suffering a coughing fit. But we would cook, fry or cobble together munchies that would seem disgusting by the light of day. So I said “why don’t we build a recipe website for stoners?” We were, after all, web designers.

Now the thing is, with the price and lack of availability of cannabis in New Zealand, we didn’t really consider creating a website of cannabis edible recipes – back then, edibles weren’t as much of a big deal. In New Zealand, if you were rich enough to splash out $350 for an ounce, you wouldn’t want to waste all of that herb in a cooking disaster. So the initial iteration of the website included recipes that didn’t contain cannabis, they were just tasty to eat when you were blazed.

So we created thestonerscookbook.com. We added a few initial recipes of our own, opened the site up to the public to submit recipes, and left it there. We had real work to do.

Around 3 years later, while reviewing some of the domains we still held, I noticed the site was alive and well and thriving and had become, somehow, the number one online resource for cannabis recipes. We were gobsmacked. The site had been hastily built (my business partner came up with a design, and I put the site together in MySQL and PHP) and had little to no SEO optimization, or work done to ensure good online visibility.

It grew from there, with a rebuild coming a few years later, the launch of the online store and the original hardcover Stoner’s Cookbook. We still receive pictures from fans around the world who’ve found this book in a corner store in some far-flung country.

A lot of people (especially US visitors) wanted edibles recipes – recipes that contained marijuana in the form of cannabutter, cannaoil, cannaflour etc (extractions). This was new to us, but we added the ability to include these in recipes and created an “extractions” meal type.

So, in the last couple of years we began to take the site seriously. Legalization was happening (sadly not here, yet), edibles were a big thing, and people were posting some amazing, canna-enabled recipes. We launched Herb: Mastering the Art of Cooking with Cannabis – a beautifully shot cookbook of cannabis recipes. I put this together with two amazing cannabis chefs, Laurie Wolf and Melissa Parks, and Laurie’s husband Bruce Wolf shot the photos and cover. Ironically, since we don’t really understand “strains” down under (the weed we see is essentially green stuff in a bag) I had a lot to learn as I wrote many of the non-recipe chapters of the book.

The First Rebuild

So it became time to look at a site rebuild. We didn’t just want to be another weed site. We wanted to elevate the discussion around cannabis. Stoner sites are a dime a dozen, but we wanted to build a community, and take a fresh look at cannabis – it’s benefits (medical and otherwise), it’s use in recreation, and the cost to the community of crime and punishment around it’s legality. We wanted to base the site around content and make it look and work better than the existing creaky old web dinosaur.

The existing site was our first foray into responsive web design – where the site layout adapts to the device it’s being viewed on. We had contracted out the HTML/CSS build, and then I had plugged the PHP/MySQL into it. I was new to responsive HTML. The developer had a huge number of CSS media queries for various display resolutions, so as the viewer’s screen size became smaller, the site layout would change to adapt. It was a nightmare to update and maintain.

We knew the value of having a blog, the power of WordPress and it’s plugins to help our SEO rankings and get our content out to people. But this wasn’t a WordPress site. And I, as the sole developer, wasn’t thoroughly familiar with WordPress beyond installing it and adding plugins.


So we installed WordPress on the server, and I built a listing page for posts (which had no paging… it just grew and grew…) and an individual article page, where I used the WordPress API to pull and display article content. It was hacky. The blog was at /blog/ but the articles were at /article/ so I had to hack WordPress to redirect any /blog/ links (especially those coming from the RSS feed). The /blog/ component still appeared separately displaying a slightly tweaked default WordPress theme. I was using CSS and PHP to mangle the post layout and styles to fit our site design. Please, shoot me…

When it came time for the rebuild we decided to go 100% WordPress. And for that we needed a custom theme developed. In general, I hate to contract out work like this (e-lance, UpWork etc). You don’t know what you’re going to get. You may end up with a developer whose quirky style is very hard to modify down the track. You don’t learn anything yourself. You have to keep going back to the developer for fixes. You frequently have language, accent and time zone issues. And no contractor cares about your property the way you do.

I decided to tackle this myself. I had been working with PHP/MySQL since 1998. I write all of my code by hand (BBEdit on the Mac for PHP/HTML, Espresso for CSS) – I’ve never found an IDE or toolkit that doesn’t inject a ton of useless and complicated code into an HTML page. I usually write code that is simple and functional and valid (or at least I try). I thought that by learning the WordPress API and system by building the theme I would have a much better grasp on the site, be able to fix and expand it in future and have the knowledge involved remain in-house.

Plus, I love to learn.

The New Site: Building the Theme

Warning: Things get a little technical at this point!

So my approach was twofold:

  1. Build the new site in HTML5/CSS3 as an HTML template
  2. Learn the WordPress theme system

I worked with the same business partner to come up with the design, which this time had only two responsive configurations – mobile and desktop.

Most mobile sites are built 320px wide (one of the standard ad banner widths in 300px), but I didn’t like that – new mobile phones have much higher screen resolutions and I didn’t want post images to be scaled up from 320px, so I made life hard on myself by building the mobile configuration at 640px. This means, for example, I have to use a CSS 2 * zoom on divs containing ads…

It was also tough because we wanted a few bells and whistles. For example, the header needed to stay put as users scrolled down the page. The submenu, once the user had scrolled down far enough, had to “stick” to the bottom of the header as the user continued to scroll. The bottom half of the sidebar (which contained an ad) also had to “stick”. We wanted “lazy loading” – when you scroll to the bottom of a page of posts, another block of posts is loaded and you can continue scrolling.  Every one of these customisations came with accompanying challenges.

So I built the template as a single HTML/CSS page, and then began to break it down into separate PHP pages to match the WordPress elements I was going to need – an archive page (for listing posts), individual post pages, the sidebar, a custom post type (for recipes) and so on.

I made sure our post pages were SEO-friendly and used Google Microdata to “tag” the content in the page (for example, the fields on the recipe page) so they’d rank and show up better in Google.

With WordPress, you essentially build a folder in the themes directory that contains all of the files your theme needs. This is quite neat, because you can move themes between WordPress servers etc and they are (generally) all contained in the one folder. You basically need a stylesheet and index.php file for the most basic WordPress theme.

You customise how WordPress works with your theme by having a functions.php file inside your theme folder. This can tell WordPress about custom post types, your thumbnail dimensions, and a myriad of other tweaks and configuration changes to allow WordPress to work with your theme. You can add menu items to WordPress, “hook” into things that WordPress does, call on the functions that WordPress uses, and so on. This was very useful when it came to building all of the custom areas of the recipe post type (cooking time, ingredients etc) and dealing with the submenus.

I spent a lot of time on the official WordPress site reading the documentation and in the forums. I posted a lot of issues to the forums, but due to their very specific nature were usually not solved by other members on that forum. So I had to solve them myself. For example, when the sidebar div that contained an ad was “stuck” to the top of the screen, and the lazy loading javascript triggered when the user scrolled to the bottom  of the screen, the ad DIV would go blank. So I made the ad div an iframe, and that sort-of fixed the problem. The iframe just reloaded every time the lazy loading was triggered, showing a new ad. Great! we thought. No, said our advertising partner. So we had to fix that.

In my initial CSS design, where I used jQuery plugins to stick the submenu to the bottom of the header as the user scrolled down, what was happening is that the user would be scrolling the entire page initially, until the “stick” occurred, and then it was the center column of content that was being scrolled thereafter. This worked fine in most browsers. For some reason, in Firefox, there was a 3-ish second pause when the scrolling switched from scrolling the page to scrolling the content div, and no amount of Googling provided any helpful information. So I had to rebuild the entire CSS structure of all of the major elements from scratch to get around the problem. In doing so, I made the code and styles more efficient.

Once the site was built as a theme in our local dev environment, then came the fun part: plugging in the dynamic elements. Configuring functions.php. Embedding all of the WordPress function calls into the pages. Installing plugins.


I want to talk about plugins. You build a theme, and you need a plugin for some aspect of your site. For example, I use WordPress Popular Posts to populate the sidebar with the most popular posts. With plugins, you’re at the mercy of the plugin developer if something goes wrong. Sometimes the developer disappears off the face of the Earth. Or they won’t implement a feature you need. Or they release a version with bugs. For example, I wanted a Trending page that utilised WPP,  but it doesn’t work that way. So I had to query the database of popular posts directly to populate that page.

We used another plugin for User Management – a nicer interface for users to sign up and register to post comments. It was nice because you could have the login/registration form pop up when the user clicked “You must be logged in to comment” so the user wasn’t redirected anywhere else. On the night of our site launch, a new version of the plugin was released, with a terrible bug that caused the plugin to create multiple user pages in the admin, and maxed out the CPU usage. So while we were dealing the load on the server on launch night, thinking it was just WordPress and we had underestimated our server requirements, it turned out to be this faulty plugin. Once we disabled it, the issue went away. I tried another plugin which doesn’t have the popup feature (to my designer’s dismay) but this conflicted with yet another plugin, preventing our article contributors from being able to login and post.

Needless to say, the site launch was an all-nighter…

Note that you shouldn’t ever edit a plugin directly, or modify any of WordPress’s core code either. Every time there’s a WordPress or plugin update, you’ll lose those changes. So you need to make sure your theme and your functions.php file can work around any plugin issues.

The Launch

I’ve mentioned that the launch was an all-nighter, and we had to make a few on-the-fly decisions. We implemented Cloudflare as a CDN pretty quickly once we realised the load that the server was under. We’d assumed that because the old site was outdated, inefficient PHP code, that our new, leaner theme would run more smoothly… but with the additional overhead of WordPress controlling everything, even the caching plugins we were trying didn’t help. We also had a huge number of 301 redirects, as our old static site had a lot of pages that needed to be pointed to what were now WordPress pages.

Our host (Liquid Web – can’t recommend these guys enough for immediate support and fast ticket response) worked with us to configure apache, PHP and MySQL settings through the night to tune the server response.

Going forward

There’s a lot still to do. The submenus need work. We still have some broken links (the Broken Link Checker plugin is helping us track these down). We’re still using the default WordPress login and registration system while we find a decent User Management plugin (or wait for the one we wanted to use initially to be fixed). CSS needs tweaking here and there. Our designer wants to make some changes. But we’ve seen a huge increase in our SEO rankings, ad clicks, and we’re a lot happier with the way the site looks and feels. We’re now in the post-launch phase: fixing, tweaking, testing… before we move on to all the things we want to do as part of phase two.

In Conclusion

Building a WordPress theme is hard work. You draw on a lot of skills and experience, not the least of which is knowing how to find answers to issues online. Most of a web developer’s work, once they know what they are doing, is problem-solving. You need to do more than just build the HTML. You need to know your jQuery, how the WordPress engine works, “The Loop,” how to navigate the API docs, how to debug, how validate your code, how to tag your content. I’m still learning.

Now, any developers reading this may immediately criticize my approach, my code, my lifestyle… coders tend to have huge egos and be critical of each other’s work, and I fully understand that. I’m sure you’ll find issues or areas in the site that need work or aren’t industry-standard. I welcome feedback. I’m sure many site developers get emails like “I checked out your new site, it sucks, why are you using javascript to detect your display dimensions as well as using CSS media queries” and to be honest, the best way I’ve found to deal with them is to reply back and say “hey, thanks for the feedback, this is why we made that decision, what would you have done?” and then you get into a discussion that can end up quite beneficial to both of you, with new approaches you can choose to learn from, adapt or discard. Gotta take something positive from every experience, you’re not on the planet for very long!

Feel free to comment, not only about the new site “I hate it, why didn’t you use angular.js, where did that brownie recipe go, etc” or if you have any questions about WordPress theme development. I’m no expert, but I might be able to point you in the right direction!