Add Terms Query block patterns, nesting, and extensibility features #71596

cr0ybot · 2025-09-10T20:49:08Z

This PR should be considered blocked by #71916, which splits out (and iterates on) the nesting & inheritance features from this PR. Once that is settled, this PR will be refocused on block patterns/variations.

What?

Addresses differences between the Query block's pattern and variation picker and the Terms Query block. This is a continuation of the effort from PR #71528 which was closed because the target branch was merged.

This PR removes variations from the term-template block, adds variations more similar to the query block to the terms-query block, and includes example patterns that can be chosen.

It also attempts to introduce extensibility mechanisms very similar to the core query block, which the pattern picker is a part of, but this has necessitated a refactoring of the query and hierarchical approach to allow only flat results with nesting accomplished via block nesting instead.

Why?

This was discussed in the main PR as one of the issues to address before releasing the terms-query block. Additionally, extensibility is critical for this block to be useful.

How?

Removes variations from the term-template block
Adds variations to the terms-query block that are similar to the query block
Adds an example pattern registration to the terms-query block in order to show the pattern chooser
Reorganizes the terms-query edit component into separate files
Removes the hierarchical query argument
Implements inheritance from block context, post context, and taxonomy archive template context

Testing Instructions

Edit a page or template
Insert the Terms Query block
Confirm that you are presented with the option to choose a pattern or start blank
Confirm that a pattern is available and selecting it loads the pattern into the editor
Repeat #3 and confirm that choosing "start blank" presents the option to select from a few variations
Confirm that choosing a variation loads the variation into the editor

Testing Instructions for Keyboard

All UI patterns are copied from the query block and should work the same

The initial placeholder for selecting between "choose" and "start blank" should be navigable by tab and arrow keys and selectable with space or enter
The pattern modal should be navigable in the same way and dismissable with escape
The variation picker should be navigable in the same way

Screenshots or screencast

Before	After

Additional Screenshots:

I am open to any feedback, and in particular am looking for thoughts about default patterns and variations.

github-actions · 2025-09-10T20:49:20Z

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Co-authored-by: cr0ybot <[email protected]>
Co-authored-by: mikachan <[email protected]>
Co-authored-by: kmanijak <[email protected]>
Co-authored-by: skorasaurus <[email protected]>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

mikachan · 2025-09-11T16:25:44Z

I've pushed a potential idea for addressing what we were discussing in this comment. I've added a new binding for the term name and link combined. Let me know what you think, feel free to revert/change!

cr0ybot · 2025-09-11T18:20:09Z

I've pushed a potential idea for addressing what we were discussing in this comment. I've added a new binding for the term name and link combined. Let me know what you think, feel free to revert/change!

Hm, this seems dangerous. It works for a paragraph binding, but if this were to be mistakenly used in a button block with a link the HTML would be invalid.

mikachan · 2025-09-12T17:33:13Z

It works for a paragraph binding, but if this were to be mistakenly used in a button block with a link the HTML would be invalid.

Oh yeah, true. I've tried adding a new boolean property to the block bindings, markup, and then only allowing this to be applied to content attributes. Do you think something like this would work?

cr0ybot · 2025-09-13T23:38:11Z

@mikachan I think we would need to check for the paragraph block as well to be safest, since other blocks may include a content attribute and I think block bindings are in the process of being opened up to other attributes via filters.

Edit: This is a bit thorny, ideally we should have the same check on the client side but as far as I can tell filtering by attribute name doesn't work in the editor because a complete data object is provided per block, not per attribute.

Oh my god I just realized the markup property handles this. I suppose if content is standardized enough to mean "could be markup" then this could work. Feels like this could be debated as its own PR apart from term query patterns though.

cr0ybot · 2025-09-15T13:04:06Z

A few things I'm noticing after some additional testing:

The placeholder gets stuck in the template editor because I've got some code attempting to account for inheritance that isn't currently compatible with the base block
There is no equivalent function to the query block's build_query_vars_from_query_block() or the query_loop_block_query_vars filter, so extending the query is currently impossible

