perf: Avoid eager Gutenberg work on ordinary admin screens

Goal

Avoid building Ultimate Multisite Gutenberg block metadata and loading Gutenberg support assets on ordinary wp-admin screens that are not block editors.

Evidence

On an authenticated subscriber Dashboard request, Block_Editor_Widget_Manager::handle_element() registered blocks for every Ultimate Multisite UI element. register_block() called each element's fields() method to derive attributes.

Three element field definitions synchronously called get_pages():

• inc/ui/class-current-site-element.php
• inc/ui/class-my-sites-element.php
• inc/ui/class-site-actions-element.php

The request trace attributed at least 240 object-cache reads and six SQL queries to those three page-list loads: 120 uncached-ID checks and 120 WP_Post instance reads. None of the resulting page options were used by the WordPress Dashboard.

The same ordinary Dashboard also enqueued wu-gutenberg-support.js, because Gutenberg_Support::add_scripts() runs on every admin_enqueue_scripts event without checking whether the current screen is a block editor.

Implementation context

Primary files:

• inc/builders/block-editor/class-block-editor-widget-manager.php
• inc/compat/class-gutenberg-support.php
• inc/ui/class-current-site-element.php
• inc/ui/class-my-sites-element.php
• inc/ui/class-site-actions-element.php

Recommended approach:

1. Enqueue Gutenberg support assets only when get_current_screen()->is_block_editor() is true, while preserving any explicitly supported site editor/widget editor contexts.
2. Avoid evaluating expensive field options merely to derive server-side block attribute types.
3. Make the shared page-option list lazy and request-memoized so the three elements do not independently query and hydrate the same pages.
4. Preserve frontend dynamic-block registration and REST block-editor previews.

Tests

• Ordinary Dashboard/Profile screens do not enqueue wu-gutenberg-support.
• Block editor screens still enqueue and localize the script.
• Registering block attributes does not execute page-option providers.
• Consolidating editor settings executes a lazy page provider once per request.
• Dynamic blocks still render on frontend and REST preview requests.

Verification

vendor/bin/phpunit --filter Block_Editor_Widget_Manager_Test
vendor/bin/phpcs inc/builders/block-editor/class-block-editor-widget-manager.php inc/compat/class-gutenberg-support.php inc/ui/class-current-site-element.php inc/ui/class-my-sites-element.php inc/ui/class-site-actions-element.php
vendor/bin/phpstan analyse

CI Repair Feedback (from PR #1724)

The previous worker's PR #1724 had terminal failed CI checks. A head-bound
finalizer is routing this issue for redispatch. The next worker should address these failures.

Terminal failed checks

• PHP 8.4: failure — check URL
• PHP 8.2: failure — check URL
• PHP 8.5: failure — check URL

Worker guidance

1. Recover the previous PR branch/commits and continue that work; do not restart from scratch.
2. Read every terminal check URL above and preserve the accumulated evidence.
3. Rebase the recovered work onto current origin/main, then fix the code rather than weakening CI.
4. Run every listed local check and create the replacement PR from the recovered branch.

Routed by deterministic merge pass (pulse-merge.sh).

In-place repair fallback

• Reason: the bounded PR-branch repair session exhausted its retry budget
• Retry: re-run the deterministic merge pass after restoring access to branch feature/auto-20260813-153304-gh1720; keep PR #1724 open until that retry is impossible.

Recover PR #1724 and read the five listed implementation files, then inspect the terminal PHP 8.2, 8.4, and 8.5 failures before rebasing. Run the listed PHPUnit, PHPCS, and PHPStan checks. Done means ordinary admin screens avoid Gutenberg work, editor and preview paths remain functional, and the page provider is lazy and request-memoized.