Skip to content

perf: Avoid eager Gutenberg work on ordinary admin screens #1720

Description

@superdav42

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

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 perf: defer Gutenberg work outside editors #1724 open until that retry is impossible.

Metadata

Metadata

Assignees

Labels

enhancementNew feature or requesthold-for-revieworigin:workerAuto-created by pulse labelless backfill (t2112)source:ci-feedbackIssue carries CI failure feedback routed from a closed worker PRstatus:in-reviewPR open, awaiting review/merge

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions