#57205 closed defect (bug) (invalid)
PHP 8.1 warning : Implicit conversion from float 9.9 to int loses precision
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 4.7 |
Component: | General | Keywords: | php81 reporter-feedback |
Focuses: | Cc: |
Description
Hi,
I use pressable as hosting and tehir php error log shows me these.
<?php [24-Nov-2022 20:41:44 UTC] PHP Deprecated: Implicit conversion from float 9.9 to int loses precision in /wordpress/core/6.1.1/wp-includes/class-wp-hook.php on line 77 [24-Nov-2022 20:41:44 UTC] PHP Deprecated: Implicit conversion from float 9.9 to int loses precision in /wordpress/core/6.1.1/wp-includes/class-wp-hook.php on line 79
Attachments (1)
Change History (10)
#3
@
18 months ago
For the record: I've done a plugin search and couldn't find a plugin hosted on wp.org which does this, so this is likely a custom or commercial plugin: https://wpdirectory.net/search/01GJXK78AKQP4E65SHK2NACYDQ
#4
@
17 months ago
- Keywords reporter-feedback added; close removed
- Milestone Awaiting Review deleted
- Resolution set to invalid
- Status changed from new to closed
Closing this one out due to lack of additional details to show this is an issue within Core itself.
Discussion can continue on closed tickets, and it can be reopened if someone can provide more context.
#5
follow-up:
↓ 7
@
16 months ago
- Resolution invalid deleted
- Status changed from closed to reopened
I've been encountering this deprecation warning as well in recent projects. As mentioned already, this stems from third-party software using floats as a hook priority.
Since, historically, floats have been permitted and prior to PHP 8 were implicitly converted to strings, we could explicitly convert them to strings in order to support PHP 8+ without introducing a breaking change compared to this older ticket (#30875) which proposed enforcing only integers.
#7
in reply to:
↑ 5
@
16 months ago
- Resolution set to invalid
- Status changed from reopened to closed
Replying to mcaskill:
I've been encountering this deprecation warning as well in recent projects. As mentioned already, this stems from third-party software using floats as a hook priority.
Which only goes to confirm this should be fixed in the third-party software.
Since, historically, floats have been permitted...
Historically, floats were never "permitted", they just accidentally worked due to a quirk in PHP. The function has always been documented to expect integers and this has not changed.
and prior to PHP 8 were implicitly converted to strings, we could explicitly convert them to strings in order to support PHP 8+ without introducing a breaking change compared to this older ticket (#30875) which proposed enforcing only integers.
This would hide an error, which should be fixed (in the third party software) instead. We're not helping anyone by hiding away helpful notices/warnings. This will only cause more problems later on.
#8
follow-up:
↓ 9
@
16 months ago
Thank you for the confirmation on the matter.
I'll be sure to take this up with the offending third-parties.
In which case, should integers be enforced with an is_int()
check that either returns false or calls _doing_it_wrong()
?
#9
in reply to:
↑ 8
@
16 months ago
Replying to mcaskill:
Thank you for the confirmation on the matter.
I'll be sure to take this up with the offending third-parties.
In which case, should integers be enforced with an
is_int()
check that either returns false or calls_doing_it_wrong()
?
I'm undecided on that at this moment. Adding a _doing_it_wrong()
would raise the error level from E_DEPRECATED
to E_NOTICE
, but would also make it more visible as the notice will display on all PHP versions, not just on PHP 8.1 and up.
I'd like to hear some more opinions about this.
Thanks @roadlink for reporting this.
Unfortunately, there is nothing which can be done without a backtrace of the notice.
The notice basically tells us there is a function call to `add_filter()` which passes
9.9
(a floating point number) as the$priority
, while that parameter is only supposed to be set to an integer (whole number).No such function call exists in WP Core, so this function call to
add_filter()
(oradd_action()
) comes from a plugin or a theme.Without a backtrace it is impossible to determine which plugin or theme is doing it wrong.
The issue should be fixed in the plugin/theme. No action should be taken on this in WP Core.
You could try to figure out which plugin/theme is causing this by disabling them one by one until the notice is no longer being written to the logs.
Once you've figured out the plugin/theme, please report it to the author of the plugin/theme and ask them to fix it.
Suggest: close.