Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

perf: Avoid eager Gutenberg work on ordinary admin screens

Aperta
  • Qualcosa non va?
#1,720 15 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@superdav42 ci sta già lavorando.

Dal 13/8/2026.

  • #1724 di @superdav42 — aperta

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
35/100
Tipo di issue
Refactoring
Chiarezza
Abbastanza chiara
Stato di attività
Ferma
Stack tecnologico
php
Ambito
backend, performance, testing

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

enhancement hold-for-review origin:worker source:ci-feedback status:available

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 #1724 open until that retry is impossible.
Lingua principale
PHP
Stelle
218
Fork
87
Merge medio
1g 8h
PR unite (30g)
82

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di Ultimate-Multisite/ultimate-multisite

Tutte le issue di Ultimate-Multisite/ultimate-multisite

Issue simili

Altre issue su PHP

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.