Though it may not be very obvious, back in July I launched a full rewrite of this site. Here's what I did to modernize a homemade blog framework that desperately needed it, while preserving the existing look, feel, and functionality.
The previous incarnation of the site was launched in 2014. It was built on the Kohana 3 framework for PHP 5.6 with a front-end built on Bootstrap 3 and a smattering of additional jQuery to handle things like typeahead searching for my Music Database project, sortable tables, and a few other minor enhancements. The site was backed by a MySQL 5.6 database. I selected this particular combination of technologies in an effort to familiarize myself with a stack I'd soon be using in my professional work at the time.
It's crazy to think that this stack was "state of the art" in 2014, but this was a simpler time in so many ways. An aborted alpha version of the site built on the then-current version of Ruby on Rails is still lying around here somewhere. It wasn't meant to be.
Though I did do some work over the years to maintain and improve the site — making the Kohana framework compatible with PHP 7.3 when PHP 5.6 left support, integrating gulp.js to streamline the CSS asset build and include CSS purging, creating a git based deploy process — the blog framework itself didn't really change at all. That was fine, since I wasn't very good about creating content anyway.
There were also problems that were more organizational than technical. While I was mostly using built-in Bootstrap components when possible, any custom designs that didn't fit well into a built-in component were developed as custom SASS classes rather than by creating custom Bootstrap components. This led to a proliferation of one-off classes in the Bootstrap "additions" file. I also developed a lazy habit of using inline styles for one-off tweaks to components rather than creating SASS variants. The eventual result was not great to work with.
Kohana was a fast and effective framework, but its templating system was limited in comparison to modern approaches. Its conception of a base layout supported slots in a roundabout way, but there was no support for components in the modern sense. I was primarily building with re-usable partials, but they didn't easily support slots, so nesting partials within partials or making partials customizable per context led to a lot of conditional logic within the template files and passing and re-passing variables down through partials — certainly not ideal. These limitations meant the path of least resistance was building template files that were larger and less re-usable than what modern frameworks encourage.
A rewrite sounds like a large project, but I was hoping that wouldn't be the case. I set the following scope for myself to limit the amount of work required while still making the effort worthwhile:
The new site is built on Laravel 12 for PHP 8.4. The front-end is built with Tailwind 4 (no component frameworks necessary). There's very little JavaScript: a bit of vanilla JS for dynamic search filtering, and Chart.js used within the Music Database. The site is backed by a MySQL 8.4 database. Additionally, I finally moved from Apache to Nginx, migrated hosting providers (to DigitalOcean), and made the switch to GitHub (away from a self-hosted git remote).
Overall, the stack is pretty familiar to me. I've been using Laravel professionally for a number of years, and this is a very minimalistic use case. Same goes for MySQL — I really saw no reason in moving to another product for this tiny use-case. Nginx is a breeze to work with (and configuring LetsEncrypt on top was just as easy).
The biggest adjustment was moving fully to a Tailwind (and Flexbox) mindset. It was interesting porting the melange of Bootstrap columns/custom SASS/inline styling to a Tailwind/Flexbox solution. Obviously, the end result is much more straightforward to understand, but also a bit more verbose. There's now very little custom CSS — just a smattering of @apply usage to make blog article styling a bit simpler. I ended up reproducing a handful of Bootstrap utility classes so that existing blog articles didn't look too broken after the transition. Because Tailwind has moved away from a CSS purging workflow and towards only generating CSS declarations based on usage within your project, I keep needing to remind myself that I don't have just any Tailwind class at my fingertips when writing these articles. That's something I'll have to figure out how to tackle more elegantly. Can Tailwind be configured to look at your database to find class usages? Sounds like a bad idea.
I decided not to port some JavaScript functionality as part of the migration; I just didn't deem it critical to considering the project complete. The typeahead search and client-side sortable tables functionality did not make it to the new version of the site. Unfortunately, both depended on jQuery, and any other solution would be more than just a drop-in. I'm hoping to treat these each as projects in themselves and to write vanilla JS widgets for both.
I'd also like to consider other, new features for the site, just to keep things fresh. I've started a @TODO list for myself. Any ideas are welcome, just let me know. The first item on that list is to WRITE MORE ACTUAL STUFF for the site. So that's what I'm doing now :)