-
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
Query block: Swap out layouts/patterns for the block #25750
Comments
This is already meant to be handled through the variations mechanism, which currently lacks after-creation transforms. Whatever is improved there should be done in a generic way, not specifically to the Query block. |
Okay, thanks for the feedback, @mtias! For anyone not familiar, here's how the current Transform tool popover looks (ie. Quote block): Query block Transform ToolHere is an iteration on using the Transform Tool in the Query block that can also be extrapolated to other blocks when necessary. I don't believe these are "style variations" so rather than saying "Styles" in the popover, I called them "Patterns." These are also wireframes and not a final iteration. This means that the previews will most likely be actual content. I would love to see the user's actual content reflected in these if possible. Feedback
|
Block styles only add a css-class, and then the theme adds CSS to handle them. |
Sounds right to me, @aristath. The Query block can have block variations, style variations, AND pattern variations. Each block variation (ie. a Latest Posts block) would also have style variations and pattern variations for itself.
Does this sound right? |
@ntsekouras just pointed out issue #25231 which aligns with my last iteration. Thanks, Nik. |
I'm working on a flow for the Query block. In this prototype I have a Query block added to my page with the Post Type set at "Posts."
|
Nice! This is starting to look like a pretty good flow, and in my opinion is the best way to let people easily work on the layout of their Query - with Patterns, I mean. Having the ability to tweak specific parts of the individual post template is probably still useful, but shouldn't be the main way to customize the loop, this feels much more user-friendly already. I'm glad you separated out some of the controls into the toolbar, the main query options have a real discovery problem I think. I still feel like they would also fit well in the sidebar, but I understand that's a meta discussion on what is and isn't considered wysiwyg editing in Gutenberg and all that so I'll digress. |
Design feedback:
|
Looping back on some of design feedback above about creating a placeholder for the block and working on a "setup" solution. This PR adds a Placeholder to the block with layout options: #26378 |
Hey @mapk - Do you think it's okay to close this one in favor of this one: #25231? Since we have decided to follow the |
Sounds good. |
The Query block is such a large part of pages and templates in WP. With it, a person can adjust settings and add/delete child blocks to get the right format for the particular query. But all this requires advanced knowledge and a willingness to jump into the block. For some this can be overwhelming, especially when trying to customize the layout of the results.
Problem
Gutenberg offers "Block Patterns" which can add content to pages, and there are "Block Style Variations" that can change the CSS for a different visual of particular blocks, but we don't quite have a system to swap out more robust layouts on existing content in the Editor.
Once the Query block is set up, how does a user change the layout to match a set of predefined layouts that are offered in Core or by Themes?
Solution
To resolve this, we should allow users to swap predefined layouts/patterns that can reformat the content of the query results. Some discussion began here: #25462 (comment). This issue is to define the UI for this interaction and directly addresses one of the tasks listed here: #24762.
Because the Query block uses the WP REST API, there is a limited set of blocks that can be used inside it. We know what these blocks are, so swapping out layouts and blocks shouldn't be difficult. This means there shouldn't be any unexpected blocks that get lost when swapping layouts as far as I'm aware.
Example of interaction
Keep in mind this is only to convey a possible path forward. More design iterations should be done to verify if this is an intuitive and robust solution.
cc @mariohamann @ntsekouras
The text was updated successfully, but these errors were encountered: