Made withPayload CMSClip

World without WordPress: Payload as an alternative to ACF

P

Payload

Creator on the Payload CMS channel

Watch on YouTube ↗

12K viewsOct 21, 202411:06 runtime

Explore a modern alternative to WordPress and Advanced Custom Fields (ACF) with Payload CMS. This video addresses recent controversies in the WordPress ecosystem and argues for a code-first, open-source approach to content management. See a direct comparison between building…

Chapters

#payloadcms#clip#cmscrm

The Case Against Modern WordPress

Recent events, like the replacement of the Advanced Custom Fields (ACF) plugin, and ongoing issues, such as ads appearing in the WordPress dashboard, signal a potential need for developers to evaluate alternatives. While WordPress isn't disappearing, it's a good time to consider other options, especially for custom development.

Why Open-Source is Non-Negotiable

One of WordPress's greatest strengths has always been its open-source nature, which provides a crucial safeguard against vendor lock-in.

Clients are often wary of SaaS CMS platforms due to concerns about:
- Sudden price increases
- Inability to migrate their data easily
- Hitting feature limitations with no ability to extend the platform
A true open-source solution like Payload gives you full ownership of your code and data, just like WordPress promised.

Two Types of WordPress Developers

No-Code Builders: This group uses off-the-shelf themes and visual page builders like Elementor and WP Bakery. Payload is not the best fit for these users.
Code-First Builders: This group builds sites from scratch. Their workflow typically involves:
- Writing custom themes
- Installing the Classic Editor
- Using ACF to define a content schema
- Crafting a bespoke editing experience in code
Note
Payload is designed as a direct, modern successor for this second group of developers.

Comparing ACF and Payload

Content Modeling & Data Structure

WordPress/ACF: Uses "Post Types" for all content. This is semantically incorrect (e.g., a "Director" is not a "Post") and forces all data into a single, massive wp_posts table.
Payload: Uses "Collections," which are logical data models that translate directly into their own dedicated database tables (e.g., a movies table and a directors table).

Database Schema

Important
The most significant difference is in the database architecture. WordPress flattens all custom field data into the wp_postmeta table, whereas Payload generates a clean, predictable, and efficient schema.

WordPress/ACF: A chaotic mix of data types stored in a key-value metalayer on top of the wp_posts table.
Payload: Generates a clean schema with proper columns for each field (year column), foreign key relationships (directorID), and modern data types (jsonb for rich text).

Developer Experience (DX)

WordPress/ACF: A UI-driven workflow that requires you to manually export/import JSON files and generate PHP to get your schema changes into version control. This is described as "madness."
Payload: A code-first approach where your entire schema is defined in TypeScript or JavaScript. This makes it easily version-controllable, testable, and scalable.

Key Payload Features

Live Preview: Comes out-of-the-box with the Next.js website template.
JSON-based Rich Text Editor: Provides structured content instead of raw HTML strings.
Bidirectional Relationships: Define a relationship on one collection, and it automatically appears on the related collection—a feature that ACF lacks.

Conclusion: An Upgrade Path for ACF Users

Payload is presented as a natural evolution for developers who use ACF but are frustrated by the architectural limitations of WordPress. It takes the spirit of ACF but builds it on a modern foundation where custom fields are a native, core concept, not an afterthought.

The core philosophy: What if "Advanced Custom Fields" were just... fields?

The WordPress Crossroads

I can't believe it, they actually did it. Yeah, I've been using Advanced Custom Fields for over a decade and coming back and seeing it just replaced with Secure Custom Fields over this petty drama. This is... where are we? What's happening? Are we in The Twilight Zone?

I mean, I guess backing up, the writing has been on the wall with WordPress for quite some time. I think like, just go to the dashboard. They're advertising WordPress events to you. Where does this come from? Get out of my software. This doesn't come with the repo. Clearly, there's something else going on that maybe shouldn't be in the open source world here. But so, like, here we are, kind of at a crossroads. Do I think WordPress is going to go anywhere? No, but it's kind of maybe an opportunity for us to take a step back and look at what we're in and think about what the world would look like if we didn't all rely on WordPress for things that maybe it never should have done in the first place, by the way. But let's just dive into that a little bit. Let's talk about it.

