Plugin: Bump minimum required WordPress version to 7.0

[jeryj]

Important

Do not merge as-is. This PR temporarily comments out the previous major version exclusion in unit-test.yml so CI validates against WordPress 7.0, the new minimum. Restore that exclusion before merging.

What?

WordPress 7.1 was released on Aug 19, 2026. This brings the plugin's version metadata in line with it, following the same steps as #74218 and #79196:

• readme.txt — Tested up to: 7.1
• gutenberg.php — Requires at least: 7.0 and GUTENBERG_MINIMUM_WP_VERSION. The plugin only supports the last two major WP versions (plus trunk), per the performance doc ("Gutenberg supports only two WP versions") and the rationale given in Plugin: Bump minimum required WordPress version to 6.7 #70023, Plugin: Bump minimum required WordPress version to 6.8 #74218 and Plugin: Bump minimum required WordPress version to 6.9 #79196
• tools/release/resolve-performance-branches.mjs — the performance reference commit, which the docs require to move whenever Tested up to changes
• removes lib/compat/wordpress-7.0/, now that WordPress 7.0 supplies its contents
• adds a pre-RC checklist item to .github/ISSUE_TEMPLATE/New_release.md, since this is the tenth WordPress major in a row where the bump landed after the release rather than before it

Why?

Two effects while Tested up to lagged behind the release:

1. People on WP 7.1 see "Untested with your version of WordPress" when installing the plugin. 23.8.0 and 23.9.0 both shipped this way.
2. Less visibly, the performance job derives its base WordPress version from the Tested up to flag, so trunk benchmarks have been running against WP 7.0 rather than 7.1. This is the same thing that happened for 6.1, and was called out in the What's New in Gutenberg 14.5 post.

How?

Every file in lib/compat/wordpress-7.0/ was one of two things, both made redundant by the new minimum:

• Dead behind a guard. class-wp-connector-registry.php and class-wp-rest-icons-controller.php wrapped their entire bodies in class_exists(), and WordPress 7.0 requires both classes in wp-settings.php (lines 297 and 358) before plugins are included (line 574), so the guards could never be true.
• The plugin's copy of a core implementation, swapped in with remove_action()/remove_filter(). Verified against the 7.0 and 7.1 sources: _wp_enqueue_auto_register_blocks, wp_mark_auto_generate_control_attributes, wp_admin_bar_command_palette_menu, _wp_connectors_init, _wp_connectors_rest_settings_dispatch, _wp_register_default_connector_settings, wp_print_font_faces, resolve_pattern_blocks and load_script_module_textdomain all exist in 7.0, and the plugin's copies differ from core's by 1–12 lines. This is the same shape as the wordpress-6.9/ files removed in Plugin: Bump minimum required WordPress version to 6.9 #79196 — command-palette.php there did exactly this and was deleted.

The three REST controller subclasses are redundant for the same reason. The revisions controller's docblock says it exists to "use rest_is_field_included() instead of in_array() … avoiding expensive rendering when only raw data is needed"; core 7.0 does that, at the same line numbers. The block-patterns and templates subclasses both just call resolve_pattern_blocks, which core 7.0's controllers already do.

Three pieces had no core equivalent and were moved rather than deleted, as #79196 did for the attachments controller:

Moved	To	Why
gutenberg_get_allowed_icon_svg_tags()	lib/class-wp-icons-registry-gutenberg.php	back where it started — see below
Fonts + Connectors admin menu registration	lib/compat/plugin/	they register pages generated by the routes build (routes/fonts-home, routes/font-list), so they are plugin-only, not compat

