Experiment: Content types tracking issue

[ntsekouras]

The problem

WordPress introduced registration of custom taxonomies in WordPress 2.3 (September 2007) and custom post types in WordPress 2.9 (December 2009). Both of them have been exceptionally important to shape and position WordPress as a CMS, and to provide the necessary flexibility in allowing different types of expression in content. However, WordPress never provided a core way to manage them, leaving those fundamental structural mechanisms available only for developers, and historically relied on plugins for that. Plugins, unfortunately which never came up with a consistent, coherent way to manage these fundamental content structures. The plugins do the job, but using them transfers trust and longevity to a third party for what is arguably a primitive of the platform. Not to mention that this creates a dependency on those third party plugins - orphan content is a known failure when those plugins are deactivated.

Why solve it in Core

Existing plugins are great, and we're not trying to replace what they do well. The argument for Core ownership is the same argument that's applied historically to navigation menus, templates, patterns, and fonts: when something is a fundamental primitive of the platform, the platform should ship a baseline, and plugins should extend that.

A few specific reasons:

• Data ownership - When a plugin registers post types in PHP at runtime, the site's structure is bound to that plugin's lifecycle. Core ownership means user-defined content types are first-class data, not plugin state.
• Consistency. The new admin paradigm (DataViews, DataForm, the site editor) is where users already manage structural concepts. Content types eventually belong there too. Asking users to context-switch into a plugin's bespoke UI for one of the most fundamental concepts in WordPress is a coherence problem.
• Foundation for other work. Block bindings, query loop, block-based templates, DataViews, DataForms, and a lot of the upcoming editor surface area increasingly assume the site can model its content. The editor has been outpacing what non-developer users can actually configure.
• Built-in extensibility. "Simple cases in Core, complex in plugins" is the line we're drawing. Custom field types, complex relationships, conditional logic, advanced UI — those are where plugins add value, and they're explicitly out of scope here.
• Discoverability. A WordPress user opens the admin and sees Posts, Pages, Media, Comments. The fact that their site could model "Books," "Recipes," or "Events" is invisible — that capability simply doesn't surface in the admin. Users who could benefit from custom content types often don't know the option exists.

Goal

Allow the WordPress admin to let you express the primitives that WordPress runs on. In a nutshell, this entails:

• A user who wants a basic, categorizable content type can do it from the admin without code, plugins, or the REST API.
• Stable and consistent storage and REST shape that we'd be willing to commit to long-term.
• Internationalization story for labels resolved, even if left for 3rd party extensions to fully cover (this is one of the genuinely hard open questions; see the tracking issue).
• DataViews / DataForm / related primitives are absorbing various cross-cutting concerns that this work surfaced.
• Existing CPTs and taxonomies registered in PHP keep working untouched alongside user-defined ones, and disabling the experiment doesn't damage data.

Success/promotion criteria

We would consider promoting the experiment to core when:

• The simple-case bar above is met and tested with real users.
• Storage/REST shape has been through enough churn to feel stable.
• Performance is profiled and acceptable
• There's a comprehensive test suite covering the REST API functionality and all basic flows
• Edge cases like slug changes, deletion of unrelated entities, and others, are handled properly

Failure criteria

We could consider dropping the experiment in case:

• The storage model doesn't meet real-world scale, performance, or extensibility expectations.
• The i18n story for labels can't be solved without major compromises that defeat the purpose.
• We've failed the extensibility bar and the "simple cases" bar requires us to keep adding surface area until we've effectively rebuilt one of the plugins inside Core, at which point Core ownership stops being the right answer.
• User research shows the addressable audience is too narrow to justify the Core surface area.

Phases

Longer-term, we're considering splitting the work in the following phases, which most likely will end up being individual experiments:

1. Basic post type and taxonomy management (current focus)
2. Managing custom fields of post types and taxonomies, with built-in extensibility for custom field types
3. Managing existing core- and plugin-registered types (potentially under a constant or developer flag)

Architecture

