Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

perf: Avoid eager Gutenberg work on ordinary admin screens

オープン
  • 何か問題がありますか？
#1,720 コメント 15 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

@superdav42 がすでに取り組んでいます。

2026年8月13日 から。

  • #1724 @superdav42 による — オープン

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
35/100
issue の種類
リファクタリング
明瞭さ
おおむね明確
活発さ
停滞
技術スタック
php
領域
backend, performance, testing

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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.
主要言語
PHP
スター
218
フォーク
87
平均マージ
1日 7時間
マージ済み PR（30日）
85

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

Ultimate-Multisite/ultimate-multisite のほかの issue

Ultimate-Multisite/ultimate-multisite の issue をすべて見る

似ている issue

PHP の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。