gutenberg_get_allowed_icon_svg_tags() is a return, not a new home. It began in lib/class-wp-icons-registry-gutenberg.php and was moved into the compat file on 2026-08-21 (d2182e5588d, follow-up to #78808) because the guarded WP 6.9 WP_Icons_Registry needed the same allowlist. With that class gone the subclass is its only consumer again. It has to stay: 99 of the plugin's 341 icon SVGs use stroke attributes after #78808, and core's sanitize_icon_content() allowlist has none — core's own icon set is stroke-free, so this is ahead-of-core work rather than a core bug.

Testing Instructions

1. npm run test:unit:php — 2272 tests, 4709 assertions, no failures. The drop from trunk's 2294/4734 is the three removed test files.
2. npm run test:unit:vitest -- tools/release/test/resolve-performance-branches.js — 20 tests.
3. vendor/bin/phpcs is clean on every changed PHP file.

No test coverage is dropped. Three test files called the removed functions and now call core's equivalents instead — auto-register-test.php (wp_mark_auto_generate_control_attributes), gutenberg-resolve-pattern-blocks.php (resolve_pattern_blocks), and class-resolve-patterns-in-patterns-test.php (whose @covers now names WP_REST_Block_Patterns_Controller; its assertions dispatch against the REST endpoint and pass unchanged against core's controller). packages/e2e-tests/plugins/connectors-empty-state.php now removes core's _wp_connectors_get_connector_script_module_data filter instead of the deleted Gutenberg one.

One assertion changed shape, though not its expected values. class-gutenberg-rest-templates-controller-test.php used assertSame() on the whole response array, which requires identical key order. The date field is not produced by either controller — it is registered by lib/compat/wordpress-7.1/rest-api.php and merged in by add_additional_fields_to_object(), and core lands it in a different position than the removed subclass did. Since a JSON object's key order is not part of the contract, both sides are now ksort()ed before the same strict comparison. The expected keys and values are untouched.

Verified against the new minimum, not just the latest release: pointing wp-env at wordpress-7.0.zip (wp core version → 7.0) and running the full suite gives the same result with no failures.

Important

unit-test.yml excludes the previous major version matrix entry on pull_request events, so CI would not otherwise exercise WordPress 7.0. This PR temporarily comments out that exclusion so CI validates both the latest and previous WordPress release, the same way #79196 did. Revert it before merging.

Decisions

Default was to drop, and keep only what has evidence behind it.

Dropped. gutenberg_block_editor_preload_paths_6_9() — arrived with #67125 (template duplication / active templates), which was reverted twice; #82241 removed the experiment last week but missed this filter. gutenberg_update_tax_query_of_query_loop_block() — hooked to query_loop_block_query_vars, which core applies but attaches nothing to. Neither is referenced or tested.

Kept. The Fonts and Connectors menu registrations: build/routes.php:112,169 hook font-library-wp-admin_init and options-connectors-wp-admin_init, which only fire if those pages are registered — dropping them orphans two built pages and the routes/fonts-home, routes/font-list, routes/connectors-home packages.

Tests removed, not retargeted. Three unit tests covered functions WordPress 7.0 now supplies, and core carries equivalents — tests/phpunit/tests/block-supports/auto-register.php, tests/phpunit/tests/blocks/resolvePatternBlocks.php and tests/phpunit/tests/rest-api/wpRestBlockPatternsController.php — so auto-register-test.php, gutenberg-resolve-pattern-blocks.php and class-resolve-patterns-in-patterns-test.php are gone (thanks @t-hamano).

Also from review. The class_exists( '\WordPress\AiClient\AiClient' ) guard around the connectors require is always true now that the minimum is 7.0 — core bundles the library at wp-includes/php-ai-client/ — so it is removed, and the connectors menu guard is narrowed to the render-page check to match the font library page.

Use of AI Tools

Claude Opus, via Claude Code. It researched how previous releases handled a lagging Tested up to value, checked every file in the compat directory against the WordPress 7.0 and 7.1 sources, and drafted the changes and this description. All of it has been reviewed by me.

[github-actions]

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: jeryj <jeryj@git.wordpress.org>
Co-authored-by: Mamaduka <mamaduka@git.wordpress.org>
Co-authored-by: t-hamano <wildworks@git.wordpress.org>
Co-authored-by: ramonjd <ramonopoly@git.wordpress.org>

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

[coderabbitai]

Note

Reviews paused

It looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

• @coderabbitai resume to resume automatic reviews.
• @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

• ▶️ Resume reviews
• 🔍 Trigger review

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Team

Run ID: 8f86e472-3ad8-479e-8bb0-664be838f4e7

📥 Commits

Reviewing files that changed from the base of the PR and between 3348038 and 0f180bc.

📒 Files selected for processing (1)

