Deprecated urlencode() passing null warning during load-styles.php because get_stylesheet_directory() returns empty

[jerclarke]

I'm getting the following in my PHP error logs (nginx+php 8.3):

[08-Oct-2025 19:06:54] PHP deprecated: "urlencode(): Passing null to parameter #1 ($string) of type string is deprecated" file: [...]/wp-includes/script-loader.php:1680 url: example.com/wp-admin/load-styles.php?c=0&dir=ltr&load%5Bchunk_0%5D=dashicons,admin-bar,buttons,media-views,common,forms,admin-menu,dashboard,list-tables,edit,revisions,media,themes,about,nav-menu&load%5Bchunk_1%5D=s,wp-pointer,widgets,site-icon,l10n,wp-auth-check,wp-color-picker&ver=6.8.3 
[08-Oct-2025 19:06:54] PHP deprecated: "file_exists(): Passing null to parameter #1 ($filename) of type string is deprecated" file: [...]/wp-includes/global-styles-and-settings.php:429 url: example.com/wp-admin/load-styles.php?c=0&dir=ltr&load%5Bchunk_0%5D=dashicons,admin-bar,buttons,media-views,common,forms,admin-menu,dashboard,list-tables,edit,revisions,media,themes,about,nav-menu&load%5Bchunk_1%5D=s,wp-pointer,widgets,site-icon,l10n,wp-auth-check,wp-color-picker&ver=6.8.3 

They always come together and seem to be related, though this ticket is specifically about the first one because I've narrowed it down to something specific.

First, the deprecation warning is clearly a new thing in PHP 8.x, so it makes sense this was never noticed before.

As you can see in the error, it happens when loading load-styles.php. The line with the error is in wp_theme_has_theme_json():

	$theme_has_support[ $stylesheet ] = file_exists( $path );

Makes sense that if $path is empty, deprecation warning will show.

Using Xdebug I determined that the reason it's empty is that it uses get_stylesheet(), get_stylesheet_directory(), and get_template_directory(), all of which return null in the context of load-styles.php.

If I debug wp_theme_has_theme_json() on a wp-admin screen, those functions return strings and a $path is created, but in load-styles.php they come up empty and the deprecation warning is the result.

I tested this with a totally vanilla copy of WP using twenty-twentyfive and had the same results.

Note that the errors don't show on my local Valet+nginx installation, they only arrive in the logs of my live server for some reason. That said, Xdebug confirms that the problem exists locally as well, albeit silently.

FWIW it doesn't seem like this actually breaks anything, I only noticed it because it fills up my server's error logs (effectively notifying me when a user has logged in with a cold CSS cache). It seems plausible to me that the "failure" of get_stylesheet() etc. is a long-time accepted state of affairs, since it doesn't hurt anything as the theme doesn't affect these scripts.

Still, I think it should be fixed one way or another, whether making those stylesheet functions work in load-styles.php, or just fixing wp_theme_has_theme_json() to not call file_exists() if $path is empty.

Thanks to anyone who can look into this and confirm or deny my conclusion that it is indeed an issue that affects all WP installs.

[jerclarke]

For now my temporary fix will be to use the following in wp-config.php:

define( 'CONCATENATE_SCRIPTS', false );

This silences both of the errors above because it disables the entire load-scripts.php system and thus these two bugs don't surface.

Obviously this isn't a good solution, because I miss out on the intended performance benefits of concatenating and minifying the scripts. At the same time, I tested the load speed in dev tools and the difference was minimal in 2025 Chrome, more or less irrelevant in the random differences between loads. As I read ​elsewhere where people are struggling with this issue, the whole premise of concatenating scripts is a lot less relevant now than it was a decade ago when systems like this were added.

Really hoping this is something that can be fixed in core, of course. Clean logs are priceless for finding actual bugs, after all.