contentOnly patterns experiment: Make the Inspector fields key a private API
#73376
Conversation
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
talldan
requested review from
ajitbohra,
ellatrix and
fabiankaegy
as code owners
|
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. |
talldan
changed the title
fields key a private APIfields key a private API
talldan
added
[Feature] Blocks
4 tasks
|
Size Change: +396 B (+0.02%) Total Size: 2.49 MB
ℹ️ View Unchanged
|
Member
|
I for one would argue that as long as we have the feature hidden behind the experimental setting, this approach isn't necessary. Wouldn't it actually be good to get 3rd parties to be able to test this with the experiment active to provide feedback & testing? |
Member
|
Or put another way, I think we should leave this behind an experimental flag for as long as we don't think it's ready. We shouldn't ship this in core without the api being public. |
Contributor
Author
|
@fabiankaegy It's a nice idea, but AFAIK there's no agreed upon way to do that currently. If we expose an API like this it's considered public, and if a third party uses it that's a contract and we can't break their code with the current WordPress backwards compatibility rules. I don't love it, but I have to live within the current rules, otherwise it's an anarchy. There's a discussion about this exact thing in Create a mechanism to expose unstable APIs to plugins, with no conclusion, so I'd encourage you to share your point there. |
Contributor
Absolutely, I totally agree that's where we want to get to. One of the things that @talldan and I have encountered while we work on the shape of While perhaps overly cautious, I'm very supportive of the approach in this PR because we (at least Dan and I) would like to have confidence that we can overhaul the shape of the API in subsequent PRs without breaking anything. But once we're in a place where we're using DataForm and have a proper proposal of the kind of API shape we'd like to have, I agree — let's remove the Thanks for raising the thoughts and concerns, though! |
andrewserong
approved these changes
Nov 19, 2025
Contributor
andrewserong
left a comment
andrewserong
left a comment
There was a problem hiding this comment.
This is testing well for me, and the blocks package sounds like a good place to put it — it looks like the primary purpose here is to make sure that .fields isn't unintentionally exposed when calling getBlockType, so this feels natural to me.
Also, while it adds a few lines to each of the blocks, it'll be easy to remove again when we're ready to stabilise the settings.fields API.
I'll merge this in now, so that I can rebase the ContentOnlyControls PR (#73374) to use it.
ramonjd
pushed a commit
that referenced
this pull request
Nov 19, 2025
Co-authored-by: talldan <[email protected]> Co-authored-by: andrewserong <[email protected]> Co-authored-by: fabiankaegy <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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?
Follow-up to #71730.
Makes the
fieldskey for blocks a private API. Avoids any risk that anyone might consider this a public API, or that it might leak as a public API if/when the contentOnly patterns experiment is stabilized.It's expected that changes that would usually be considered 'breaking' will be made to this API to make it conform more to the DataForms fields API. Eventually it may even be removed and subsumed entirely into the block attributes API. At the moment it's best for external users to not use this API.
How?
Uses a
Symbolas a private key.The
blockspackage exports this Symbol.blocksis a good place as both theblock-editorpackage and theblock-librarypackage can import from it. Also the API isblocksrelated.Testing Instructions
Expected: you should still see fields in the sidebar.
Screenshots or screencast