• .github/workflows/unit-test.yml

Included review availability: Your plan provides up to 8 included reviews per hour; 5 remain after this review.

---

📝 Walkthrough

Walkthrough

The plugin now requires WordPress 7.0, reports testing through WordPress 7.1, removes obsolete WordPress 7.0 compatibility loading, adds plugin-level replacements, updates related tests, enables previous-version pull-request tests, and changes the performance reference commit.

Changes

WordPress compatibility updates

Layer / File(s)	Summary
Update WordPress version requirements gutenberg.php, readme.txt	The plugin metadata and runtime constant change the minimum WordPress version from 6.9 to 7.0. The README changes the tested version from 7.0 to 7.1.
Remove obsolete compatibility loading lib/compat/wordpress-7.0/*, lib/load.php	The loader no longer includes the removed WordPress 7.0 compatibility implementations.
Wire plugin compatibility replacements lib/compat/plugin/*, lib/class-wp-icons-registry-gutenberg.php, lib/load.php, packages/e2e-tests/plugins/connectors-empty-state.php	Plugin-level Connectors, Fonts, preload, and icon SVG compatibility code is added or loaded. The connector empty-state setup removes Core’s connector data filter.
Update compatibility tests phpunit/block-supports/auto-register-test.php, phpunit/blocks/gutenberg-resolve-pattern-blocks.php, phpunit/class-gutenberg-rest-templates-controller-test.php, phpunit/class-resolve-patterns-in-patterns-test.php, .github/workflows/unit-test.yml	Tests use current WordPress function and controller names, resolve patterns through the current function, compare REST template responses without depending on key order, and include the previous WordPress version in pull-request tests.

Performance workflow reference

Layer / File(s)	Summary
Update performance reference commit tools/release/resolve-performance-branches.mjs	The performance workflow reference commit changes to 601575c5de46876fad9c086b9712ed1e69919ec3.

Estimated code review effort: 3 (Moderate) | ~25 minutes

Merge Risk: ⚪ Minimal · up to 0f180

Pull requests now exercise the previous major WordPress version, improving coverage for the updated minimum-version support without an identified merge-blocking risk.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 13 functions across 12 files. (1 skipped: …
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately describes the minimum WordPress version change from 6.9 to 7.0. It does not mention the broader compatibility cleanup, but it clearly identifies a primary change.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch update/bump-tested-to-7.1

---

_{Comment @coderabbitai help to get the list of available commands.}

[Mamaduka]

I think we should bump versions and clean up compat dirs after the release - #79196.

But I can understand if you want to keep this more atomic and just merge the "tested up to" change.

[github-actions]

🤖 PR meta 🤖

📦 Bundle size

Size Change: 0 B

Total Size: 8.06 MB

_{1e0f24b Run}

⚡ Performance

Show the results

Client side metrics exclude the server response time.

front-end-block-theme

Metric	ee2482d	trunk	% Change
timeToFirstByte	55.65 ms +13.03% -2.79%	54.9 ms +5.19% -2.28%	1.37%
largestContentfulPaint	96 ms +6.25% -4.17%	96 ms +4.17% -8.33%	0%
lcpMinusTtfb	37.55 ms +17.31% -9.72%	36.8 ms +17.12% -6.66%	2.04%
wpBeforeTemplate	27.02 ms +18.99% -0.93%	26.78 ms +7.62% -1.83%	0.9%
wpTemplate	23.79 ms +8.74% -1.81%	23.8 ms +4.03% -2.31%	-0.04%
wpTotal	51.55 ms +14.47% -2.54%	51.13 ms +5.38% -2.6%	0.82%
wpMemoryUsage	7.52 MB +0% -0%	7.49 MB +0% -0%	0.35%
wpDbQueries	17 +0% -0%	17 +0% -0%	0%

front-end-classic-theme

Metric	ee2482d	trunk	% Change
timeToFirstByte	40.45 ms +10.88% -1.73%	36.8 ms +11.28% -1.36%	9.92%
largestContentfulPaint	92 ms +4.35% -4.35%	84 ms +9.52% -0%	9.52%
lcpMinusTtfb	51.05 ms +4.41% -5.48%	47.7 ms +4.4% -0.94%	7.02%
wpBeforeTemplate	23.65 ms +8.5% -1.27%	23.57 ms +4.07% -1.36%	0.34%
wpTemplate	13.62 ms +5.29% -0.81%	10.41 ms +4.8% -1.92%	30.84%
wpTotal	37.22 ms +12.41% -1.4%	33.92 ms +11.67% -1.42%	9.73%
wpMemoryUsage	6.00 MB +0% -0%	5.37 MB +0% -0%	11.68%
wpDbQueries	10 +0% -0%	10 +0% -0%	0%

media-processing

Metric	ee2482d	trunk	% Change
mediaProcessingJpeg	416.34 ms +0.37% -2.23%	409.38 ms +1.05% -0.61%	1.7%
mediaProcessingAvif	6207.48 ms +0.14% -0.19%	6176.29 ms +0.2% -0.24%	0.5%
mediaProcessingJpegToAvif	4307.76 ms +0.65% -0.09%	4333.29 ms +0.13% -0.07%	-0.59%

media-upload

Metric	ee2482d	trunk	% Change
jpegUploadProcessing	1432.11 ms +37.07% -1%	1424.67 ms +1.73% -0.55%	0.52%
pngUploadProcessing	213.58 ms +4.11% -3.19%	215.63 ms +4.28% -2.46%	-0.95%
largeJpegUploadProcessing	1416.25 ms +1.03% -0.37%	1432.66 ms +0.25% -0.93%	-1.15%
multipleImageUploadProcessing	1575.42 ms +1.91% -0.21%	1591.16 ms +11.77% -2.22%	-0.99%

post-editor

Metric	ee2482d	trunk	% Change
serverResponse	496.15 ms +4.09% -6.68%	516.06 ms +5.56% -5.83%	-3.86%
firstPaint	242.02 ms +20.73% -14.89%	218.36 ms +29.01% -8.38%	10.84%
domContentLoaded	1272.96 ms +0.41% -0.77%	1262.47 ms +1.73% -1.91%	0.83%
loaded	1274.16 ms +0.41% -0.76%	1263.76 ms +1.74% -1.93%	0.82%
firstContentfulPaint	423.28 ms +1.83% -3.09%	431.33 ms +4.8% -3.06%	-1.87%
firstBlock	3536.5 ms +0.83% -0.73%	3514.06 ms +0.25% -0.95%	0.64%
type	14.01 ms +5.92% -5%	13.31 ms +11.42% -3.76%	5.26%
typeWithoutInspector	13.9 ms +7.77% -9.64%	13.24 ms +3.93% -7.85%	4.98%
typeWithTopToolbar	17.66 ms +4.08% -7.08%	17.47 ms +6.7% -10.02%	1.09%
typeContainer	8.6 ms +10.81% -8.84%	9.08 ms +5.62% -8.92%	-5.29%
focus	73.98 ms +21.8% -6.7%	76.44 ms +4% -11.64%	-3.22%
firstFocus	165.69 ms +0% -0%	166.29 ms +0% -0%	-0.36%
selectAll	612.84 ms +2.26% -1.71%	584.31 ms +1.02% -3.64%	4.88%
listViewOpen	66.47 ms +16.79% -2.27%	67.19 ms +12.56% -7.95%	-1.07%
inserterOpen	21.83 ms +6.41% -7.01%	21.88 ms +6.86% -11.97%	-0.23%
inserterHover	3.75 ms +6.13% -16.8%	3.85 ms +8.57% -21.04%	-2.6%
inserterSearch	8.67 ms +8.19% -5.65%	7.65 ms +9.54% -6.41%	13.33%
loadPatterns	587.45 ms +8.84% -3.83%	616.1 ms +8.86% -6.43%	-4.65%
wpTotal	486.31 ms +4.28% -6.73%	506.12 ms +5.38% -5.95%	-3.91%
wpMemoryUsage	13.05 MB +0% -0%	13.03 MB +0% -0%	0.21%
wpDbQueries	54 +0% -1.85%	53 +1.89% -0%	1.89%

site-editor

Metric	ee2482d	trunk	% Change
serverResponse	415.61 ms +1.39% -0.6%	393.01 ms +7.1% -5.34%	5.75%
firstPaint	247.12 ms +4.95% -8.36%	251.27 ms +3.04% -11.84%	-1.65%
domContentLoaded	1348.67 ms +1.3% -0.85%	1347.43 ms +0.83% -0.97%	0.09%
loaded	1349.93 ms +1.29% -0.86%	1348.66 ms +0.82% -0.97%	0.09%
firstContentfulPaint	434.91 ms +1.64% -3.13%	426.82 ms +2.89% -3.28%	1.9%
firstBlock	4226 ms +0.27% -0.12%	4214.6 ms +0.62% -0.84%	0.27%
type	15.44 ms +10.3% -7.19%	15.66 ms +8.94% -8.88%	-1.4%
navigate	104.06 ms +3.25% -4.75%	101.01 ms +9.65% -0.6%	3.02%
loadPatterns	1397.93 ms +14.04% -6.77%	1422.98 ms +15.99% -9.1%	-1.76%
loadPages	1083.7 ms +0.55% -1.7%	1081.92 ms +0.72% -1.07%	0.16%
wpTotal	405.14 ms +1.42% -0.74%	381.98 ms +7.3% -5.46%	6.06%
wpMemoryUsage	12.00 MB +0% -0%	12.04 MB +0% -0%	-0.32%
wpDbQueries	43 +2.33% -0%	43 +2.33% -0%	0%

_{1e0f24b Run}

🏁 Flaky tests

Show the failures

Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

image inserted via link should appear in the frontend published post content in /test/e2e/specs/editor/blocks/image.spec.js, passed after 1 failed attempt.

Error: apiRequestContext.fetch: socket hang up
Call log:
  - → GET http://localhost:8889/wp-json/wp/v2/media?per_page=100
    - user-agent: Playwright/1.63.0 (x64; ubuntu 24.04) node/24.18 CI/1
    - accept: */*
    - accept-encoding: gzip,deflate,br
    - X-WP-Nonce: 0e773758aa
    - cookie: wordpress_test_cookie=WP%20Cookie%20check; wordpress_logged_in_23778236db82f19306f247e20a353a99=admin%7C1789238875%7C52luTgXUOUP3XIWnozNFlD6UAuBa5tiU2kTPdUeUFYt%7C15c5bbcbfe76803f5b90980edd06fdb5c226e354d8d0e422ed4767cd1b261b8c; wp-settings-time-1=1789066076

    at RequestUtils.rest (/home/runner/work/gutenberg/gutenberg/packages/e2e-test-utils-playwright/src/request-utils/rest.ts:112:39)
    at RequestUtils.listMedia (/home/runner/work/gutenberg/gutenberg/packages/e2e-test-utils-playwright/src/request-utils/media.ts:24:30)
    at RequestUtils.deleteAllMedia (/home/runner/work/gutenberg/gutenberg/packages/e2e-test-utils-playwright/src/request-utils/media.ts:85:27)
    at /home/runner/work/gutenberg/gutenberg/test/e2e/specs/editor/blocks/image.spec.js:24:22

