The release of Gutenberg 23.1 brings a long-anticipated but unexpected feature: a user interface for managing custom post types and taxonomies directly within WordPress admin. This new UI, tucked under the Settings menu as an experimental option, has stirred a mix of enthusiasm and skepticism among developers and site owners alike.
Key Takeaways
- Gutenberg 23.1 introduces an experimental custom taxonomies and post types UI in WordPress admin.
- The feature moved from proposal to merged pull request in under two weeks, reflecting rapid development.
- Community reaction is divided, questioning the timing and readiness of the UI.
- This change signals a shift toward more accessible content type management within WordPress core tools.
- Site owners and developers should test the new UI cautiously before adopting it in production.
Background: Custom Taxonomies and Post Types in WordPress
Custom post types and taxonomies have been foundational to WordPress extensibility for over a decade. Traditionally, these are registered programmatically via PHP code or through plugins, requiring technical knowledge or reliance on third-party tools. This approach, while flexible, often creates barriers for site owners and less technical users who want to tailor content structures without coding.
Efforts to provide a UI for managing these custom content types date back years in the WordPress project and community plugin space. However, attempts to integrate such functionality into core or bundled tools have faced challenges related to complexity, user experience, and potential conflicts with existing code.
The Gutenberg 23.1 Custom Taxonomies UI Feature
The latest Gutenberg plugin release, version 23.1, ships with an experimental interface allowing users to create and manage custom post types and taxonomies through the WordPress Settings menu. This UI lets users define labels, slugs, hierarchical behavior, and visibility options, all without writing code. The feature was rapidly developed, moving from initial discussion on GitHub to merged pull request in less than two weeks, highlighting a focused effort by contributors.
This interface is currently marked experimental, meaning it is not yet enabled by default and likely to evolve based on user feedback. It is designed to integrate with the broader block editor and WordPress admin experience, aiming to simplify content architecture management for site owners and agency clients.
Community Response: “Why Now?” and Skepticism
The introduction of this feature has prompted a wave of questions within the WordPress community. Many experienced developers and plugin authors expressed surprise at the timing, wondering why such a significant UI change was merged without extensive prior testing or broader discussion.
Some skepticism centers on the readiness of the UI, its potential impact on existing sites with complex content structures, and how it might overlap or conflict with established plugins that offer similar functionality. Questions also arise about whether this shift aligns with WordPress’s core priorities amid ongoing performance and usability challenges.
On the other hand, proponents argue that enabling non-technical users to manage custom content types directly helps democratize site customization and reduces dependence on third-party solutions. The rapid development cycle is seen by some as a sign of agile responsiveness to community needs.
Technical Implications and Backward Compatibility
In practice, adding a UI for custom taxonomies and post types changes how site administrators interact with WordPress’s content model. It abstracts registration away from code and into the admin, which could simplify workflows but also raises concerns about version control, portability, and potential conflicts.
For most WordPress sites, especially complex or enterprise-level deployments, custom post types and taxonomies are managed in code or configuration files for stability and repeatability. Introducing a UI layer risks fragmenting management approaches and complicating migrations or updates.
Developers should consider how this UI integrates with existing tools and workflows. Plugin and theme authors might need to accommodate or restrict this UI to prevent unintended changes on production sites.
Comparison to Previous Approaches
Previously, users relied on plugins like Custom Post Type UI or manually adding code snippets to functions.php or custom plugins. While these methods require more technical skill, they provide explicit control and versioning through codebases.
Gutenberg’s new UI represents a shift toward a more visual, user-friendly approach aligned with the block editor’s philosophy of editing everything in context. However, it remains experimental and not yet a full substitute for code-driven registration.
What This Means for WordPress Users
The arrival of the custom taxonomies UI in Gutenberg 23.1 should be seen as an invitation for experimentation, not immediate adoption. Site owners, agencies, and developers should test this feature in staging environments to understand its capabilities and limitations.
For developers, this change signals a potential trend toward expanding the WordPress admin’s scope to cover more content architecture tasks. Plugin authors will want to monitor how this UI evolves to ensure compatibility and consider how to integrate or disable it as needed.
Agencies and freelancers should prepare to educate clients on this new workflow while cautioning about its experimental status. It also highlights the ongoing balancing act between empowering non-technical users and preserving the stability and portability of WordPress sites.
Looking ahead, this UI could become a core part of WordPress’s content management toolkit, reducing reliance on third-party plugins and making custom content types more accessible. However, it will require careful development, feedback, and iteration to meet diverse user needs without introducing fragmentation.
Frequently Asked Questions
What exactly does the new custom taxonomies UI in Gutenberg 23.1 do?
It provides an experimental interface in WordPress admin for creating and managing custom post types and taxonomies without coding, allowing users to define labels, slugs, and settings via the Settings menu.
Is this new UI enabled by default in WordPress core?
No, the feature is currently experimental and not enabled by default. Users must enable it manually for testing and feedback purposes.
Will this replace plugin solutions like Custom Post Type UI?
Not immediately. While it offers similar functionality, it is still in early stages and may not provide all features or flexibility that established plugins offer.
Could this new UI affect existing sites with custom content types?
Yes, there is a risk of conflicts or unintended changes if the UI is used alongside programmatically registered post types and taxonomies. Testing in staging environments is recommended.