I'd like to take care of both in this PR but am open to being told that it's getting out of scope, but my primary mission contributing to this block is extensibility.

mikachan · 2025-09-16T09:24:48Z

Feels like this could be debated as its own PR apart from term query patterns though.

Yeah, definitely. It got more complicated quickly (as most things do 😄). We can revert my attribute binding changes and move them to their own PR.

I'd like to take care of both in this PR but am open to being told that it's getting out of scope, but my primary mission contributing to this block is extensibility.

I think the extensibility of this block is very important, so definitely happy for it to be prioritised. I think it's also fine for them to be worked on in this PR. If it starts to feel like there are too many changes, we can always split the work up, but the first point you mention sounds like it should be included in this PR anyway.

mikachan · 2025-09-16T14:53:33Z

I removed the No Core Sync Required label, my mistake, I didn't think we needed to sync anything, but we will need a Core backport PR as we're adding this file: lib/compat/wordpress-6.9/terms-query-block-patterns.php. @cr0ybot Let me know if you need any help with this.

cr0ybot · 2025-09-21T20:32:28Z

There is no equivalent function to the query block's build_query_vars_from_query_block() or the query_loop_block_query_vars filter, so extending the query is currently impossible

This is going to be more complicated than the query block. I've consolidated into a single WP_Term_Query with filterable args, but the results on the front end for hierarchical terms are not quite working the way they seem like they should. You can see the discrepancy right away in the editor vs front end for perPage=10:

Editor	Front End

This is because WP_Term_Query is a little weird with limits, and is actually querying ALL terms and slicing the array. In this case, terms are ordered by name, so the terms that end up in the results array without their own parent also present just get left out.

Therefore, I admit that separate queries for child terms is actually preferable. However, I'd like to propose a different approach instead of the one currently in use: nested Terms Query blocks. We remove the hierarchical option entirely and instead allow nested blocks to inherit the current term_id of the current block context for use as the parent in the query.

This nested approach feels like it meshes well with the block editor ethos, allowing more control over the presentation of child terms from within the editor. It also follows more closely with the Query block, which does not have a hierarchical option even though some post types are hierarchical. The biggest drawback that I can see is that it wouldn't allow for displaying a taxonomy's full hierarchy in one go. However, I'm wondering if this block would really need to be used in that manner, since the Category List block already exists for this use case.

I am going to proceed with this approach and update the patterns accordingly.

…setting

This reverts commit a52096b.

cr0ybot · 2025-09-24T03:50:01Z

@skorasaurus @mikachan I believe this is ready for review again. Inheritance should work for nested within other terms query blocks, nested in a query for a post's terms, and on a taxonomy template archive. One nested example is available as the "Category Children" pattern. The query is extensible via similar means to the query block with the terms_query_block_query_vars filter and rest_{$this->taxonomy}_query.

I apologize that there are so many changes in this PR. I did refrain from implementing a few things like allowedControls, which is also part of extensibility, that can be done as a followup.

cr0ybot · 2025-09-24T03:52:24Z

