OMQ is holding me back with PHP!
The Old Master Q Comics website has been a long time side project of mine. I started working on it back in 1999(?), before I graduated college. I have a love/hate relationship with it.
The "hate" part has only been creeping in the last decade or so. It's a relationship that I have a hard time getting out of because it's practically family! I have these unnecessary obligations I've set for myself around it.
Recently it's gotten me to go back to coding some PHP. The entire OMQ website is built on PHP that I wrote 10+ years go, back when I had what developers today would call bad coding habits and hygiene. But whatever, it's always been a side project that no one will ever see behind the scenes!
But now on my current path to becoming a better and more knowledgable modern web developer, and leading by example, returning to this PHP environment feels like an embarrassing step back.
But the work had to be done!
So at the beginning of vacation, I had the brilliant idea to consolidate the two different mySQL databases powering OMQ. I had my original comics website-DB that powers everything on the OMQ website, on top of which I built an Admin system to manage the strips you see on the site. I've been using this DB system for OMQ since I learned how to write PHP back in 2005 or so.
Several years ago, after I learned React, I built a separate DB and Admin to catalog the 11,000+ raw OMQ scanned comic strip jpg files I received from my father back in 2003 or so. This was intended to be the definitive OMQ resource where I could look up any topic and find relevant OMQ strips about it, by searching tag cloud system. This new React Cataloging Admin only worked locally because I hadn't learned the ways to be able to serve it from an Apache server.
My comics web publishing work flow has evolved through years. The current process for the last 8 years has been to take a random strip from the 11K source, then "process" it with my old admin to publish it to the site. I would use the base file name of the source strip to be the final file name of the web strip. This was the only connection for the live strip to the new admin, but nothing else.
So my great idea was to forgo my old Website DB and create a mapping table of the "live" strip to the raw strip in the Catalog DB. Then I would create APIs in PHP on top of this new DB to power the comics website and the React Admin, which I would move onto NextJS.
This process was a mess.
- I worked across 3 different Git repos. 1) the comics frontend website 2) the Website Admin repo and 3) the new Catalog API repo.
- My web host only supports FTP into it (no SSHing) and PHP (no Node). So I would basically be coding directly on the server through FTP, then pull down a copy locally, then push it to my Git repo.
I never really had any deployment automation process set up for this in the past. Everything was manual. Yes totally inefficient, hella old school way of working.
This took me all week to write a bunch of scripts and APIs to take care of most of it. Most of my code was a bit cleaner this time around -- better name functions with comments, consistent function name and variable casing. But there were still areas I left alone to "get to one day" for further clean up. So.. still a mess. I also found a few things about PHP that really annoyed me this time around:
$all the time gets annoying. Copy/pasting vars don't include the
$symbol so you have to be careful.
array_manipulation methods seem inconsistent. Sometimes the first arg is the source array, sometimes it's the second argument. I had to look them up every time.
Anyway that's all the big Part 1 of of what I needed to do. I still need to finish the Catalog Admin interface in React that I plan to build with NextJS and host with Vercel. I'll get to that another day.
In the meantime I drew an elephant, since that's the logo for PHP. I had to look up photos of elephants as a reference, and realized that they are quite alien looking!