[wp-trac] [WordPress Trac] #57581: str_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated in functions.php

[WordPress Trac]

#57581: str_replace(): Passing null to parameter #3 ($subject) of type array|string
is deprecated in functions.php
-------------------------------------+---------------------
 Reporter:  ipajen                   |       Owner:  (none)
     Type:  defect (bug)             |      Status:  new
 Priority:  normal                   |   Milestone:  6.3
Component:  General                  |     Version:  trunk
 Severity:  normal                   |  Resolution:
 Keywords:  PHP81 close 2nd-opinion  |     Focuses:
-------------------------------------+---------------------

Comment (by hellofromTonya):

 Replying to [comment:2 SergeyBiryukov]:
 > In a discussion with @joostdevalk, it was pointed out that this might
 help surface the problem faster, and would be a better developer
 experience.

 While yes it ''may'', how far should this go? Should ''all parameters in
 all functions'' be type checked with a `_doing_it_wrong()`? This kind of
 question is part of what @jrf is talking about, i.e. architectural
 discussions and considerations of how (or if) to handle function/method
 parameters input validation.

 In this case, PHP is handling the notification that a type mismatch has
 happened, i.e. doing it wrong.

 I agree with @jrf to avoid adding `_doing_it_wrong()` for each report but
 instead to shift focus towards the larger architectural and developer
 experience discussion of systematically and structurally handling this.

 Also quoting @azaozz who has raised the flag that `_doing_it_wrong()` is
 not meant for type validation, but instead is for the most severe
 instances of doing something thing.

 While I do sympathize and know how hard it can be to trace where the root
 cause is and where/how to report it, I agree with @jrf to avoid dripping
 type checks into the source code. I support closing this ticket in favor
 of a broader, encompassing architectural approach across Core's source
 code, rather than in a handful of places.

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