-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Query Loop: Fix 'block' scoped variations to get the query
defaults
#63477
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. |
@@ -122,6 +122,7 @@ function QueryVariationPicker( { | |||
setAttributes( { | |||
...variation.attributes, | |||
query: { | |||
...attributes.query, | |||
...variation.attributes.query, | |||
postType: |
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.
I actually don't understand why we're doing this, Why are we overriding namespace and post type here?
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.
I think we should just call setAttributes( variation.attributes )
since this variation picked is only used when starting blank.
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.
I think we should just call setAttributes( variation.attributes )
Hm.. that could work now. If I remember correctly, this was needed because before we intentionally had the inherit:false
and since properties of object attributes are not merged, we needed to also provide the rest of the props in the variation declaration. But since we could be here from another inserter
Query variation, we needed to respect some important attributes like postType
. I'll update to just set the attributes then.
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.
Ah.. it's also about this PR: #46410. namespace
is used in order to be able to connect variations with variations 😄 . So we cannot do just setAttributes
..
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.
namespace is used in order to be able to connect variations with variations 😄 . So we cannot do just setAttributes..
What? I don't understand this sentence, can you clarify?
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.
I'm understand the issue more, I think combining "block variations" with "inserter variations" was a mistake from the start. Do we know of people actually using that or is it theoretical?
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.
Here's another proposal: "block variations" shouldn't update the query attribute at all, they should just update the inner blocks. So what about removing the setAttributes here entirely?
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.
IF you provide a variation for the query block, you don't need to show the "block scoped variations" at all, you're not starting blank as you picked a variation no?
Not necessarily. You can register variations that don't provide inner blocks.
I'm understand the issue more, I think combining "block variations" with "inserter variations" was a mistake from the start. Do we know of people actually using that or is it theoretical?
There were many issues from extenders and was definitely used. Not sure if some plugins still use it, but there was a lot of traction to get this working. I think the combination of block and inserter
variations stems from the complexity of this specific block and that's why there was a local
implementation.
Here's another proposal: "block variations" shouldn't update the query attribute at all, they should just update the inner blocks. So what about removing the setAttributes here entirely?
This should be a breaking change, no?
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.
This should be a breaking change, no?
I don't think so. For me, it just clarifies the behavior. "Inserter" is about defining the whole block, "block" scoped variations is about the content (which is already the case btw)
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.
This makes sense. Let's try this.
Size Change: +156 B (+0.01%) Total Size: 1.75 MB
ℹ️ View Unchanged
|
29e3c3b
to
d2fdb57
Compare
d2fdb57
to
8bee67c
Compare
…WordPress#63477) Co-authored-by: ntsekouras <[email protected]> Co-authored-by: youknowriad <[email protected]>
What?
Follow up of: #63353
The intention of the linked PR was to allow the
block
scoped Query Loop variations to get the default query values and especially theinherit: true
value. That PR did would normally work, but with the nuances ofobject
handling attributes in GB and specifically also in Query Loop which has other nuances, we need to make the changes in this PR too.Testing Instructions
1- Insert Query Loop block
2- Click "Start blank"
3- Pick one of the proposed variations
4- Notice that the inserted query has the "inherit" toggle enabled.