-
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 Library - Query]: Set inherit value according to detected context #32230
Conversation
Size Change: +40 B (0%) Total Size: 1.86 MB
ℹ️ View Unchanged
|
I realized that we can edit templates like |
IMO:
|
Isn't it confusing that block behaves different depending on the insertion position. (In site editor context you can insert both outside and inside the post). That said, what's important for me is that the markup stays the source of truth. Meaning that if you insert a block, copy/paste it somewhere else, it doesn't change the behavior. |
The Query block is confusing because it has been built to serve two related but very different purposes at the same time:
Unfortunately the design doesn't really hold up so well, and folks get confused by options like "Inherit query from URL" :D I've said this elsewhere, but I think the optimum UX would be dedicated variations for these purposes. IE, if I am editing a post or page:
This solves the unpredictable behaviour you mention, and also creates a more intuitive UX (I don't expect many average users wanting to add posts to a page will search for a "Query" block). If I am editing a template like index or archive:
|
I also believe variations are the best approach to make the UX more understandable as @jameskoster explained. It would also solve the renaming of the Query block, although I'm not sure how to make then the inner blocks' names relatable to the variations, as right now they are named |
@priethor there was a fairly long discussion in #26856 around giving those blocks more generic names. IE "Title" instead of "Post title" or "Product title" or "Page title". I still think this is a good idea because it means a single block feels intuitive in all of those contexts, plus others like editing the single template which can entertain all manner of post types. |
Description
Part of: #30369
We need to find a way to detect the context a Query block 'lives' and handle any settings needed appropriately. By context I mean FSE context (site-editor) or a page/post (post-editor). Moreover is valuable to even know the kind of template we are on FSE context (related: #29438).
This PR checks during the insertion of a Query block if we are in FSE context or not and sets the
inherit
value accordingly.In a single page there is no much use in having an inherit Query, but instead a custom one. Since
Query
block is now incore
and the site editor is not, we should at least set this value to false when is inserted in post editor.Testing instructions
Query
block and clickStart blank
inherit
option is set tofalse
site editor
and observe that theinherit
option is set totrue
Notes
This change overrides the
Query patterns inherit
value which is not bad as this is something that should be handled under the hood mostly. It will be revisited in the next iteration for the context detection which should make more changes toQueryLoop
depending on the current template editing etc..Related: #30910