Merged
Conversation
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
|
Size Change: 0 B Total Size: 7.75 MB ℹ️ View Unchanged
|
|
Flaky tests detected in 1855def. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/24712515306
|
tyxla
reviewed
Apr 21, 2026
Member
tyxla
left a comment
tyxla
left a comment
There was a problem hiding this comment.
Thanks @ntsekouras, this is looking good to start with 👍
I've got some suggestions, but I believe we can work on most of them after landing.
This tests mostly well, there's some weird behavior when editing taxonomies (we don't always see the change immediately), which we should take a look at.
| 'delete_published_posts' => 'manage_options', | ||
| 'edit_others_posts' => 'manage_options', | ||
| 'delete_others_posts' => 'manage_options', | ||
| 'publish_posts' => 'manage_options', |
Member
There was a problem hiding this comment.
Should we also add:
read_private_postsdelete_private_postsedit_private_posts
Member
There was a problem hiding this comment.
Definitely not a blocker. Right now there is no way to create a private post in the UI
| return null; | ||
| } | ||
|
|
||
| $config = json_decode( (string) $record->post_content, true, 8 ); |
Member
There was a problem hiding this comment.
Should we consider storing config in post meta? This seems a bit fragile.
Contributor
Author
There was a problem hiding this comment.
We should definitely consider how the config should be handled best. I think it will become more obvious when we'll add the rest of the taxonomies fields. We need to have a secure way of storing/consuming the data and also flexible to be used efficiently for queries and our APIs.
I'll soon open an initial tracking issue and this should be part of it.
Co-authored-by: Marin Atanasov <8436925+tyxla@users.noreply.github.com>
tyxla
reviewed
Apr 21, 2026
tyxla
approved these changes
Apr 21, 2026
Member
tyxla
left a comment
tyxla
left a comment
There was a problem hiding this comment.
I think this is good to go 👍 Thanks!
There are some follow-ups to be done (see open comments), but since this is an experiment, we can address them in subsequent PRs.
🚀
|
Thanks for working on this! I'd like to follow the progress on this experiment. |
This was referenced Apr 21, 2026
t-hamano
reviewed
Apr 21, 2026
| ), | ||
| isValid: { | ||
| required: true, | ||
| pattern: '^[a-z0-9_-]{1,32}$', |
Contributor
There was a problem hiding this comment.
Apologies for the late notice, as the PR has already been merged, but would it be possible to relax this regular expression rule?
I'm sure that lowercase alphanumeric characters, dashes, and underscores are recommended, but in fact, only the length of the text is checked. And I know that in Japan, at least, there are many users who use non-alphabetic characters in slugs on a daily basis.
Member
There was a problem hiding this comment.
Of course, @t-hamano. Note that this is still in a very early state, and we'll be iterating in the coming weeks. You can also see I had a lot of feedback in this PR that we haven't addressed.
Member
There was a problem hiding this comment.
@t-hamano circling back on this. AFAIK there are many places where sanitize_key() is ran on the taxonomy slug in core, which will remove any characters that are not alphanumeric, dashes, or undescores. This may lead to subtle bugs in many places, like various checks not working as intended, or even capabilities being broken. AFAIK this is why core has been recommending the current limitation, even if it doesn't seem to be explicit during registration. Thoughts?
Member
Sounds like a new label will be needed. I'm fine with creating that a later point if we decide we need it. |
Member
There was a problem hiding this comment.
While looking into #77497 (comment), when the build failed in #75814, catching that missing dependency, I noticed that the routes/* use TypeScript but are never type-checked. You can use any non-existent type imports, but npm run clean:package-types && npm run build never catches them.
Contributor
Author
|
@hanneslsm I created a label for this experiment, but please be aware that we might update or remove it eventually. |
ntsekouras
added
the
Content types (experimental)
This was referenced Apr 22, 2026
Member
|
All follow-ups that haven't already been addressed are listed in #77600 and we'll address them separately. Thanks everyone for helping here 🙌 |
This was referenced Apr 23, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
5 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What?
In the same spirit with: #77487
This PR adds under a Gutenberg experiment the ability to add and edit custom taxonomies. For now you can manage only a few necessary fields and not all of them - we will iterate.
Let's see how far we can get with the current APIs and how possible it can be to support the majority of use cases for custom taxonomies (and later for post types), where it's assumed that the majority of the cases are the simpler ones.
How
Testing Instructions
Content types: manage custom taxonomiesexperimentSettings/Taxonomiesand play around with adding and editing taxonomies.Screenshots or screencast
Screen.Recording.2026-04-20.at.4.55.20.PM.mov
Use of AI Tools
Opus 4.7