fix: blank snippets page when another plugin's screen_settings filter returns null

[TallblokeUK]

Fixes the fatal behind the "blank All Snippets page" reports — #671 and #674 — reproduced locally from a customer's WordPress fatal-error email.

The bug

Manage_Menu_Screen_Options::render() declared its parameter as string:

public function render( string $screen_settings ): string {

It is hooked to screen_settings, a shared WordPress filter. Any other plugin or theme that filters it and forgets to return its value hands the next callback null, and on PHP 8 that is a fatal:

Uncaught TypeError: Code_Snippets\Admin\Menus\Manage\Manage_Menu_Screen_Options::render():
Argument #1 ($screen_settings) must be of type string, null given,
called in wp-includes/class-wp-hook.php on line 343

We are not the plugin at fault, but we are the one that dies.

Why it looks like a blank page rather than an error

The filter runs while WordPress renders the screen meta — after the admin header, before the page content. So the response is a 200 with a fully working admin menu and no content at all:

	before	after
http status	200	200
admin menu links	51	51
snippets table	0	1
page heading	none	Local Snippets: All Snippets

That is why the reports describe a healthy-looking admin with an empty Snippets screen, and why nothing obvious shows up in the browser console.

The fix

Accept the value loosely and coerce it. A careless callback elsewhere now degrades to an empty Screen Options panel instead of taking the page down.

public function render( $screen_settings ): string {
    $screen_settings = is_string( $screen_settings ) ? $screen_settings : '';

Testing

Two regression tests. Both fail on core with the customer's exact error at the same line; the second goes through the real apply_filters → class-wp-hook.php path rather than calling the method directly.

• test_render_tolerates_a_null_value_from_an_earlier_callback
• test_screen_settings_filter_chain_survives_a_null_returning_callback

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

Also verified end to end on a local WP 7.1 / PHP 8.3 site with an mu-plugin returning null from screen_settings at priority 5 — the table renders again and the filter chain completes instead of stopping at our callback.

Same hazard elsewhere — deliberately not in this PR

The sweep found three more strictly-typed filter callbacks. Left out to keep this patch-release diff tight, but worth a follow-up:

Callback	Hook	Blast radius
disable_snippet_execution( bool )	code_snippets/execute_snippets	Our own public filter, one we document for third parties. A null return here fatals the front end, not just admin
add_safe_mode_query_var( string )	home_url, admin_url	Safe mode only
add_settings_fields( array )	code_snippets_settings_fields	Settings screen only

disable_snippet_execution is arguably worse than the one fixed here — happy to fold it in or open it separately, whichever you prefer.

[code-snippets-bot]

Download and install

📦 code-snippets.3.10.0.zip