[wp-trac] [WordPress Trac] #51423: Fix function argument type issues reported by PHPStan

WordPress Trac noreply at wordpress.org
Mon Apr 12 21:41:11 UTC 2021


#51423: Fix function argument type issues reported by PHPStan
-------------------------------------------------+-------------------------
 Reporter:  SergeyBiryukov                       |       Owner:
                                                 |  hellofromTonya
     Type:  task (blessed)                       |      Status:  assigned
 Priority:  normal                               |   Milestone:  5.8
Component:  General                              |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  php8 has-patch has-unit-tests        |     Focuses:  coding-
  commit                                         |  standards
-------------------------------------------------+-------------------------

Comment (by hellofromTonya):

 Replying to [comment:91 SergeyBiryukov]:
 > * I don't see how `get_site_option( 'limited_email_domains' )` can
 return `null` in normal workflow, so it seems a bit random to specifically
 guard against `null` here. Even if the option does not exist, it returns
 `false`. So it looks like the only way for that to happen is if someone
 specifically filters the value to `null`. Instead of targeting `null`, I
 think the existing check for a truthy value would be enough here.

 Checking for truthy would result in different value if the the returned
 filtered option was a string 0 or 0.0. [https://3v4l.org/oYFA8 See it in
 action here]. I know that's a very very very far edge case. But here we
 were seeking to not change the existing behavior for backwards
 compatibility for any 3rd parties that are filtering the option.

 Why guard for `null`?

 In PHP 8.1, it will generate a deprecation notice. But in less than PHP
 8.1, all falsey values will work with `str_replace` as
 [https://3v4l.org/sduMb shown here].

 The PR could guard against the falsey values except for string 0 and 0.0.
 However, it might be confusing why. So we opted to guard specifically to
 prevent the future PHP 8.1 deprecation notice.

 @SergeyBiryukov what do you think?

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


More information about the wp-trac mailing list