placeholder displays in the site editor even when comments are closed by default in /test/e2e/specs/editor/blocks/post-comments-form.spec.js, passed after 1 failed attempt.

Error: expect(locator).toBeVisible() failed

Locator: locator('[name="editor-canvas"]').contentFrame().locator('role=document[name="Block: Comments Form"i]').locator('form')
Expected: visible
Timeout: 5000ms
Error: element(s) not found

Call log:
  - Expect "toBeVisible" locator('[name="editor-canvas"]').contentFrame().locator('role=document[name="Block: Comments Form"i]').locator('form') with timeout 5000ms
  - waiting for locator('[name="editor-canvas"]').contentFrame().locator('role=document[name="Block: Comments Form"i]').locator('form')

    at /home/runner/work/gutenberg/gutenberg/test/e2e/specs/editor/blocks/post-comments-form.spec.js:44:59

_{1e0f24b Run}

[jeryj]

I think we should bump versions and clean up compat dirs after the release - #79196.

Agreed - working through it with Claude now :)

[jeryj]

@Mamaduka - My agent has been really struggling with this. I went through and verified its thinking and had it update the PR description with the decisions. That said, this is my first time doing one of these version updates, so I'm not very confident that everything is right yet. I'd definitely appreciate a review to see if it's on the right track!