packages/editor/src/bindings/term-data.js

 		id: {
 			label: __( 'Term ID' ),
-			value: idValue,
+			value: `${ idValue }`,


This fixed an error I was getting in the editor when using the term id binding for button text. Coercing to a string is probably not ideal in all cases though.

cr0ybot · 2025-09-24T03:54:56Z

packages/block-library/src/terms-query/index.php

+	$content = ( new WP_Block( $block->parsed_block ) )->render( array( 'dynamic' => false ) );
+	remove_filter( 'render_block_context', $filter_block_context, 1 );
+
+	return $content;


We don't need to render the container tag here since it's part of the static saved content in save.js.

cr0ybot · 2025-09-24T12:43:57Z

packages/block-library/src/terms-query/index.php

+	if ( $inherit ) {
+		if ( isset( $block->context['termQuery'] ) ) {
+			$query_context['taxonomy'] = $block->context['termQuery']['taxonomy'] ?? $query_context['taxonomy'] ?? 'category';
+		}
+		if ( isset( $block->context['termId'] ) ) {
+			$query_context['parent'] = $block->context['termId'] ?? $query_context['parent'] ?? 0;
+		}
+	}
+
+	$filter_block_context = static function ( $context ) use ( $query_context ) {
+		$context['termQuery'] = $query_context;
+		return $context;
+	};
+
+	// Use an early priority to so that other 'render_block_context' filters have access to the values.
+	add_filter( 'render_block_context', $filter_block_context, 1 );
+	$content = ( new WP_Block( $block->parsed_block ) )->render( array( 'dynamic' => false ) );
+	remove_filter( 'render_block_context', $filter_block_context, 1 );


I introduced another layer of filtering block context so that the main block can handle termQuery inheritance. Otherwise, the template block only sees the termQuery context from it's container terms query block and not the parent terms query block in a nested scenario.

cr0ybot · 2025-09-24T12:53:47Z

lib/compat/wordpress-6.9/terms-query-block-patterns.php

+					<!-- wp:buttons -->
+					<div class="wp-block-buttons">
+					<!-- wp:button {"metadata":{"bindings":{"url":{"source":"core/term-data","args":{"key":"link"}},"text":{"source":"core/term-data","args":{"key":"name"}}}}} -->
+					<div class="wp-block-button"><a class="wp-block-button__link wp-element-button">' . _x( 'Tag', 'Block pattern button text' ) . '</a></div>


This and other default button text were added because these buttons were not rendering without it. Not sure if this is an upstream issue with the button block or an issue with this PR. It does look like the button block is explicitly hidden if there is no set text content.

cr0ybot · 2025-09-24T12:55:26Z

packages/block-library/src/term-template/block.json

-	"attributes": {
-		"namespace": {
-			"type": "string"
-		}
-	},


The namespace attribute is only needed on the block that provides the query args for plugins to hook into.

cr0ybot · 2025-09-24T14:31:39Z

@fabiankaegy could use your eyes on this one if you have any time to spare.

cr0ybot · 2025-09-24T14:34:03Z

packages/block-library/src/term-template/index.php

-
-	if ( empty( $query_block_context['termQuery'] ) ) {
-		return '';
+	$query_args = gutenberg_build_query_vars_from_terms_query_block( $block );


Any advice about how this is supposed to be handled? Getting a PHPCS error:

It's not allowed to call the "gutenberg_build_query_vars_from_terms_query_block()" function as its name matches the forbidden pattern: "/^[Gg]utenberg.*$/".

I think this error means that we can't prefix the function name with gutenberg, so hopefully this error can be fixed by renaming the function to build_query_vars_from_terms_query_block.

@mikachan I tried that and it failed, so not sure how to update the PR to fix this.

Ah, so the check failed again even when you renamed the function? Do you know if you got the same error? I seem to be able to rename it locally on this branch OK, I can push that change and try it if you like, but I imagine it'll fail the check again if you already tried pushing this change.

Sorry I misunderstood and renamed it where called instead of renaming the function. You can push the change if you'd like, I've just pushed it in my other PR #71916 so we'll see if that worked.

kmanijak

Hi @cr0ybot, thanks for this PR, especially about thinking of extensibility aspects that I really appreciate but also include some changes that I'm not a fan of.

Great things:

make context/query filterable
I love block bindings allowing to have a link to specific taxonomy!
moving variation to Terms Query

Things to address:

from my POV it has to be more flexible and work with custom taxonomies and custom templates. I'm speaking from WooCommerce perspective and will give WooCommerce examples:
- currently Terms Query breaks in editor with custom templates (e.g. in context of WooCommerce templates like Products by Categories/Tags but also Product Catalog or Single Product)
- "Default" Query Type doesn't work well with custom taxonomies (e.g Product Categories or Tags from WooCommerce)
- Terms Query works well with those use cases on trunk

Things to discuss/consider:

I was never a fan of "Query Type" (former "Inherit query from template") and I will strongly advocate for more explicit options addressing explicit use cases but that's a subject to discuss.
I'm on the fence with Query Terms nesting... I must admit I initially didn't like it at all 😅 But as I played with child terms it makes more sense. I'm still thinking about it. But if we go this way, I'd hide most of the controls here (especially Query Type, Taxonomy) and only leave those that makes sense like "Show empty". They create confusion and I think block needs to make some decisions for users and hide complexity from them. What do you think? We can easily detect if block has Terms Query descendant.
What happens to Term Count? Sorry if I missed that in the comments.

Happy to discuss this further! 🙌

kmanijak · 2025-09-24T11:54:41Z

packages/block-library/src/terms-query/edit/inspector-controls/order-controls.js

+		label: __( 'Most used' ),
+		value: 'count/desc',
+	},
+	{
+		label: __( 'Least used' ),
+		value: 'count/asc',
+	},


I'm not convinced to "Most/Least used" labels. They make me think of "popularity" and not necessarily count, especially that we don't know what taxonomy may represent. But I may be biased as I'm not a native English speaker.

kmanijak · 2025-09-24T14:02:54Z

packages/block-library/src/terms-query/edit/inspector-controls/inherit-control.js

To be honest, former "Inherit Query from Template" and current "Query Type" controls are one of the most confusing ones I know.

It is confusing in Query Loop and I think it's even more confusing in Terms Query it's since:

There's no global/default query to inherit from

Inheritance order is strict here and I feel the "post content" can be error prone since postId is pretty commonly provided context that may easily lead to unexpected result.

// Inheritance order: block context, post context, taxonomy archive context.

I would honestly love more explicit options like a radio controls we had addressing specific use cases rather than Default vs Custom Query Type option.

In addition, "Default" option doesn't make much sense in many contexts in Editor, e.g in posts. I don't think we should put a responsibility of knowing how to set up a block to a user but rather do it for them. So at least the option should be hidden if not applicable but I'm personally against having an option in current shape.

kmanijak · 2025-09-24T14:09:18Z

packages/block-library/src/term-template/utils.js

+	}
+	isSingular = singularTemplates.includes( templateType );
+
+	return { isSingular, templateType, templateQuery };


