So, sure: WordPress is a CMS. I think it’s sometimes the answer given as a defense against the cynical question: “What’s WordPress still good for these days?”
It’s a pretty great CMS, honestly. But what if we don’t focus on the CMS aspect so much. I think there are more imaginative ways to think about the opportunities WordPress provides.
Because beneath the templating and posts and menus, WordPress is something far more powerful: it’s a runtime (and by runtime I mean the sense of the word that conveys framework or platform). I tweeted this thought yesterday but, alas, I had more thoughts on the subject, so today we’re blogging.
WordPress has a built-in database, user authentication, routing, a REST API, and the ability to conditionally load resources or change output based on server state or user state. There’s all the makin’s of application logic in there.
Please Embrace the Today’s WordPress, Please
The problem is, most WordPress sites still treat it like it’s 2011. We build themes, add a few forms, maybe install a member plugin—and that’s it. (Not that there’s anything wrong with member plugins–the PeakZebra site uses one.)
A WordPress site gives you a pretty solid authentication setup, one that’s been battled tested on a ridiculously large set of sites in the wild. The fact that WordPress sites get compromised sometimes (though, to be honest, this generally isn’t about the way authentication works in WP, but is either password guessing or other problems (insecure plugins) that have nothing to do with authentication.
Want to add two-factor authentication? People have already packaged that up in plugins.
Or consider API’s. Yes, it’s cool that the CMS side of WordPress offers full access via REST, but I’d say it’s even cooler that it gives you a framework where it’s very quick and easy to add as many other application-specific REST endpoints as you’d like. You can make them public, but you can also make them private and, hey presto, WordPress takes care of the security so you don’t have to.
If you start thinking of WordPress as the foundation for an actual application, a whole world opens up: dynamic interfaces, persistent user flows, personalized content, and client-specific tools—without abandoning the platform you already know.
WordPress isn’t “just a CMS.” It’s a bigger deal than that.
Since the stuff I’m building these days has similarities to some of the things Airtable does, I figured why not build a version of the request queue I’ve built with PeakZebra, only with Airtable.
TLDR: Throw in all the AI you want, once you’re past just storing everything in a single sheet, it’s pretty easy to make a false step (or use the AI to try and do too much) and you wind up with something that just doesn’t work. And it’s possible that it won’t be obvious to you that it’s not working like you think.
Airtable is pretty cool and there’s no question that it’s got way more polish than PeakZebra does just now, but then again, there are ways in which it’s considerably trickier to build things with Airtable if you’re coming in cold.
Magic AI bullshit
These days, it almost goes without saying, Airtable has some magic AI bullshit built in. The promise is that you describe the app you want and it builds it.
Honest to god, I didn’t try to trick it into screwing things up. I tried to come up with a concise description of what I wanted my request queue to do. I’m afraid I didn’t preserve the actual prompt I gave it, but I can tell you that it created tables that appeared to do the right things, but the relationships between them weren’t at all correct.
So the AI stuff was a bit of a crock, but that’s not really what I was interested in getting at in any case. And if you just wade in and do it yourself, there are all sorts of things Airtable does that are very powerful.
Easy and powerful things
It’s very easy, for example, to connect a field in one table to records in another table. For instance, if you have a table where you store all the requests that are coming into your request system, it’s easy to tell it that the client field should come from the clients stored in a client table.
And there are some nice touches. When you click on the client you’ve chosen in one of the request records, it pops up a view of all the data in that client’s client record. Handy.
So the app let’s you establish clients and let’s you create a form for adding requests that are associated with your client identity.
Twist once for death
I wanted an extra twist, though. I wanted to be able to let a client create a bunch of associated requests–all the tasks needed to carry out a given project–but not necessarily put all of those tasks into the request queue.
So I wanted a project table to store the name of various projects, plus a tasks table to hold all the tasks associated with all the projects of all the clients.
This is easy enough. It’s also straightforward to add a field that toggles to tell you whether a given task is currently in the request queue.
Doing this, though, means that you don’t want to store requests in a request table, but that instead you want the request queue to be a view of the tasks table that filters on tasks that are flagged as being in the queue. You can also add a further filter or grouping to show the queued items by project and/or by client.
Wait, one more twist
Ah, but another twist. Some things are projects with a bunch of different steps, each one handled as a separate task. But other things are one-off things that need to be done and that really aren’t part of a task. Say you’ve got a website and you want to request a change in some content on that website. That’s not a project.
You could create a project for “non-project” tasks, but what’s conceptually cleaner is to have things in the queue either be tasks from projects or be standalone tasks. There’s no obvious way to have a field be populated by data from either of two tables.
Now, let’s be clear. I don’t have any doubt whatsoever that there’s a way to do this. There’s almost certainly several different ways to approach it. But if you’re trying to avoid learning lots of technical minutia about the Airtable environment, you’ll hit a wall with something like this.
Sometimes a little code is the magic
The PeakZebra approach doesn’t preclude figuring out how to do the trickier stuff yourself, but as part of the basic arrangement you also have the option of just, well, using the PeakZebra request queue (on PeakZebra, not Airtable) and just asking us to do it for you.
But my real point here, I think, is that services like Airtable and Notion and others are focused on making everything work for everybody without requiring any code. And this can sometimes completely obscure the ease with which the same thing could be accomplished in a “low-code” approach with just a couple of lines of code.
And oh by the way: I’m not as against AI for coding (and similar code-like tasks) as it might sound like in this post. I’ve been doing more and more AI assisted programming of late, and there are definitely things about it that make me loads more productive.
