-
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: Use default values in connected custom fields in templates #65128
Block Bindings: Use default values in connected custom fields in templates #65128
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. |
This could work well |
if ( isGlobalTemplate && props.object_subtype ) { | ||
return; | ||
} | ||
metaFields[ key ] = props.default; |
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.
What will happen when the default
is undefined or empty?
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 says:
Apart from that, when no default is provided, it should still show the meta key.
I'll test it.
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.
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 seems that is returning an empty string, as documented here:
https://developer.wordpress.org/reference/functions/get_metadata_default/#description
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's a very interesting idea. I'm wondering how it will fit when nested into the Query Loop block. The other edge case I can think of is post meta that skips the default value. |
44cccb1
to
e2fddae
Compare
Size Change: -1 B (0%) Total Size: 1.78 MB
ℹ️ View Unchanged
|
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.
434ec40
into
experiment/add-meta-post-type-api
…lates (#65128) * Abstract `getMetadata` and use it in `getValues` * Adapt e2e tests * Update e2e --------- Co-authored-by: SantosGuillamot <[email protected]> Co-authored-by: cbravobernal <[email protected]> Co-authored-by: gziolo <[email protected]> Co-authored-by: mtias <[email protected]>
…lates (#65128) * Abstract `getMetadata` and use it in `getValues` * Adapt e2e tests * Update e2e --------- Co-authored-by: SantosGuillamot <[email protected]> Co-authored-by: cbravobernal <[email protected]> Co-authored-by: gziolo <[email protected]> Co-authored-by: mtias <[email protected]>
* Initial commit. Add meta field to post types. * Add post meta * Add todos * Add fields in all postType * WIP: Add first version to link templates and entities * Revert "WIP: Add first version to link templates and entities" This reverts commit a43e391. * Only expose public fields * Add subtype to meta properties * Render the appropriate fields depending on the postType in templates * Use context postType when available * Fetch the data on render, preventing one click needed * Yoda conditions.. * Try: Expose registered meta fields in schema * Try: Create a resolver to get registered post meta * Use rest namespace * Move actions and selectors to private. * Add unlocking and import * Merge useSelect * Fix duplicated * Add object_subtype to schema * Update docs to object_subtype * Add explanatory comment * Block Bindings: Use default values in connected custom fields in templates (#65128) * Abstract `getMetadata` and use it in `getValues` * Adapt e2e tests * Update e2e --------- Co-authored-by: SantosGuillamot <[email protected]> Co-authored-by: cbravobernal <[email protected]> Co-authored-by: gziolo <[email protected]> Co-authored-by: mtias <[email protected]> * Try removing all object subtype * Fix e2e * Update code * Fix `useSelect` warning * Remove old comment * Remove support for generic templates * Revert changes to e2e tests --------- Co-authored-by: mtias <[email protected]> Co-authored-by: cbravobernal <[email protected]> Co-authored-by: SantosGuillamot <[email protected]> Co-authored-by: Mamaduka <[email protected]> Co-authored-by: gziolo <[email protected]> Co-authored-by: youknowriad <[email protected]> Co-authored-by: tyxla <[email protected]> Co-authored-by: TimothyBJacobs <[email protected]> Co-authored-by: artemiomorales <[email protected]> Co-authored-by: spacedmonkey <[email protected]>
…lates (#65128) * Abstract `getMetadata` and use it in `getValues` * Adapt e2e tests * Update e2e --------- Co-authored-by: SantosGuillamot <[email protected]> Co-authored-by: cbravobernal <[email protected]> Co-authored-by: gziolo <[email protected]> Co-authored-by: mtias <[email protected]>
…dings workflows (#65099) * Initial commit. Add meta field to post types. * Add post meta * Add todos * Add fields in all postType * WIP: Add first version to link templates and entities * Revert "WIP: Add first version to link templates and entities" This reverts commit a43e391. * Only expose public fields * Add subtype to meta properties * Render the appropriate fields depending on the postType in templates * Use context postType when available * Fetch the data on render, preventing one click needed * Yoda conditions.. * Try: Expose registered meta fields in schema * Try: Create a resolver to get registered post meta * Use rest namespace * Move actions and selectors to private. * Merge useSelect * Fix duplicated * Add object_subtype to schema * Update docs to object_subtype * Add explanatory comment * Block Bindings: Use default values in connected custom fields in templates (#65128) * Abstract `getMetadata` and use it in `getValues` * Adapt e2e tests * Update e2e --------- Co-authored-by: SantosGuillamot <[email protected]> Co-authored-by: cbravobernal <[email protected]> Co-authored-by: gziolo <[email protected]> Co-authored-by: mtias <[email protected]> * Try removing all object subtype * Fix e2e * Update code * Fix `useSelect` warning * Remove old comment * Remove support for generic templates * Revert changes to e2e tests * Change the value returned by `getFieldsList` to include label * Use label in bindings panel * Use label in rich text placeholders * Add filter to include `label` * Use title instead of label in schema * Add safety check * Adapt branch after rebase * Remove extra spaces * Don't rely on key outside of post meta * Remove key from bindings component * Read title instead of label * Add backport to changelog * Update translator comment --------- Unlinked contributors: dannyreaktiv. Co-authored-by: cbravobernal <[email protected]> Co-authored-by: SantosGuillamot <[email protected]> Co-authored-by: gziolo <[email protected]> Co-authored-by: mtias <[email protected]>
What?
This PR is built on top of #64072 because it reuses the logic added there.
Basically, I'm exploring the possibility of using the default values of the custom fields in templates instead of the meta keys.
Apart from that, when no default is provided, it should still show the meta key.
Why?
It could make sense to show the default value in templates. First, it looks nicer. Second, it is how the post will look like if the value is not overriden.
How?
I'm reusing the logic introduced in #64072 to get the registered meta fields object, which includes the default value, and use it in
getValues
function.Apart from that, while testing it, I realized that
toHaveText
check is true when the string is part of the expected value. This means that if the value is "Value of the text_custom_field", and we check `expect( paragraphBlock ).toHaveText( 'text_custom_field ' ), it returns true when that is not expected.For that reason, I changed the text to ensure the key and the value don't overlap.
Testing Instructions