Why Open-Source Matters

Now, to the surprise of absolutely no one, I am not the biggest fan of Wordpress. I have a lot of respect for them, but I literally built a company so that I didn't have to ever use it myself ever again. And here we are. It was a lot of work, but luckily Payload has some safeguards in place to make it so that if anyone on the Payload team ever became insane, they literally could not steal your plugins or your hard work. Because we use, just like any common sense open source software, a third-party package repository to install dependencies called npm in our case. And that's owned by Microsoft. And if Microsoft stole your plugin, I think we'd be in a different world of hurt right now. Um, I don't think that's going to matter.

But if we're going to be thinking about where we go after WordPress, I think we should start by looking at its strengths and try to replace the strengths, right? And to me, the biggest strength of WordPress was that it was open source. And every time I pitched it to clients, they were like, "Sweet, let's go." But every time I tried to pitch a third-party software as a service content management system, they were like, "Oh, uh, what happens if we want to change vendors in like six months? What happens if the vendor increases their pricing in three months? What happens if we want to reuse our database? What happens if we hit a roadblock and we don't have a feature that we need and we can't build it because we don't own the code?" So I think thinking about a world without WordPress, it's important to value it for what it was good at, and open source is part of that.

Two Types of WordPress Users

But then outside of that, I think we can break down the people that use WordPress into two different categories. And the first category is people that are building no-code, um, cobbling together themes and plugins off the shelf and throwing a Hail Mary, crossing their fingers, praying that nothing breaks or explodes, or they don't get hacked. And you know that crowd, the Elementor, the WP Bakery... I wonder if WP Bakery is going to get sued. Interesting. Um, that crowd, I don't know that Payload would really be a good fit for that crowd, because they should just go find some open source website builder tool, like a visual one. Like, no-code is not really Payload's thing.

Payload is more focused on the types of people that use WordPress to build things from scratch. I'm talking write your own theme. I'm talking, first step, install the classic editor. Second step, install ACF, build out your schema, and then craft your editing experience in code how you want it to be. Those types of WordPress installations, that's what I used to do. Those ones are a natural fit for Payload. And I'm going to show a little bit about that. I'm going to spin up an ACF project—well, I already did, and it was traumatizing—but I'm going to compare that ACF project over to a Payload project and kind of talk about the differences, some of the important ones, and show you that it's maybe a natural upgrade path for you as we think about this new opportunity.

ACF Problem #1: The `wp_posts` Table

Okay, so here's a pretty typical WordPress instance. Kind of triggered by the advertising to me right here in open source software, but we're going to put that behind us. SCF... oh, triggered again. Can't believe they did that. Okay.

So here's how ACF generally works, right? I added two post types called Directors and Movies. And I'm going to zoom in a little bit. So post types are the first thing that I want to concentrate on. Like, post types are insane. The fact that I have something called Directors which is considered a post type, that just drives me crazy. It's not a post type, it should be a table in a database. But in WordPress, somehow we've been dealing with this since 2003. It goes in the wp_posts table. Why? I couldn't tell you. But here's a director and here it is in the wp_posts table, right next to movies. You'd think that the schema might be different between these two things, but nope. WordPress, ACF, they just jam everything into one table, call it a day, move on. And this is—you have to pay for this. This isn't even true open source because you have to pay for a license. But anyways.

ACF Problem #2: A Clunky Developer Experience

So, we've got two post types, um, Directors and Movies. And I'm using the free version. And then we have field groups. So I have Directors and Movies, and this field group is assigned to the director post type, and the movie is assigned to the movie post type, right? And this is very simple. I've just... Lord of the Rings, best movie ever made. You can tell me that it's not and I will plug my ears. But this is pretty typical. If you're used to ACF, you know that you can install some custom fields down here. So I did a relationship field and a poster field, right? And I like Rivendell. Rivendell. I can't remember. Rivendell. But anyways, ACF right here, you're all probably very familiar with this.