[Mamaduka]

Thanks, @jeryj!

This looks good. I'll do proper testing shortly. Usually, it's better to get more eyes on similar changes.

[Mamaduka]

It looks like we've to keep similar page overrides forever. We should look into streamlining the process. cc @jorgefilipecosta, @youknowriad

[ramonjd]

resolve_pattern_blocks / WP_REST_Block_Patterns_Controller

I tested the patterns functionality on top of 7 and 7.1 (I helped introduced the feature in 7.0) LGTM 🙇🏻

[t-hamano]

Since some tests were modified to use core classes and functions, the resulting tests are copies of the core and appear redundant. Can the following unit tests be completely removed?

• phpunit/class-resolve-patterns-in-patterns-test.php
• phpunit/blocks/gutenberg-resolve-pattern-blocks.php
• phpunit/block-supports/auto-register-test.php

[t-hamano]

This if statement is always true, so it can be removed.

[t-hamano]

Suggested change

	if ( ! class_exists( '\WordPress\AiClient\AiClient' ) || ! function_exists( 'gutenberg_options_connectors_wp_admin_render_page' ) ) {
	return;
	}
	if ( ! function_exists( 'gutenberg_options_connectors_wp_admin_render_page' ) ) {
	return;
	}

If we assume that contributors run a build before launching their local environment, we can remove this entire if statement. This guard is not present on the font library page. In any case, the AiClient check can be removed.

