WordPress at 18: Building things that last
Today WordPress turned 18 years old, the same age I was when I built my first WordPress site. This got me thinking about the longevity of the software we create and use.
In 2009, I was 18 and dipping my toes into freelance web development while I still lived at home. Some of that early work was with Chez Koop, the place where I would eventually have my first full-time, grown-up job as a developer and designer. At the time, we built websites with plain old HTML, CSS, and perhaps some custom PHP. We started with Photoshop mock-ups, before coding the whole thing pretty much from scratch. Table based layouts were on the way out, but the “responsive design” revolution wasn’t quite upon us.
My journey with WordPress started with PHP. I’d been using the language for a few years for basic server-side stuff—like creating a rudimentary templating system so we’d only need to update the header and footer in one file. “Ugly” URLs like index.php?page=about were still common and things like caching, third party APIs and SSL weren’t yet on my radar.
Like many young developers unaware of their own limitations, I tried building my own CMS. I was creating a website for the small business of a family friend, and they wanted to be able to update the content of the pages. I knew off-the-shelf CMS’s existed, but I wasn’t familiar with how any of them worked, so doing my own thing just seemed to make sense.
At this point I’d tried doing stuff with MySQL (I recall a janky todo app), but I knew I didn’t have the chops to use it for a live site. So I created a flat-file system with PHP and the TinyMCE content editor that allowed the client to login and change the main block of content on each page.
There was no image uploading, no preview or draft functionality, and in hindsight, no security. If I recall correctly, “users” were hard coded into an array, including their passwords stored as plaintext 😳. Never mind changing a password, even adding a new page couldn’t be done through the “user interface”.
I don’t have a copy of the source code from that site, but that’s probably for the best. It was certainly a mess, but the experience taught me a lot. Mostly, that building a good CMS is really fucking difficult.
Towards the end of 2009, I got my first major solo project—the website for the local shelter for women in crisis, Agape House. For this site, plain old flat files weren’t gonna cut it—they needed to be able to edit it, post news and update pages. They also needed to be able to reset their passwords whenever they felt like it 😅.
Having done a little work with TinyMCE, I’d heard about WordPress (which used TinyMCE as its content editor at the time). WordPress was PHP-based, didn’t require me to learn a new templating language, and it seemed to be getting popular. I wanted something low maintenance that would be around for a while.
That first custom theme was a huge learning experience, but ultimately it set the course for all the WordPress-based work I’ve done since. With a few tweaks, updates, and bug-fixes over the years, that site lasted a decade. We finally replaced it with a new theme in 2019, designed to take advantage of the block editor.
The lesson in all this, I think, is to build software that lasts, that’ll keep doing its job week after week, year after year. In todays tech world, with so much software obsolete almost as soon as it’s released, it's important to remember the things that just keep doing their job.
There’s no getting away from updates entirely-but we can still build things that are meant to endure. If you move too quickly, you’ll break too many things.