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.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    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:availableTask is available for claiming

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions