Patterns are proving to be exceptionally useful, but there is some confusing, bug-like behavior with the core/query
Query Loop block where patterns assigned to newly inserted blocks discard the pattern's query and fallback to the block's defaults. (as of March 2025).
-
Insert a Query Loop block, click Choose, select pattern.
Expectation: Use the specified pattern's query.
Actual: The pattern specified in the query is ignored, query reverts to defaults (postType
,perPage
,order
, etc.) -
Configure a Query Loop Block, then click Replace to choose a pattern
Expectation: Either use the query in the pattern, or offer an option to replace the query?
Actual: Existing query is preserved.
This situation is not clear. Existing behavior makes some sense, since we've already configured the query. However there is still a query in the pattern which is being ignored. -
Insert the pattern from the Patterns insertion interface
Expectation: Use the query from the pattern
Actual: Expectation! This uses the query from the pattern
If the pattern is inserted from the Pattern chooser, it uses the query from the pattern. However if the Query Loop block is inserted first, and the the pattern is choosen from the Choose button modal, the pattern query is discarded and the Block's existing query is used instead.
This is especially confusing if the pattern is chosen when the block is first inserted. Because the pattern selection appears before the block is visible on the page, the default query parameters are not clear to the author. Furthermore, the pattern chooser preview respects the pattern's perPage
query property, but once the pattern is confirmed and the Block is inserted into the page, the number of visible posts will be reset to the block's default query.
If the same pattern is coded as a JavaScript Block Variation, it works correctly. (see attached)
I'm not sure how to proceed with this. The Block Variation is the most seamless solution, also appearing as a transform target for Query Loop Blocks, but is more code to maintain. The core/query
pattern is a nice halfway option, but everyone seems to find the initial chooser behavior confusing. That behavior makes sense after explaining, but still fails if the pattern is dependent on a specific post_type. Hiding the pattern from the Query Block chooser might be the easiest option, but feels terrible since it should work.
I didn't dig into how the Query Loop block handles its iniital state, but the most elegant solution might be to assume the query from the pattern if the block is newly inserted. If the query has been modified, keep the existing query.
Patterns are becoming a significant part of our toolkit. These inconsistancies are an unfortunate speedbump on that roadmap.
This tested on WordPress 6.7.2 with/without Gutenberg 20.5.0.