Query block: Inspiration from Drupal's Views module

[aristath]

While working with the query block and FSE themes I thought I'd give a look at what other CMSs do... Particularly Drupal.
Drupal has a "views" module. It's far more advanced than what we're trying to achieve with the query block, but it does have some good ideas. Its UI is more developer-oriented, and is not WYSIWYG, but I'll post a screenshot of its options below:

Left Column:

• Title - We add that as a separate block above the query if we want to.
• Format - Has options for list, table, grid etc. This is something that we'll need to have... Semantically sometimes they will need to be lists with proper <ul><li> items. Tables can come later, but it's important we have them as lists. Not everything is supposed to be a <div> on the web, and most themes (non-FSE themes) print lists on brogrolls 'cause that's what makes sense semantically.
• Fields - We add those as separate blocks.
• Filter Criteria - There are already other tickets to experiment with filters.
• Sort Criteria - There are already other tickets to experiment with filters.

Middle Column:

• Page Settings - The one thing we're missing here is permissions. But I don't think it should be implemented in the query block anyway... If at some point permissions are added they should probably be in a group block wrapping the query and not in the query itself.
• Header - We add this as a separate block
• Footer - We add this as a separate block
• No Results Behavior - This is a great idea and something we'll need.
• Pager - We add this as a separate block
• Language - Not relevant at this stage, WP is not multilingual (yet).

Right Column:

• Advanced options - Not relevant at this stage.

cc @ntsekouras @mapk

[ntsekouras]

Hey @aristath - thanks for exploring ideas!

To be honest Drupal is a CMS I haven't worked with before, but your screenshot seemed to me intimidating and hard to understand. I think your point here is to highlight the features of it, no? If that's not the case please provide some more info on what you're proposing.

With my above assumption (features highlight) my thoughts are:

Left column:

The only thing that is not being discussed or already supported (at least partial support) is the format. I've made some experiments with the display options as grid/list, which is going to be definitely needed and will be implemented (task here). The interesting part you mention and I wasn't sure as well, is the div versus list. Latest Posts block now renders a ul list.
I'm not sure which one make more sense semantically and will be good to discuss. @kellychoffman @mcsf @jasmussen any thoughts on this one?

Regarding the table option I think it's another issue and we can look at such options down the road.

Middle column:

No Results Behavior - This is a great idea and something we'll need.

Yes this should be a simple placeholder I think, that is missing now.

[aristath]

I think your point here is to highlight the features of it, no? If that's not the case please provide some more info on what you're proposing.

Correct. I used Drupal as an example because it may be intimidating, but at the same time it has every option under the sun. Most of them are things we won't need or won't want to do, but there are some ideas worth exploring.

The 2 main things that I feel we should add is the format, and no-result-behavior.

Especially the format option would be critical for many reasons - including a11y (a list of posts should be announced as a list), SEO (search engines understand lists and show them differently), and semantic behavior.

[jasmussen]

I'm not sure which one make more sense semantically and will be good to discuss. @kellychoffman @mcsf @jasmussen any thoughts on this one?

If things are in list form, a list item makes sense for sure. Overall I would defer to developers on the specific implementaton aspects and what features the query block should support.

However I would echo that the list of features is intimidating, so even if those features are largely meant to be for the Query block alone, and to be abstracted away in patterns, or wrappers such as the Latest Posts block (at some point), and to an extent even themes, there's definitely an interesting challenge here when it comes to sorting, displaying and handling all that complexity. Perhaps uncovering it in a progressive way — adding a property/filter with a plus button when you need it — may be a good way to do that.

[mtias]

The Query block should be entirely agnostic regarding formatting. Formatting should come from individual blocks (like "Latest Posts") or other containing elements.

[aristath]

The Query block should be entirely agnostic regarding formatting. Formatting should come from individual blocks (like "Latest Posts") or other containing elements.

Does that imply that the query block will be "hidden", and users will be interacting with it via "proxy" blocks (like latest-posts)?
If not, then it should at least allow changing the elements used - not necessarily in the UI but in code.

[mtias]

My point is the query block itself shouldn't have markup.

[mapk]

@aristath thanks for doing some competitive analysis to spark inspiration. I really appreciate that.

In regards to "Format" and switching out different layouts for the Query block, I've created an issue here: #25750

I recently explored using the Transform Tool to help surface these patterns. Please drop some feedback there when you can. :)

[aristath]

In regards to "Format" and switching out different layouts for the Query block, I've created an issue here: #25750

The format here is not so much a visual format as it is a structural format.
I suppose a list format could be achieved using nested group blocks and defining them as ul li using tagName in the groups... but would be a weird implementation
Posts inside the query will sometimes need to be <div> (what we currently have), but as a rule they should either be <li> elements inside a <ul>, or <article> elements.

[ntsekouras]

The Query block should be entirely agnostic regarding formatting. Formatting should come from individual blocks (like "Latest Posts") or other containing elements.
My point is the query block itself shouldn't have markup.

I thought just a div should be there so as to be able to add the sole display option of Query block for switching to grid/list. Without that how could we make a grid layout that is going to be definitely needed? Should we rely on placing in another block to achieve that(like Columns)? Wouldn't be the same thing with more steps and nuances?

related comment: #25462 (comment)
--cc @mtias

[aristath]

The way I can make this work right now is by wrapping the query block in a group, then nest all post blocks inside another group, add a custom css class to the group wrapping the query block and then style it.
It's... less than ideal.

[mapk]

I thought just a div should be there so as to be able to add the sole display option of Query block for switching to grid/list.

I agree with this point. 👍 There needs to be a wrapper of sorts that handles the repeating pattern of blocks. Unless of course, we just use a Group block to provide that wrapper.

[mariohamann]

Building on @mapk 's comment #25750 (comment)

(Always thinking from developer's perspective)

Wouldn't it be possible to:

• Create a variation of e. g. the Group-block:
  • Call it e. g. "Slider"
  • Change HTML Output with render_block() to whatever you need
• Create a Variation of Query Loop-Block:
  • Call it e. g. "Slide"
  • Change HTML Output with render_block() to whatever you need
• Create a pattern by...
  • Inserting the needed blocks (e. g. Author Name, etc.)
  • registering the pattern

Of course it would be nice to change directly the Markup of the Query Block – but as far as I understand we can't create variations of it for this porpuse, as they are used for the the parameters like "Latest Posts" etc. But it would be great to make something like the following possible:

Is anything possible like:

if(block_paramater('layout')=='grid'){
   render_block('query'){
      [CHANGES here]
   };  
   render_block('query_loop'){
      [CHANGES here]
   };  
}

of even if(block_style()=='grid')){}?

[gziolo]

@aristath, amazing work doing this exploration. Is there anything actionable here that we should include in the tracking issue #24762? I personally can see two items that stand out:

Format - Has options for list, table, grid etc. This is something that we'll need to have... Semantically sometimes they will need to be lists with proper

• items. Tables can come later, but it's important we have them as lists. Not everything is supposed to be a
  on the web, and most themes (non-FSE themes) print lists on brogrolls 'cause that's what makes sense semantically.

I think @ntsekouras had PR opened that explores grid view in the Query block.

No Results Behavior - This is a great idea and something we'll need.

If there isn't an item filed, we should do it.

Otherwise, it feels like we can close this issue once we create follow-up tasks.

[aristath]

Good point @gziolo. I couldn't locate an issue for the no-results behavior so I created one on #27302

Closing this since all tasks have their separate tickets now 👍