[jeryj]

@t-hamano I was wondering the same thing about removing those tests. I asked Claude about if new development happened on that code, where would it happen? Gutenberg or Core. My agent analyzed that it would happen in Gutenberg. If that's wrong, and development would not happen in Gutenberg, then let's remove the tests.

[t-hamano]

@jeryj Personally, I want to minimize code duplication between the core and Gutenberg as much as possible. The more duplication there is, the harder it is to keep both in sync, and the more likely differences are to arise. While it's possible that new development will happen in Gutenberg first, I believe we can simply add the necessary tests when that occurs.

[jeryj]

@t-hamano sounds good to me! Addressed your feedback in 16704b3.

[t-hamano]

Thanks for the update! I believe the CI error is occurring because the trunk branch is referencing Gutenberg_REST_Templates_Controller_7_0. This should be resolved by merging trunk into this branch and then changing Gutenberg_REST_Templates_Controller_7_0 to WP_REST_Templates_Controller.

--- a/lib/compat/wordpress-7.2/class-gutenberg-rest-templates-controller-7-2.php
+++ b/lib/compat/wordpress-7.2/class-gutenberg-rest-templates-controller-7-2.php
@@ -11,9 +11,9 @@
   * checking that a theme or plugin version of the template exists.
   *
   *
- * @see Gutenberg_REST_Templates_Controller_7_0
+ * @see WP_REST_Templates_Controller
   */
-class Gutenberg_REST_Templates_Controller_7_2 extends Gutenberg_REST_Templates_Controller_7_0 {
+class Gutenberg_REST_Templates_Controller_7_2 extends WP_REST_Templates_Controller {
  	/**
  	 * Prepares a single template output for response.
  	 *

--- a/lib/compat/wordpress-7.2/rest-api.php
+++ b/lib/compat/wordpress-7.2/rest-api.php
@@ -21,8 +21,7 @@
 /**
  * Registers the Templates and Template Parts REST API routes.
  *
- * Runs after the WordPress 7.0 filters of the same shape, so this controller
- * class wins.
+ * Replaces the core controller class so the 7.2 controller is used.
  *
  * @see Gutenberg_REST_Templates_Controller_7_2
  *

[jeryj]

129d271 is green, so I'm going to undo the exclusion in unit-test.yml that made CI validates against WordPress 7.0.

[jeryj]

@t-hamano, @Mamaduka - How is this looking to y'all?

[Mamaduka]

@jeryj, did some smoke testing, and this looks good to me ✅. Happy to approve, but let's wait for Aki when he's online tomorrow, and then we can merge.

[t-hamano]

LGTM! Everything seems to be fine.