Oh, this is fun. I created the post type and I accidentally left the O capitalized: movie. But then I went back and I tried to fix it. So I fixed it, but it doesn't actually fix. So I don't know where this is, must be in the database somewhere. I don't know where they save that, but it's pretty interesting.

Okay, and then we go to directors, and directors is pretty simple. We've got a couple fields. Peter Jackson directed Lord of the Rings. Now, this is pretty straightforward, and in the Payload world, it's pretty similar. I mean, you don't really have to use code for this, but unfortunately, you do have to learn about this mania over here. Export as JSON. Let's do it. Ooh, download that. I don't know what I'm going to open that in. Oh, X code? Get out. Never mind. Um, okay, you have to download the JSON as a backup, you got to import that JSON if you want to edit your fields and share them with somebody else, and then you got to generate the PHP and put it in your functions.php file. This is madness. We've been doing this for almost two decades. We don't have to do this. We don't have to do this. Look at how it looks in Payload.

Payload's Modern Approach to Content Modeling

So I'm going to go over here. I've spun up this... this is a brand new Payload project out of the box. The only thing I did was I added the movies and the directors here as the two collections. This is our website template. You can go spin up the website template, it's pretty cool. It comes with live preview out of the box so you can see what you're working on. And, uh, if I spin this up and wait for it to compile over here, I can say like, "test, test, test," and I can see my changes in real time because Payload and Next.js are kind of connected. So Payload is actually... it's been coming along. Um, why am I in light mode? Let's go to dark mode. Okay, cool.

But anyway, this is the website template out of the box. We added two collections, movies and directors. So if I go to movies, here's the list view. So if we compare this, we go back over here: list view, list view. And then we go to Lord of the Rings. Here's our rich text editor. You can drag and drop things. It's actually JSON, it's not HTML strings. So that's very—that's a very big deal. But other than that, we've got an image field here. We can edit this poster if we want to. We can edit the director here. We've got a relationship to the director. We've got the year it was made, whatever we want. And so this is kind of like a shot-for-shot replacement, and you can even put things in the sidebar with Payload. So it's very similar to how WordPress works.

But then going back over to directors, let's see that there's some cool things. Uh, one thing to remember is that we have a relationship field right here. Peter Jackson is the director. We go over to directors. This is a new feature in Payload 3.0, but we have bidirectional relationships, which is something that ACF doesn't even have. You define the relationship on movies, and then you go over to directors and you can see all of the movies that this director has filmed, and it works out of the box. I can go edit this right here. And the bidirectional thing is brand new, it's coming out with Payload 3.0, but it's pretty cool. I couldn't do that in ACF, otherwise I would have. But you can see it's kind of the same idea here.

Payload's Superior Database Schema

Now the big, big difference between WordPress's database shape and Payload's is that in Payload, the database is exactly how you said that it should be. I have a year column. I have a directorID which is a foreign key to the director's table. I have a posterID column which is a foreign key to the media table. And I have a description which is a JSONB. This is Postgres. You can use MongoDB, you can use Postgres or SQLite, but everything works out of the box. You can even do indexes.

And if you compare this type of thing over to WordPress's obliteration over here, I don't even know how to describe this. Look at this, there's comments... there's a comment that is functional. That's a functional comment right there. I don't know, man. I don't know, man. I get fired up real easy, so I'm going to cut it there. I think that's been enough.

Conclusion: Why Payload is the Next Step

But if you're coming from that second camp of WordPress users, the ones that actually write code and they know what functions.php is and they don't like Elementor, then you might find a lot of value with Payload. If you're looking for what's next after WordPress in general, I think that sticking with open source is going to be the move. And outside of that, I think Payload is a pretty good substitute, especially for those of you that have been using ACF a lot. I think that inspired a lot of what Payload does, just ACF in general. But we thought, you know, hey, Advanced Custom Fields—what if they were just... fields? You know, I think WordPress maybe should have had that in 2004 after it came out. But here we are, 2024. That's it. Goodbye.