Code Quality: Declare the $wpdb global in wp-admin scripts

[robelsust]

✅ Committed in r64046 (fee6a84).

---

Trac ticket: https://core.trac.wordpress.org/ticket/65817

Declares the $wpdb global in five wp-admin scripts where PHPStan reports variable.undefined errors. All five files use $wpdb at file scope after bootstrapping via require admin.php → wp-load.php → wp-settings.php, which sets $GLOBALS['wpdb']. The variables are valid at runtime; the errors are static-analysis artifacts of file-level scoping across require boundaries.

File	$wpdb usages	Count in baseline
network/site-new.php	hide_errors(), show_errors()	2
options.php	get_results() + property access	2
upload.php	get_col() + property access	2
user-edit.php	get_var(), query(), prepare() (×2 blocks)	12
user-new.php	get_var(), prepare()	3

Changes

Each file receives a global $wpdb; declaration with a @global docblock, placed immediately before the first $wpdb usage in scope:

1. src/wp-admin/network/site-new.php: Before $wpdb->hide_errors() (line 143), inside the form submission handler.
2. src/wp-admin/options.php: Before $wpdb->get_results() (line 399), inside the <?php block that renders the options table.
3. src/wp-admin/upload.php: Before $wpdb->get_col() (line 265), inside the delete_all branch of the bulk action handler.
4. src/wp-admin/user-edit.php: Before the email-change confirmation block (line 108), at file scope to cover both $wpdb usage sites (lines 114 and 170).
5. src/wp-admin/user-new.php: Before $wpdb->get_var() (line 243), inside the no-confirmation signup activation branch.

Background

All five files load $wpdb through the standard admin bootstrap: require admin.php → wp-load.php → wp-settings.php, where $GLOBALS['wpdb'] is instantiated. None of these files have ever declared global $wpdb; at file scope, because the variable is already available via $GLOBALS. PHPStan cannot trace globals injected through require, so each usage appears undefined.

The $wpdb usages in these files have been present for many years:

• network/site-new.php: $wpdb->hide_errors() / show_errors() around wpmu_create_blog() since the network admin was introduced.
• options.php: $wpdb->get_results() for the "All Options" screen since the earliest revisions.
• upload.php: $wpdb->get_col() for emptying the media trash, added in r11863.
• user-edit.php: Multisite signup table updates, added in r21923.
• user-new.php: Activation key lookup for no-confirmation signups, added in r21511.

Testing instructions

1. On trunk, npm run typecheck:php reports [OK] No errors, because all five entries are baselined.
2. Remove the five $wpdb entries for these files from tests/phpstan/baselines/variable.undefined.neon without applying the source changes, then run again. PHPStan reports Variable $wpdb might not be defined. in each file.
3. With this branch applied, npm run typecheck:php reports [OK] No errors with all five baseline entries removed and no new errors elsewhere.
4. composer lint is clean on all five changed files.
5. The baseline was regenerated with composer phpstan:baselines -- --identifier=variable.undefined, not edited by hand.

---

Use of AI Tools

AI assistance: Yes
Tool(s): Antigravity IDE
Model(s): Claude Opus 4
Used for: Identifying the five $wpdb entries in the PHPStan baseline, verifying each file's bootstrap chain, and drafting this description. The source changes, baseline regeneration, and verification against PHPStan and PHPCS were reviewed and confirmed by me in a local development environment.

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Core Committers: Use this line as a base for the props when committing in SVN:

Props therssoftware.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[github-actions]

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
  it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

[mukeshpanchal27]

Thanks @robelsust for the PR!

Changes look good to me.