[wp-trac] [WordPress Trac] #51894: PHP 8: Invalid functions added to hooks now cause fatals

[WordPress Trac]

#51894: PHP 8: Invalid functions added to hooks now cause fatals
-------------------------+-----------------------------
 Reporter:  dlh          |      Owner:  (none)
     Type:  enhancement  |     Status:  new
 Priority:  normal       |  Milestone:  Awaiting Review
Component:  General      |    Version:
 Severity:  normal       |   Keywords:  php8
  Focuses:               |
-------------------------+-----------------------------
 `call_user_func()` and `call_user_func_array()` are among the functions in
 PHP 8 that throw a `TypeError` when passed a parameter of an invalid type,
 which means that `do_action()` and `apply_filters()` are capable of
 generating fatal errors when the hooked function no longer exists, has a
 typo, etc.

 A lot of amazing work has gone into ensuring that WordPress calls internal
 PHP functions with correct types (e.g. #51423). The PHP 8 dev note also
 helpfully reviewed the new strict-typing behavior.

 But I might argue that the risk to `apply_filters()` represents a special
 "gotcha" worth highlighting for developers (and I hope that I haven't
 missed that it was) because of its delayed occurrence and relative
 unpredictability:

 - Unlike invoking a WordPress function that uses its parameters
 immediately, passing an invalid callable to `add_action()` or
 `add_filter()` is itself still safe. The fatal error occurs whenever the
 hook fires, if it does at all during the particular request.

 - Also unlike invoking most WordPress functions, it's possible to hook an
 invalid callable that later becomes valid, e.g. if the function is loaded
 later in the bootstrap process.

 On a more basic level, the change in behavior might be worth just
 acknowledging as arguably a backwards compatibility break in core:
 Previously, invalid callables added to hooks didn't cause fatals, and now
 they do.

 #38116 raised the issue of invalid callables generating warnings and
 proposed an `is_callable()` check. That certainly would bypass the fatal
 now, but as yet there is no counterargument in that ticket to the concerns
 about performance and general prudence.

 Another thought that would be specific to PHP 8 would be to catch
 `TypeError`s thrown by the `call_user_func*` block and trigger a warning
 but let execution continue. That might address the performance concerns
 but not the prudential ones.

 So, the best course of action for core might be to do nothing, but even
 so, perhaps this ticket can at least note that consensus.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/51894>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform