[wp-trac] [WordPress Trac] #58157: PHP Deprecated: str_replace(): Passing null to parameter #3 ($subject) of type array|string is deprecated in wp-includes/formatting.php

WordPress Trac noreply at wordpress.org
Thu May 11 11:13:24 UTC 2023


#58157: PHP Deprecated: str_replace(): Passing null to parameter #3 ($subject) of
type array|string is deprecated in wp-includes/formatting.php
-------------------------------------------------+---------------------
 Reporter:  salvoaranzulla                       |       Owner:  (none)
     Type:  defect (bug)                         |      Status:  new
 Priority:  normal                               |   Milestone:  6.3
Component:  Media                                |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  php81 needs-patch reporter-feedback  |     Focuses:
-------------------------------------------------+---------------------

Comment (by SergeyBiryukov):

 Replying to [comment:11 Soean]:
 > I think that the last solution would be the best one in this case,
 right?

 On one hand, yes, since the `$display_name` parameter is documented as
 `string|null` in `the_author` filter, and `ent2ncr()` is hooked to that
 filter by default, so it should be able to handle the `null` value as
 well.

 One the other hand, the current behavior is inconsistent:
 * `get_the_author()` returns `null` if there is no author name.
 * `get_the_modified_author()` returns empty string if there is no author
 name.

 Some history here:

 * [2858] / #1531 added `the_author` filter.
 * [12284] / #10758 added `null` as a default value if there is no author.
 * [53187] / #55420 added an empty string if there is no author in a
 similar fix for `the_modified_author` filter.

 So maybe `get_the_author()` could be updated to use an empty string too
 instead of `null`? That would be a minor backward compatibility break, but
 would result in a more consistent API.

 At a glance, I don't see any issues with returning an empty string here,
 it should not cause a fatal error anywhere as far as I can tell, but
 should be mentioned in a dev note.

 [attachment:"58157.diff"] implements this if we go in that direction.

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


More information about the wp-trac mailing list