fix: safe mode fatals with an undefined wp_get_current_user()

[TallblokeUK]

Safe mode is currently unusable. Any request carrying ?snippets-safe-mode=1 dies with a fatal, on 3.10.0 and on released 3.10.1. Reported by hannab in this forum thread — they were told to use safe mode to recover, and hit this instead.

The bug

Fatal error: Uncaught Error: Call to undefined function wp_get_current_user()
in wp-includes/capabilities.php:914
#0 .../php/Plugin.php(282): current_user_can('manage_options')
#1 .../php/Integration/Evaluate_Functions.php(51): Code_Snippets\Plugin->current_user_can()

Evaluate_Functions is constructed from Plugin::load_plugin(), which Core/load.php:88 calls at include time. The order in wp-settings.php is:

line	what happens
574	active plugins are included — our constructor runs here
604	require pluggable.php — wp_get_current_user() defined here
622	plugins_loaded fires

So the constructor runs 30 lines before the function it depends on exists. The only reason this is not fatal on every request is the empty() short-circuit on the query var:

return ! empty( $_REQUEST['snippets-safe-mode'] ) && code_snippets()->current_user_can();

Set the query var and the second operand is evaluated, and the request is over.

This matters more than a normal edge case: safe mode is what we tell people to use when a snippet has broken their site, so it fails exactly when it is needed.

The fix

Split the check in two. The constructor tests only for the query var, which reads nothing but the request and is safe at any point. The capability is checked inside the callback, which cannot run before URLs are being generated, long after pluggable functions are available.

Behaviour is unchanged for a user without the capability — the query var is still never added to URLs.

Also included

The two filter callbacks in this same file declared non-nullable scalar parameters:

public function add_safe_mode_query_var( string $url ): string
public function disable_snippet_execution( bool $execute_snippets ): bool

Neither can trust its input, because an earlier callback in the chain may return anything, and on PHP 8 passing null to a non-nullable scalar is a TypeError regardless of strict_types. This is the same defect Sam reported on the forum for screen_settings, fixed in #481, and they suggested auditing the rest. disable_snippet_execution is hooked to code_snippets/execute_snippets, a filter we publish for third parties, and a null there takes down the front end rather than one admin screen.

One remains after this: Snippet_Files::add_settings_fields( array $fields ) on code_snippets_settings_fields. Left out to keep this diff to a single file — happy to follow up.

Testing

4 new tests in Evaluate_Functions_Safe_Mode_Test. All 4 fail on core today: two with Call to undefined method ...::is_safe_mode_query_var_set() and two with the exact TypeErrors above.

Full suite: 161 tests, 0 failures. phpcs clean.

Verified end to end against released 3.10.1 on WP 7.1 / PHP 8.5:

	before	after
/?snippets-safe-mode=1	fatal, 1.3 KB	clean, 69 KB, closes </html>
/	200	200
/wp-admin/	302	302

(Worth noting when testing by hand: opcache will happily serve the old bytecode after you swap the file in, which cost me a confusing minute.)