[wp-trac] [WordPress Trac] #53493: Errors in `ms-files.php` aren't logged

[WordPress Trac]

#53493: Errors in `ms-files.php` aren't logged
-------------------------------------------+------------------------
 Reporter:  iandunn                        |       Owner:  iandunn
     Type:  enhancement                    |      Status:  reopened
 Priority:  low                            |   Milestone:  5.9
Component:  Upload                         |     Version:  3.0
 Severity:  normal                         |  Resolution:
 Keywords:  early has-patch needs-testing  |     Focuses:  multisite
-------------------------------------------+------------------------

Comment (by schlessera):

 Let me try to reply to the questions above.

 Replying to [comment:8 iandunn]:
 > * r51358 was only supposed to enable ''logging'' errors, not
 ''displaying'' them. Has this been reproduced in a browser, or just WP-
 CLI? If it's only WP-CLI, then it may be related to how
 [https://github.com/wp-cli/wp-cli/issues/3220 it doesn't always respect
 WP_DEBUG].

 What the change does is to go from suppressing errors in a specific
 context to not suppressing errors in a specific context. Whether they are
 sent to the logs, displayed or manipulated in some other way depends on
 the environment. However, no matter what the environment is, the previous
 behavior was to "not have errors at all", which now changed.

 > * The change should also only effect `ms-files.php` (multisite media
 proxying), which doesn't seem related to `wp core is-installed`. Does
 reversing this commit locally fix that CLI command?

 Yes, reverting the commit fixes that command. The errors appear as soon as
 the `MULTISITE` define is found in the `wp-config.php`, which triggers
 loading the `ms-files.php`. Then, the multisite bootstrapping is supposed
 to figure out the exact topology from the database, which throws WPDB
 errors depending on the state of the site. These errors were always
 present, what were suppressed. The DB calls in Core that can potentially
 fail with an error but are necessary are all wrapped in a
 `$wpdb->suppress_errors()` structure, except for the multisite one in
 question here, as no one noticed they produced errors due to the
 `error_reporting( 0 )`.

 > * The change was committed 6 months ago, at the start of the 5.9 cycle,
 so it seems odd that it wasn't discovered until just now.

 I have seem them much earlier, but the combination of PHP 8.1 and latest
 Core `trunk` has had so many breaking changes that it took quite a while
 to distill everything and figure out the root cause for everything. In the
 beginning, I assumed it was a typing error or similar.

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