[wp-trac] [WordPress Trac] #64087: Deprecated urlencode() passing null warning during load-styles.php because get_stylesheet_directory() returns empty

[WordPress Trac]

#64087: Deprecated urlencode() passing null warning during load-styles.php because
get_stylesheet_directory() returns empty
-------------------------+-------------------------------------------------
 Reporter:  jerclarke    |       Owner:  (none)
     Type:  defect       |      Status:  new
  (bug)                  |
 Priority:  normal       |   Milestone:  7.0
Component:  Script       |     Version:
  Loader                 |
 Severity:  minor        |  Resolution:
 Keywords:  php8         |     Focuses:  administration, performance, php-
  reporter-feedback      |  compatibility
-------------------------+-------------------------------------------------

Comment (by jerclarke):

 Thanks for the tip about Playgrounds logging. I managed to see errors in
 the logs, but it was VERY inconsistent and unreliable, so I ended up using
 a completely fresh and default LocalWP installation to debug this outside
 my Varnish/live environment.


 **I figured out why the errors don't normally show, `load-styles.php` and
 `load-scripts.php` both call `error_reporting(0)` at the top of the file!
 **

 {{{
 /*
  * The error_reporting() function can be disabled in php.ini. On systems
 where that is the case,
  * it's best to add a dummy function to the wp-config.php file, but as
 this call to the function
  * is run prior to wp-config.php loading, it is wrapped in a
 function_exists() check.
  */
 if ( function_exists( 'error_reporting' ) ) {
         /*
          * Disable error reporting.
          *
          * Set this to error_reporting( -1 ) for debugging.
          */
         error_reporting( 0 );
 }
 }}}

 Aside from the fact that that is cringe AF, it explains a lot. When I
 disable that line I suddenly get both of the errors I reported at the top.

 The reason it showed up on the live server is we have a custom error
 handler that doesn't respect `error_reporting()`, so I guess it's exposing
 WP's dirty little secret here.

 Am I being unreasonable to say that WP should work, without errors, even
 if `error_reporting` is forced on?

 I figured out these lines to insert in `wp_theme_has_theme_json()` before
 the `file_exists()` call that I think clarify what's going on:

 {{{
         error_reporting(E_ALL);
         error_log( "LOADING: " . $_SERVER["HTTP_HOST"] .
 $_SERVER["REQUEST_URI"]);
         error_log( 'BEFORE filter $path');
         error_log('$path [gettype] ' . gettype($path) . ' [value] ' .
 $path);

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

         /** This filter is documented in wp-includes/link-template.php */
         $path = apply_filters( 'theme_file_path', $path, 'theme.json' );

         error_log('AFTER filtering $path');
         error_log('$path [gettype] ' . gettype($path) . ' [value] ' .
 $path);

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

 Resulting log:

 {{{
 [26-Feb-2026 17:25:22 UTC] LOADING: gv.test/wp-admin/load-styles.php
 [26-Feb-2026 17:25:22 UTC] BEFORE filter $path
 [26-Feb-2026 17:25:22 UTC] $path [gettype] string [value] /theme.json
 [26-Feb-2026 17:25:22 UTC] AFTER filtering $path
 [26-Feb-2026 17:25:22 UTC] $path [gettype] NULL [value]
 [26-Feb-2026 17:25:22 UTC] PHP Deprecated:  file_exists(): Passing null to
 parameter #1 ($filename) of type string is deprecated in /{site}/wp-
 includes/global-styles-and-settings.php on line 440
 }}}

 So it `$path` starts as `/theme.json` but ends up as `null` after the
 filter, thus triggering an error, IF error reporting is enabled, of
 course.

 I didn't dig into WHY that filter returns null, but now that I know that
 errors are **expected** during `load-styles.php`, I'm disinclined to spend
 more time on it.

 Honestly I'm not sure what to do at this point, it seems like this corner
 of WordPress is just "errors allowed" and I should assume a resolution of
 `wontfix`.

 More than anything it makes me think of your earlier comment:

 > Milestoning this for 7.0 because we may remove concatenation in #57548.

 This whole system should probably be burned with fire, TBH. Glad I turned
 it off on my actual sites 😅

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/64087#comment:10>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform