You may have heard about experimental custom post types feature coming to WordPress core, one of the many exciting results of Automattic’s Radical Speed Month.
A few weeks back, I published my prototype of what I’d like to see around content modeling, and it’s been great to see the Gutenberg team moving forward on a similar idea. People have asked, and to be clear: there’s no correlation between my prototype and the ongoing work, other than me being a big fan of better developers than me working on this.
This experiment has triggered a lot of takes, many in support of the feature, but many asking why custom post types should be coming to WordPress core at all? Let’s not forget: custom post types have been a core feature of WordPress for over a decade. Developers and plugins have been able to create them since register_post_type() was introduced in WordPress 2.9, over fifteen years ago.
What’s happening now is work in the Gutenberg repo to add a user interface and data layer for custom post types. That distinction matters more than most people realize.
This Isn’t About Developers
Since custom post types already exist and are fully extensible through code, adding a UI means the target audience clearly isn’t developers. Yes, many WordPress builders use tools like ACF or CPT UI for convenience—but most agency developers will tell you they hide that functionality from their end users. Metabox covered this in their great response post, but I disagree with their conclusion that “the current implementation is too basic.”
Yes, custom post types carry significant weight in how you build and structure a site. That means that exposing them in the WordPress admin by default means we need to get a simplified, user-friendly version. We can’t just port existing plugins into core, because those plugins serve a different audience: agencies who want granular control and the ability to lock things down.
If that’s what you need, those plugins still exist. This is about something different.
Unfortunately, a lot of the conversation I’ve seen online is people bringing other complaints (many of them valid) about WordPress into this conversation. I think that’s the wrong way to approach this.
Abilities and APIs Over UI
Right now, to create custom post types, you write PHP code and deploy it. That works, but I’ve been reevaluating my conceptions about the future of WordPress. With AI agents and tools like WP-CLI and MCP servers, we need secure, programmatic ways to interact with WordPress that don’t require writing code.
You’ve probably seen the recent security concerns being raised about the fact that plugins can modify your database and write executable code, something that projects like EmDash and others are pointing out. If users want to create content types and they resort to file manager and code snippets plugins, things can go wrong fast. I’d rather have a safe, UI-based approach—but more importantly, the APIs, Abilities, and CLI commands that make that UI possible.
When I built my prototype for content modeling, I included a chat agent in the demo specifically to show: this is what happens when you can do things through APIs. An agent using WP-CLI or MCP can create content types without touching your filesystem.
Custom Fields and Config Files
More than that, custom post types do really need custom fields as well. That’s why I’ve been using the terms like “content types” and “content modeling” intentionally. Custom post types are a developer-centric feature, but content modeling is something that many CMS users, especially at the enterprise level, are used to with platforms like Sanity and Contentful.
Joost de Volk wrote a follow-up post agreeing that custom fields need to be part of this—content modeling means post types and fields working together as a cohesive experience. But I want to challenge a few of the other points in his post.
First, I don’t quite agree with the call for config files. I’ve had a mental shift recently about moving away from files for everything. The “just write PHP and version control it” approach already exists and agents are really good at writing decade-old WordPress functionality. After the last few years of building with theme.json and a decade of ACF’s JSON sync files, I’m going to say that I’m ok not having any more json config files in my life.
WordPress should lean in the other direction – empowering non-developers to safely make changes to their websites. It’s the thinking that led me to want Future Revisions as a core feature.
I know the argument is that we need to move configurations out of the database, but I disagree. I want WordPress to move more things away from needing separate version control and local development environments. Yes, those things are important for complex, developer-supported sites, but content modeling should not be for developers only, but also power users. Those users need to be able to build on their production environment. We need a cleaner line between users and developers in WordPress, and stop expecting WordPress power users to write code.
There’s also been concern about the data structure of the post type registration: It’s meta in a way—using a custom post type to manage your post types—but that’s exactly why it works. Building this on top of WordPress’s existing architecture gives you so much for free:
- Revisions, version tracking, and scheduling capabilities
- Routing and admin screens
- Core’s existing hooks and filters
- REST API endpoints
- Core data layer
And so much more. There’s a built-in layer of extensibility that would have to be rebuild from scratch.
On the flip side, I will agree with the argument that all of the new React-based UIs in Gutenberg need more UI extensibility, but that’s also a separate issue unrelated to this specific feature and applies to basically every aspect of the new WordPress admin components.
On Separate Database Tables
Another suggestion that comes up: registered custom post types should store content in separate database tables instead of wp_posts.
Whether that’s right or wrong, it’s also a completely separate problem from adding new UI. It would need to be solved for all post types, be backwards compatible, and still provide all the core functions, commands, REST API endpoints, and features that posts give you.
We’ve seen WooCommerce tackle this with High Performance Order Storage. It’s possible, but it’s hard—lots of data, migration questions, compatibility layers. That’s a major architectural project regardless of whether a content modeling UI exists. I understand the argument, but I’m also less convinced that it’ll impact users as directly as a new UI.
This project is about getting content modeling into the UI and enabling programmatic management without writing code. Database architecture is orthogonal to that goal.
Some Hypocrisy from Me
Earlier I complained that everyone brings their own unrelated WordPress issues into this conversation, but I can’t help doing the same. So I’ll be upfront that I, too, want some deeper architectural changes, and I’m a total hypocrite for including this.
When you create a custom post type, you have limited options:
- Public: Every entry gets its own URL, plus optional archive pages
- Private: The content isn’t queryable at all in blocks like Query Loop
But what if you want something in between? A collection of FAQs that you display in filtered lists on various pages, but where individual FAQs don’t need their own URLs? Or testimonials that appear throughout your site but shouldn’t be indexable as standalone pages?
This is a very common use case, and it’s surprisingly difficult to achieve cleanly right now. So there is one architectural change I think is essential: the ability to have public post types without single URLs.
I found a Trac ticket from 10 years ago (from Jason Adams of GiveWP, now AI Director of Engineering at Automattic) asking for exactly this. When you register a post type, you can already choose whether to have archives. Why can’t you choose whether to have single pages?
The workaround today is painful. You have to:
- Hide it from sitemaps
- Use
template_redirectto trigger a 404 - Remove “View” links from the dashboard
It’s all backwards engineering and doesn’t even cover everything.
I did some testing, and the fix is harder than it looks. The entire premise of a public custom post type is that it has a permalink. Remove that, and WordPress (and blocks, and SEO plugins) assume it still exists. You’d need changes to:
- Dashboard UI (remove view links)
- Query Loop, Post Title, Excerpt, Date, and other blocks (to hide build-in permalink options)
- SEO plugins that assume
publicmeans the CPT has single pages
But this change is essential. Think about the use cases: FAQs, testimonials, download links, any table-style data. You want to query and display this content in lists and archives, but individual records don’t need URLs.
I submitted a patch, but there’s probably more community discussion needed for this to work.
The other architectural change I’d like to see is around post types that don’t use post_content at all, or want to function as something other than a blog posts or landing page (including the examples I listed above). In that scenario, you lose access to the Gutenberg block editor UI. Editing your content feels like WordPress in 2015.
In my prototype I implemented a (very hacky) workaround to load the block editor UI, hide the block editor itself, and use the canvas to display your custom fields groups. I’d like to find ways to enable more extensibility around how the canvas is used in the block editor, with the assumption that not every post type needs visual editing.
What’s Coming
I’ve been following the progress in Gutenberg and providing feedback. If you want to see a true future-oriented version of content modeling in WordPress, you should look at Cortex, a project that takes custom post types and fields and gives them a Notion-style interface—inline editing, rich data tables, almost like direct database access. This is the future of what could be possible on top of WordPress.
This matters because once you have proper content modeling in core, these interfaces can build on top of it. The same way WooCommerce benefits from Gutenberg’s UI components for products and orders, content modeling tools will benefit from shared foundations.
Build this on custom post types (as unique as the architecture is) and it all has a better chance of working together.
How you can help
This stuff makes it into core based on public perception and engagement. Plus, more WordPress features need good feedback from real users. If you want to see content modeling in WordPress:
- Comment on the Gutenberg issues
- Test the prototypes
- Give specific feedback about your use cases
- Say how you would use it
Otherwise, the assumption is nobody really cares.
And when you do engage, I recommend skipping the whole “I wanted this 10 years ago” comments. We all wanted things 10 years ago. The question is whether you want to be constructive now and help push WordPress forward.
Leave a Reply