• Add more fields for taxonomy creation and edit. This will probably result to a new page for creating a taxonomy instead of the current Modal. PR: Experiment: Taxonomies new package and add/edit screens #77657
• Separate page for edit and add taxonomy. PR: Experiment: Taxonomies new package and add/edit screens #77657
• Consider renaming the current edit action to quick edit and create edit action that redirects to a separate page. PR: Experiment: Taxonomies new package and add/edit screens #77657
• Revisit how we store and consume the config of the entity. Should we use post_meta for some fields. Investigate implications, security, performance. PR: Experiment: User Taxonomies REST controller #77697
• Revisit/profile possible performance implications with the taxonomy_object_type as post meta. See 1, 2, 3.
• Consider adding revisions support
• Consider introducing a single package (e.g. content-types) in place of the separate ones to reuse components, utils, etc.. between the two. 1
• Consider having a single page/route with tabs to manage the post types and taxonomies. PR: Experiment: Content types single route and package #78059
• Revisit the whole architecture storage model. We've started with CPTs but eventually a dedicated DB table could be the way forward. Evaluate other alternatives too.
• Consider abstracting storage-related functionality from REST endpoints (see Content types: flush rewrite rules on rewrite-impacting changes #78058 (comment))

Taxonomy fields

• Add more fields. Right now we've only added all labels. This task should be implemented incrementally for easier testing. Visibility fields PR. Advanced fields part 1
• Users should have a way to auto-fill labels based on the required singular and plural labels. PR: Experiment: Taxonomies implement auto-fill labels #77786
• Investigate how/if labels are internationalized. Maybe adding some filters that 3rd party plugins is the way to go here.

Enhancements

• Relax taxonomy-key pattern validation. See ongoing discussion here: Experiment: Add custom taxonomies #77497 (comment)
• Add more filters - especially the post type. This is related to how we end up storing the config. PR for post type filter: Experiment: User Taxonomies REST controller #77697
• Delete action should also have a way to delete the terms created. Consider having a checkbox for deleting terms in the delete dialog. It should also check and delete any default term set for the taxonomy (see here. PR: Content Types: Add checkbox for deletion of terms  #78629
• Explore disabling create/save button based on form validity. PR: Experimental: Content types - disable create/save button based on form validity #77931
• Introduce a "Duplicate" action - Content Types: Add Duplicate action to taxonomy management #77853
• Autopopulate slug based on singular label. PR: Experiment: Auto fill slug from singular label for taxonomies and post types #77938
• When duplicating a post type or taxonomy, we should ensure the generated slug is not taken. PR: Content Type: Handle duplicate slug generation for CPT's and Taxonomies  #78341
• Check slug availability on auto-fill PR: Content Type: Handle duplicate slug generation for CPT's and Taxonomies  #78341
• Integrate useView to preserve search, filters, etc.. PR: Experiment: Integrate useView in content types lists #78197
• Introduce a link to all posts from a specific CPT / all terms from a specific taxonomy Content Types: Introduce view items actions #78104
• Migration path for existing posts and terms after renaming the post type/taxonomy slug

Bugs

• Fix height of taxonomies page. DataViews should fit 100% height like we do in site editor. PR: Experiment: Improve taxonomies DataViews height #77603

Cross-cutting concerns

• FormTokenField: Add help prop to render additional help text below the field
• DataForm: Render field description as help text in the array control
• Consider adding actions' section in DataForm layouts to support cases like the auto-fill labels in add/edit taxonomy. Another thing we could consider is supporting ReactNode in the FormField description, though this is not serializable.
• Now that the Drawer component has landed, explore using it for the edit action. This will inform us whether is good for our use case and whether the quick edit in site editor can use it too.
• Add or augment e2e createPost utils to handle easier creation of different post types. See: https://github.com/WordPress/gutenberg/pull/77998/changes#r3194246751. PR: Testing: Add createRecord e2e request util #78017
• Fields with hidden through isVisible API that also have validation can make a DataForm invalid, even if we only want validation when the field is visible. There is a workaround by using custom validation but it should probably be baked in the DataForm handling. An example is the default term name for user taxonomies (current experiment) introduced here.
• Explore cross-entity cache invalidation in core data package. PR: Core Data: Add private API for cross-entity cache invalidation #78287

Post Types

• Introduce a post types management interface - Content Types: Add post type management #77754
• Introduce a dedicated REST controller, move some fields (filterable ones for example) to post meta. Experiment: User post types REST controller #77915
• Handle flush_rewrite_rules() on change of has_archive, public, or renaming the CPT slug - Content types: flush rewrite rules on rewrite-impacting changes #78058
• Next steps for existing CPT posts after deactivating a CPT
• Avoid parsing JSON content on every init
• Consider supporting non-public taxonomies?
• Add more fields for menu icon, menu position, rewrite, etc. Content Type: Add menu_icon and menu_position fields #78285
• Should we drop "show in REST API" control since disabling it might break stuff? PR: Content Types: Remove "show in REST API" #78668
• Labels is a huge collection of fields, consider sub-grouping of the labels or better organizing them
• Introduce a "Duplicate" action - Content Types: Add Duplicate action to post type management #77844
• Add label autofill functionality - Content Types: Abstract and reuse label autofilling for post types #78099

Integrations

• Make sure post types and taxonomies relationships are integrated and synchronized.
  • When saving one entity, the related one should autoupdate its relationships PR
  • When deleting an entity, the ones that contain relationships with it should clear that relationship PR
  • Improve handling of inactive post types and taxonomies association. The related fields (e.g. taxonomies) should retrieve inactive user taxonomies too. See: Experiment: Sync user taxonomies with post types #77997 (review)
  • Saving a taxonomy with a changed object_type (or a post type with a changed taxonomies field) syncs the relationship server-side, but the client doesn't invalidate getEntityRecords for the other domain. Switching tabs after such a save can show stale rows. PR: Experiment: Content types invaidate cache for synced taxonomies-post types #78143
• When deleting or changing the slug of a taxonomy, "Post Terms" block instances are orphaned.

Notes

This is a living issue, and any suggestions are welcome.

[desrosj]

👋 Hi @ntsekouras and @tyxla,

Thanks for your work on this! I have been looking through the various PRs and issues here, but unless I'm missing something, there seems to be some details missing. It would be great to support this work by encouraging others to contribute or test, but I need some answers to the following before I can do that:

• Why is this being tackled? I don't see any compelling discussions or reasoning as to why this is a problem that WordPress Core should tackle. How does this fit into the roadmap and the 4 phases?
• What is the root problem that is being solved here? I understand that it's to provide the ability to add and manage taxonomies and post types, but what are the actual user problems being solved here?
• What are the benefits of making this available to users in Core? Content types is a fairly advanced concept. I'd argue it's a huge benefit to the majority of users that WordPress manages the content types for them without needing to even be aware of it. There are a few very popular plugins out there (particularly this one) that solve this problem really well. So curious about the motives to rebuild this in a way that's native to WP.

Some details about the experiment itself (including but not limited to the following) would also be really helpful:

• What would success look like?
• What are we hoping to achieve?
• What would be the point we would consider promoting it from an experiment to stable?
• What would be the point we declare that the experiment did not work out?

I'm sure that this has been considered already, and that it takes time to collect the thinking so far into a somewhat comprehensive outline, but I think that more people will be willing to help out and test the experiment more broadly if the rationale is clear and compelling. Since this is in the early stages, it's a great opportunity to gather this now.