What do we need isSingular for? It's not used anywhere.

Thanks, I've removed it.

kmanijak · 2025-09-24T14:22:52Z

packages/block-library/src/term-template/utils.js

+	const templateTypeFromSlug = templateSlug.includes( '-' )
+		? templateSlug.split( '-', 1 )[ 0 ]
+		: templateSlug;
+	const queryFromTemplateSlug = templateSlug.includes( '-' )
+		? templateSlug.split( '-' ).slice( 1 ).join( '-' )
+		: '';
+	if ( queryFromTemplateSlug ) {
+		templateType = templateTypeFromSlug;
+		templateQuery = queryFromTemplateSlug;
+	}


I don't think this is generic enough as it assumes specific template slugs structure so it breaks on custom templates like this:

For example Woo has the following:

products by category: taxonomy-product_cat

for specific category: taxonomy-product_cat-accessories

products by tag: taxonomy-product_tag

for specific tag: taxonomy-product_tag-red

I think we need to make it much more generic and maybe rely on templateSlug.includes( taxonomy ) where taxonomy is the one chosen in Terms Query block.

@kmanijak Thanks for catching this. The function does work, I just used the wrong value for the taxonomy slug. PR has been updated.

packages/block-library/src/terms-query/index.php

kmanijak · 2025-09-24T14:31:55Z

packages/block-library/src/terms-query/edit/terms-query-placeholder.js

+			<BlockControls>
+				<TermsQueryToolbar
+					clientId={ clientId }
+					attributes={ attributes }
+					hasInnerBlocks={ false }
+				/>
+			</BlockControls>


