-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Block bindings: Hide keys starting with underscore #64618
Conversation
Size Change: +14 B (0%) Total Size: 1.77 MB
ℹ️ View Unchanged
|
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. |
Ping to @bacoords , I cannot assign him as a reviewer. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It should be good as a temporary measure, but we need to establish a more robust approach where the list of options is computed on the server and exposed in the REST API endpoint level through its schema as discussed in #64072.
Thanks for your work on this! |
I completely agree with you, but this way we can avoid private keys from leaking in a quick way (similar with footnotes). |
Developers can also mark any meta as protected using |
We have all the rules for Post Meta visibility encapsulated on the server in these lines of code: That's why I left the remark that the list of the options to expose in the UI should be produced on the server. |
💯 We need this exposed via the REST API for a more permanent solution. |
Should this require creating a new REST API endpoint for this meta? I feel it may be overkill. We could filter the |
At some point, I wanted to explore the possibility to create a new endpoint for bindings, but I didn't find a big reason to do it yet. We will probably have more info once we know better what external sources expect.
I believe we can't filter the |
What?
Fixes #64575
Why?
Keys starting with underscore should be considered as hidden following the guides:
https://developer.wordpress.org/plugins/metadata/managing-post-metadata/#hidden-custom-fields
How?
By filtering the values like footnotes.
Testing Instructions
I think we should wait for a definitive version of the UI to add an e2e test for this one. As reaching the list of fields to bind is not so easy (all the attributes are computed generated).
Testing Instructions for Keyboard
Screenshots or screencast
Screenshot of the UI not showing private registered field color.
The field in the database.
Code used to add the field:
add_post_meta( 61, '_color', 'red', true );