[wp-trac] [WordPress Trac] #57581: str_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated in functions.php
WordPress Trac
noreply at wordpress.org
Tue Feb 28 13:45:21 UTC 2023
#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 jrf):
Replying to [comment:2 SergeyBiryukov]:
> Replying to [comment:1 jrf]:
> > The function used `wp_normalize_path()` is clearly indicated as only
accepting `string`s, so IMO, yes, this should be fixed by the plugins
which are ''doing it wrong''.
>
> Should we consider adding a `_doing_it_wrong()` notice here if
~~`$path`~~++the parameter++ is not a string?
>
> In a discussion with @joostdevalk, it was pointed out that this might
help surface the problem faster, and would be a better developer
experience.
For visibility I'm re-posting the reply I posted to
[https://core.trac.wordpress.org/ticket/57580#comment:3 the same question
elsewhere]:
> That would be the ''only'' thing we could do in Core about this issue,
but there is no structural plan on whether and how to validate the type of
received parameters in functions in Core ''(well, I have a plan, but it's
not like that will get approved anytime soon)''.
>
> The current hap-snap "add a ''_doing_it_wrong'' to a function whenever
someone reports an issue of a plugin doing silly things" is not helping
anyone in the long run.
>
> IMO we need a more structural approach.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/57581#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list