[wp-trac] [WordPress Trac] #54997: untrailingslashit() throws a deprecation notice for null on PHP 8.1

WordPress Trac noreply at wordpress.org
Thu Sep 29 06:22:54 UTC 2022


#54997: untrailingslashit() throws a deprecation notice for null on PHP 8.1
-----------------------------------+---------------------
 Reporter:  haozi                  |       Owner:  (none)
     Type:  defect (bug)           |      Status:  new
 Priority:  normal                 |   Milestone:  6.1
Component:  Formatting             |     Version:  6.0
 Severity:  normal                 |  Resolution:
 Keywords:  has-patch php81 close  |     Focuses:
-----------------------------------+---------------------
Changes (by Cybr):

 * keywords:  has-patch php81 => has-patch php81 close


Comment:

 I dumped a backtrace, and the problem lies in
 `WP_Scripts::print_translations()` calling `load_script_textdomain()`,
 where the third parameter given is `NULL`. This is further detailed by
 @jrf in https://github.com/WordPress/wordpress-develop/pull/3186.

 There is argued that the call to `unstrailingslashit()` from
 `load_script_textdomain()` needs fixing and must test for `is_string(
 $path )`.

 (1) However, for `load_script_textdomain()`, I reckon we should change
 `$path` from default `NULL` to `''`, as the PHPdoc for the function also
 requires, and only **expect a string** henceforth.

 The same goes for function `unstrailingslashit()`: guide via PHPDoc that
 it requires a string (which it already does), do nothing further but let
 PHP send out warnings via `rtrim()`. Again, **expect a string** from
 developers.

 (2) Finally, fix the actual offending caller
 `WP_Scripts::print_translations()` for passing `NULL` to `$path`.

 That said, I just downloaded a copy of trunk and saw this issue was fixed
 as described in this comment ((1) and (2)). I am not sure where this was
 committed, though. But, I think it's already fixed perfectly, thus marking
 for "close".

 I highlighted "expect" above: If we'd add forceful type checks for every
 function call and property before requiring PHP 7.4 or later, we might as
 well develop a new server language. Even if we'd require PHP 7.4 or later,
 I still recommend staying clear from strictly typing because that is
 notoriously slow: https://3v4l.org/j7FPnW. I recommend keeping PHPDoc
 leading instead of imposing type declarations.

 It isn't difficult to fix bugs, but it is inconceivable and detrimental to
 anticipate every mistake.

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


More information about the wp-trac mailing list