What about NOT rendering this at all while in placeholder. User has already a choice so there's no need to display "Choose Pattern" button that does the same thing as "Choose" button.

kmanijak · 2025-09-24T14:36:56Z

packages/block-library/src/terms-query/edit/terms-query-placeholder.js

+				{ !! hasPatterns && ! isSmallContainer && (
+					<Button
+						__next40pxDefaultSize
+						variant="primary"
+						onClick={ openPatternSelectionModal }
+					>
+						{ __( 'Choose' ) }
+					</Button>
+				) }
+				{ ! isSmallContainer && (
+					<Button
+						__next40pxDefaultSize
+						variant="secondary"
+						onClick={ () => {
+							setIsStartingBlank( true );
+						} }
+					>
+						{ __( 'Start blank' ) }
+					</Button>


To be honest, I find this choice redundant in the Query Loop and here as well. "Choose" allow to choose pattern and more advanced use cases but "Start Blank" doesn't start blank but gives you another choice of "simple" patterns.

This is general comment that I'd rather put "Start Blank" options as first options in pattern selection modal since I don't see much value in giving users this choice.

Yea, the wording "Start blank" feels like a vestige, not sure what would be better since I don't really think that actually starting blank is a good option. The difference is the choice between patterns (which can be supplemented by the pattern library) vs built-in simple variations. Maybe "Start simple"?

Agreed! I like "Start simple" instead of "Start blank". We could open a follow-up to make the same change to the Query Loop block.

kmanijak · 2025-09-24T14:41:18Z

packages/block-library/src/terms-query/edit/terms-query-content.js

+	// Maybe inherit taxonomy from parent query.
+	const taxonomyInherited = inherit && !! queryContext;
+	const taxonomy = taxonomyInherited
+		? contextTaxonomy ?? queryContextTaxonomy ?? initialTaxonomy
+		: initialTaxonomy;
+
+	// Maybe inherit parent from parent query.
+	const parentInherited = inherit && !! termIdContext;
+	const parent = parentInherited ? termIdContext : initialParent || 0;


Could you explain that logic, what are the use cases here? 😅 Why isn't taxonomy deterministic?

Mainly because taxonomy currently defaults to category. If it defaulted to an empty string maybe this could be simplified. This was done to attempt to automatically inherit the query if a terms query block is inserted within another.

Co-authored-by: Karol Manijak <[email protected]>

cr0ybot · 2025-09-24T15:28:07Z

@kmanijak Thanks for taking a look!

from my POV it has to be more flexible and work with custom taxonomies and custom templates. I'm speaking from WooCommerce perspective and will give WooCommerce examples:

currently Terms Query breaks in editor with custom templates (e.g. in context of WooCommerce templates like Products by Categories/Tags but also Product Catalog or Single Product)

"Default" Query Type doesn't work well with custom taxonomies (e.g Product Categories or Tags from WooCommerce)

Terms Query works well with those use cases on trunk

Definitely think you've found some bugs if it's not working for custom taxonomies or templates. I will investigate.

Things to discuss/consider:

I was never a fan of "Query Type" (former "Inherit query from template") and I will strongly advocate for more explicit options addressing explicit use cases but that's a subject to discuss.

I don't disagree with you, but I strongly believe that the two query blocks should work similarly, including controls. Since this PR doesn't aim to make changes to the Query Loop block, I've opted to use similar controls and wording where possible. I would be in favor of a separate PR that changes controls/wording in both blocks simultaneously.

I'm on the fence with Query Terms nesting... I must admit I initially didn't like it at all 😅 But as I played with child terms it makes more sense. I'm still thinking about it. But if we go this way, I'd hide most of the controls here (especially Query Type, Taxonomy) and only leave those that makes sense like "Show empty". They create confusion and I think block needs to make some decisions for users and hide complexity from them. What do you think? We can easily detect if block has Terms Query descendant.

I stopped short of implementing allowedControls because this PR was already getting wildly out of scope. This should definitely be done in a followup PR.

What happens to Term Count? Sorry if I missed that in the comments.

I'm not sure I understand the question. The count can be applied via block bindings, but I'm also advocating for a new Term Title block that optionally includes the count.

kmanijak · 2025-09-24T16:09:28Z

I don't disagree with you, but I strongly believe that the two query blocks should work similarly, including controls. Since this PR doesn't aim to make changes to the Query Loop block, I've opted to use similar controls and wording where possible. I would be in favor of a separate PR that changes controls/wording in both blocks simultaneously.

I see your point but I'm not convinced they necessarily have to have the same controls especially that "Query Type" is contextual and it makes more sense in Query Loop than in this block. While obviously they're very similar they also serve a different purpose and hence I think it's ok (or even expected) to have some differences that makes the use easier in this specific context.

"Query Type" is already a result of attempt to improve it and... there was no better idea than this 😆 but control is partially enforced by technical aspect (there is global WP_Query) while we don't have to make the same ~~mistake~~ decision here 😄 What I worry about is if we don't find a better alternative that would address both blocks needs and we stay with this.

What about we display different option depending on the context. If we could determine the "inherit type" (from template, from post) in the Editor we could actually give more meaningful option to choose from, e.g. in taxonomy template: Query Type: From the template | Custom etc.

I stopped short of implementing allowedControls because this PR was already getting wildly out of scope. This should definitely be done in a followup PR.

I get it. I know I'm late to the party but any chance this PR could be split into smaller chunks? There are some aspects that are probably good to go now while we could iterate on others like this one. I know we can always followup though.

What happens to Term Count? Sorry if I missed that in the comments.
I'm not sure I understand the question. The count can be applied via block bindings, but I'm also advocating for a new Term Title block that optionally includes the count.

Ah, my bad, I was asking about Term Count block not available but yeah, it was rather dummy question 😅 thanks for answering! And yeah, I saw discussion about dedicated block(s) instead of block bindings. 🙌

cr0ybot · 2025-09-24T16:44:55Z

What about we display different option depending on the context. If we could determine the "inherit type" (from template, from post) in the Editor we could actually give more meaningful option to choose from, e.g. in taxonomy template: Query Type: From the template | Custom etc.

@kmanijak You're definitely right about this. Right now there is a static explanation for default: "Display a list of terms based on the current template or term.", which I did tailor a bit for this block. We might be able to make this more contextual.

I get it. I know I'm late to the party but any chance this PR could be split into smaller chunks?

😅 If that's what is desired here I can start over again...

mikachan · 2025-09-25T17:23:15Z

I'd really appreciate it if this PR could be broken down into smaller changes; it'd be easier to review and land 🙇 But I also appreciate being able to test all of these changes together. Is it possible to split some of the changes out on their own, without there being too much interdependency?

cr0ybot · 2025-09-25T22:23:35Z

@mikachan I think that the change to nesting & inheritance could be split out. I think this PR that adds patterns would have to be considered blocked because there was some organizational shuffling with the higher complexity of the edit component, plus some incompatibilities in the attributes and of course the nesting. I'll get started on that other PR hopefully tonight, and I'll probably open a separate issue for it as well.

cr0ybot · 2025-09-25T23:02:16Z

Issue created for nesting & inheritance: #71911, accompanying PR: #71916

Also created an issue for the Term Title block: #71912

cr0ybot · 2025-10-09T12:33:04Z

Closing in favor of smaller PRs, starting with #72197.

cr0ybot requested review from ajitbohra, fabiankaegy, juanmaguitar and spacedmonkey as code owners September 10, 2025 20:49

cr0ybot mentioned this pull request Sep 10, 2025

Term Query Loop Block #49094

Closed

15 tasks

t-hamano added [Type] Enhancement A suggestion for improvement. [Block] Terms Query Affects the Terms Query Block labels Sep 11, 2025

mikachan added the No Core Sync Required Indicates that any changes do not need to be synced to WordPress Core label Sep 11, 2025

mikachan self-requested a review September 11, 2025 10:31

mikachan requested a review from tellthemachines as a code owner September 12, 2025 16:05

mikachan removed the No Core Sync Required Indicates that any changes do not need to be synced to WordPress Core label Sep 16, 2025

mikachan mentioned this pull request Sep 16, 2025

Data Bindings: Update terms data with markup content type #71702

Closed

cr0ybot mentioned this pull request Sep 21, 2025

Add Terms Query block #70720

Merged

cr0ybot added 8 commits September 21, 2025 15:33

add termQuery as context source to detect inheritance

a9a8e54

add variations and placeholder pattern icons

c2d5f91

move edit components

90c2172

remove default category taxonomy

2491566

placeholder with taxonomy/variation/pattern selector

32c36fb

add button to toolbar for choosing a different pattern after initial …

323f155

…setting

prune utils, update useBlockNameForPatterns from query block

8cd4f6e

Revert "remove default category taxonomy"

8a9d27a

This reverts commit a52096b.

cr0ybot commented Sep 24, 2025

View reviewed changes

cr0ybot changed the title ~~Add Terms Query block patterns (take 2)~~ Add Terms Query block patterns, nesting, and extensibility features Sep 24, 2025

cr0ybot commented Sep 24, 2025

View reviewed changes

kmanijak reviewed Sep 24, 2025

View reviewed changes

fix typo

e2e1923

Co-authored-by: Karol Manijak <[email protected]>

cr0ybot added 3 commits September 24, 2025 12:16

fix site editor template inheritance

a0fcb26

ensure all buttons in variations have default text

a1dbee0

remove unused isSingular value

52dcb7e

This was referenced Sep 25, 2025

Terms Query block: nesting & inheritance #71911

Open

Term Name block #71912

Closed

cr0ybot added a commit to cr0ybot/gutenberg that referenced this pull request Sep 26, 2025

nesting & inheritance features split out from WordPress#71596

c18d62c

cr0ybot mentioned this pull request Sep 26, 2025

Update Terms Query block to support nesting & inheritance #71916

Closed

kmanijak mentioned this pull request Sep 29, 2025

Terms Count block (inner block of Terms Query) #71954

Closed

cr0ybot mentioned this pull request Oct 7, 2025

Terms Query: simplify controls and layout #72121

Merged

cr0ybot closed this Oct 9, 2025

This was referenced Oct 13, 2025

Update Terms Query block to inherit from block context #72187

Open

Terms Query: Update inherit control and functionality #72313

Merged

Add Terms Query block patterns, nesting, and extensibility features #71596

Add Terms Query block patterns, nesting, and extensibility features #71596

Uh oh!

Conversation

cr0ybot commented Sep 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What?

Why?

How?

Testing Instructions

Testing Instructions for Keyboard

Screenshots or screencast

Uh oh!

github-actions bot commented Sep 10, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

mikachan commented Sep 11, 2025

Uh oh!

cr0ybot commented Sep 11, 2025

Uh oh!

mikachan commented Sep 12, 2025

Uh oh!

cr0ybot commented Sep 13, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

cr0ybot commented Sep 15, 2025

Uh oh!

mikachan commented Sep 16, 2025

Uh oh!

mikachan commented Sep 16, 2025

Uh oh!

cr0ybot commented Sep 21, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

cr0ybot commented Sep 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

cr0ybot commented Sep 24, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kmanijak left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

cr0ybot commented Sep 10, 2025 •

edited

Loading

github-actions bot commented Sep 10, 2025 •

edited

Loading

cr0ybot commented Sep 13, 2025 •

edited

Loading

cr0ybot commented Sep 21, 2025 •

edited

Loading

cr0ybot commented Sep 24, 2025 •

edited

Loading

cr0ybot commented Sep 24, 2025 •

edited

Loading

cr0ybot commented Sep 25, 2025 •

edited

Loading

cr0ybot commented Sep 25, 2025 •

edited

Loading