[wp-trac] [WordPress Trac] #51525: Add new functions apply_filters_single_type() and apply_filters_ref_array_single_type()

[WordPress Trac]

#51525: Add new functions apply_filters_single_type() and
apply_filters_ref_array_single_type()
-------------------------------------------------+-------------------------
 Reporter:  jrf                                  |       Owner:  (none)
     Type:  feature request                      |      Status:  new
 Priority:  normal                               |   Milestone:  Future
                                                 |  Release
Component:  General                              |     Version:
 Severity:  normal                               |  Resolution:
 Keywords:  2nd-opinion php8.x early has-patch   |     Focuses:
  has-unit-tests                                 |
-------------------------------------------------+-------------------------

Comment (by mathieulamiotwpmedia):

 Thank you for your ideas! I would tend to agree with @jrf, especially
 "commonly used plugins will have put guard code in to prevent acting on
 incorrect/unexpected input data to prevent their reputation being damaged
 by other plugins/themes doing it wrong."
 This is one of the main motivations behind this enhancement. Maybe this
 point of view differs depending if you are a Core maintainer or a 3rd
 party developer, but as a 3rd party developer, even if cases of filter
 misuse are rare, this is already too much. Unfortunately, we have frequent
 reports like that on code that we did not safeguard properly. Hence our
 need for an off-the-shelf safe-type mechanism. I assume this is a general
 issue in the ecosystem, that would push developers away from actively
 providing customization with filters
 .
 I am saying safe-type, not strict type: the idea here is resiliency, not
 failing early.

 As this ticket has been discussed at yesterday's weekly of WP Core
 devchat, here are some feedbacks and next steps:

 - It would be good to handle, or at least anticipate union types and
 nullable types, based on PHP syntax (for instance ?int|string). @tabrisrp,
 I and our team will look into this great idea and circle back with a
 refined proposal.
 - "changes to src/wp-includes/class-wp-hook.php shouldn't rely on other
 files.  There are situations where it is loaded extremely early." We'll
 look into that as well!
 - Should we use doing_it_wrong or something else, maybe failing early to
 enforce types? In the spirit of resiliency, doing_it_wrong allows to
 preserve safety while informing. A mechanism that would fail early would
 not fit the need as a 3rd party developer, and would reduce the interest
 in this feature. Let's gather opinions on this point.
 - "For a major change to such a foundational part of the Core API, I would
 also think the next steps would be to have a committer willing to
 "sponsor" this effort (for lack of a better term). Someone who would help
 support the creation of a Proposal, collect feedback, and help define when
 the feature is "merge" ready." I do agree with that! So if any committer
 would like to sponsor this initiative, we'd be happy to continue the
 effort!

 Thanks, we will try to circle back here with a refined proposal about the
 2 first points in a few weeks.

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