Skip to content

Query / Post-template-block layout controls should be on parent (WP 6.3). #53678

Open

Description

Description

Since 6.3 the new grid layout has come out for the query block. With this came a change to the layout settings (columns, gap, etc) which have now been moved to the post-template block.

I was very convinced this was a huge bug, but after reading the PR this seems intentional, at some point is decided: these controls belong on the post-template block, instead of the query.

Let me argue why this is completely terribly a bad idea.

A query is a collection of posts, this block should be the container for a grid of posts and this grid gets defined by gap and column amount/width).

Each post in this grid is a 'post-template'. It's called a template because that thing is copied in the grid (what we usually call 'cards'). That template defines the layout, style, colors for that 'one single block' from which the template is copied for each post. Inside this template we have a title, excerpt, feat. image, that we add once (user expectation: this post-template thing is copied!).

Why would these have grid layout controls now? It is very against expectations and logical relation with html structure (a grid with a loop containing posts according to a post-template). It makes it more confusing, for a block that already is pretty complex and hard to explain to a normal client with low technical experience.

Simple side effects after testing:

  • If I turn on a background color on the post-template, it now colors the whole query grid, instead of the post-template. Huh? You expect this would give each card a background (and not the gutters also).
  • The user interface now signals the post-template has layout settings. But what if i want a columned post-template with image left and text right? That is the real layout of this post-template and not the grid with gutter and column specs.
  • We now have to put groups inside the post template to actually style background colors of each card.

// rant:
For most corporate sites, 60% if not more of content is query loops of custom post types. Every update I have high hopes, but query blocks and post type archives are again not cutting it. We have to resort to ignoring archives, use pages with our own custom query blocks to offer a user experience that is workable, for actual real life websites!

I know this is a huge undertaking but it is time the default blog experience gets more attention before more fancy features are added. With which I mean: managing collections of post types, and offering robust ways of controlling their templates, on a single post or a card in a grid.

For example there is an issue I wrote a year ago about post-title and feat. image outside of query block, displaying first post in loop on a home.html template (the most basic default blog template). It got closed, then buried. It was very accurately documented. Nobody cared. I've a few more issues related to this, like menu-marking archives, (or even being able to add them to menu's properly).

It is such a shame when a new user uses your blog system in the most simple way and it then fails doing the most default things.

Try it yourself. Build a simple site with a few cpt's and add some rows with simple query loop grids. You will find so many problems during that trip. I know, it's easy to complain, and I'd love to help more on testing and feedbacking this, but I've spent so many hours on issues that are still there 2 years later.

Step-by-step reproduction instructions

  1. Add a query loop block.
  2. Inspect the template.
  3. See controls are here instead of in query block.

Screenshots, screen recording, code snippet

No response

Environment info

  • WP 6.3
  • Default TT23

Please confirm that you have searched existing issues in the repo.

Yes

Please confirm that you have tested with all plugins deactivated except Gutenberg.

Yes

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions