Hosting and deployment
My website is hosted on a private VPS that I rent. The VPS runs Plesk, a hosting dashboard similar to cPanel, which allows me to easily manage SSL certificates, automatic cloning from Git, Cron schedulers, and much more. I’m very fond of Plesk after having adopted it into my workflow a little over a year ago, and can’t see myself moving away from it any time soon.
I use Cloudflare as a CDN for my traffic, as well as Cloudflare’s R2 storage buckets for my media. Using Cloudflare speeds up my website significantly all over the globe, and protects my server from malicious traffic or common attacks such as DDoS attacks. I have several WAF rules set up within Cloudflare that protect my admin login page, as well as the comment and contact form submission pages, verifying any traffic that tries to utilise these routes and preventing any spam from happening.
By using Cloudfare’s R2 storage buckets, I’m able to manage all of the code for my website independently from the media. The benefit of this is that when I work on local, staging, or the live version of the website, all of my media is readily available without the need for it to be committed to GitHub as a part of the code. Additionally, the media benefits from all of Cloudflare’s strengths in speed and caching, while costing me absolutely nothing due to the generous free usage tiers they offer.
Design
I designed the website myself as a part of the development. While these days I try to separate these two layers of the development process, back when I first started this build a few years ago, I decided to “put pen to paper” as it were, and see what felt right. I had a logo drawn up by a friend in a specific font and colour pallet and used this as a basis throughout development.
If you looked at the links at the top of this page to the WayBackMachine’s archive of the site from a few years ago, you’ll see it looked quite different at its initial launch. I think it’s great to make the comparison as, while the initial site is quite different, it’s also quite similar. Seeing where it was makes me proud of where it is. While the differences might feel more intense to my eyes, the differences that exist are huge both on the front and back ends.
Frontend Stack
As it’s a WordPress project, I utilise the Divi theme for my website. It’s a theme that I own an unlimited, lifetime license for, and it’s something I’ve used on over a dozen sites in the past. While I like the drag-and-drop editing that Divi provides, it has a lot of drawbacks which I’ve been tackling over the years. If I were to do an entire rebuild, I’d go for a custom theme. But as it stands, I have a child theme in place that ships many customisations and extensions to the base Divi experience. I have many snippets of shortcode and custom styling to make the out-of-the-box Divi experience more tailored for my needs.
Backend Stack
As I’ve mentioned above, I manage the code for this project using Git, instead of the ‘normal’ WordPress workflow of just working within WordPress itself. The reason for this is that I utilise many custom blocks and a custom, complicated child theme, all of which have their own Git repositories. By utilising PHP’s Composer package manager, I’ve set up my website to pull dependencies from repositories without the need for WordPress’ standard marketplace. This means I can stage all of my changes locally to avoid breakages when updating and I can very specifically control software versions. While this won’t work for some people’s workflow, as I only have around 8 plugins, 3 of which I wrote myself, I find this to be an excellent way to keep my site clean and secure.
This website uses the latest version of PHP and the latest MySQL database server. Redis cache is in place to optimise database querying, and Swift Performance 2 is used to generate static page cache.
The future
My plan is to constantly add content to this website. However, I don’t intend to write or deploy anything that I wouldn’t read myself. As this isn’t a typical blog that’s trying to appease algorithms, I won’t be pushing out articles just to remain active. Instead, as I work on other projects and in my full-time job, I make note of my struggles. If I find myself encountering a problem or looking for a solution and little clear guidance is available to me online, that’s the content I’ll write myself. Everything I publish as a blog post will be there to fill a void that I found. Outside of the blog posts, I’ll continue publishing and showcasing projects here too.
I’m currently working on a very exciting project, which is a suite of blocks that changes the way we use Gutenberg. While I won’t be sharing any details on that just yet, once this project is production ready, I’m going to be rebuilding my website with that new framework. So one day soon, the Divi-centric front-end will be gone.
