WordPress might soon have a native user interface for creating and managing custom post types, following the merge of a new feature into the Gutenberg trunk as part of the Content Types experiment.
Overview and Implementation
Marin Atanasov introduced the recently merged pull request by outlining its scope, stating, “ Introduces the foundations of user-defined custom post type (CPT) management interface as part of the content types experiment.”
This will allow users to manage custom post types directly from the dashboard without the need for code or plugins.
The pull request outlines how the feature is implemented, noting “We register a private wp_user_post_type CPT holds one record per user-defined post type, with the slug, status, and a JSON-encoded config stored in the standard post fields.”
It adds that each custom post type record is processed during initialization and registered using a validated subset of its configuration, “ Each published record is read on init and registered via register_post_type() with a tightly-validated subset of its config.”
It also outlines safeguards to prevent conflicts between post types, stating, “A REST insert filter rejects slug collisions with existing post types or other records.”
The update also introduces a new package, “@wordpress/user-post-types,” along with new routes for managing post types. A list of additional works that are also considered has been provided.
Interested folks can try it now on Playground, by entering the PR number “77754”. Once the environment loads up, head to Gutenberg > Experiments and enable “Content types”.
After this, the Post Types are accessible from the settings tab.
Héctor Prieto asked about the architectural approach, including what other options were considered and the benefits of storing field data in post content versus post meta.
In response, Marin Atanasov said, “ We chose the content mostly because it has been the easiest to move forward. We are considering moving some fields to post meta, to facilitate filtering, for example.”
He also highlighted that related work is already underway in adjacent areas such as taxonomies, while emphasizing that post type storage is still evolving as the interface is relatively new.
Performance considerations were also raised by Maarten Belmans, who suggested that storing the data in wp_options with autoloading could be more efficient than querying the posts table.
Atanasov responded that an earlier experimental approach had already explored this method, but emphasized that the final storage mechanism has not yet been decided, “ FWIW, options is exactly the approach I took in my initial approach #77487, and I don’t think we’ve necessarily finalized the storage mechanism. Since this work is experimental, it’s still subject to architectural changes…”
The Community Response
Following the merge, Jamie Marsland said, “ This was just merged into Gutenberg trunk, and it’s a much bigger deal than it looks “
Johanne Courtright described the feature as a positive addition while also pointing to potential concerns, stating, “ It’s a very nice feature, but man not sure I want this much power for someone who is less technical to easily add this to the site. Oof I can see tons of new post type and deranged that later”
Joost de Valk also weighed in on what could come next, asking, “ So… how long before we get this for custom fields too? :)”
Sreenath Kumar described the update as a positive step while noting it could have been introduced earlier,” This is actually a good step, but it needed to be added much earlier.”
Keith Mason also highlighted the delay in its timing, stating, “ I mean as great as this is – its about 15 years too late and its only really useful if adding custom fields, custom taxonomies and relationship management doesnt take another 15 years. But we can live in hope, right? “
Paolo M. Tajani suggested the feature could have been introduced differently while raising concerns about potential conflicts, “ IMO this should have been an official plugin first. I get the excitement, but native CPT creation in core could create confusion: duplicate post types, naming conflicts, plugins registering the same thing differently…”
Matt Cromwell called the feature a necessary addition, “ Post Types have always been something Core has desperately needed in order to be an actual CMS. Finally! Will be interesting to see what plugins do with this new functionality. That is… whenever it finally lands in Core.”