[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 dmsnell):

 Before forming many personal thoughts, I wonder if it would be helpful for
 us to measure the breadth of this particular issue at large. The reason is
 that I wonder about the underlying warrant.

 > PHP 8 is a lot more strict about data types and depending on what is
 done with the data will start throwing more notices/warnings, but more
 concerning exceptions, which will result in fatal errors (= white screen
 of death) when uncaught.

 This is true, but hopefully also WordPress developers are being educated
 that filter inputs are always `mixed`. Okay, well maybe this isn't true,
 but I see //many// errors in practice that are related to people assuming
 that a given input is in an expected form, particularly in server code for
 blocks. However, in almost all of those cases, the types are correct, so
 of the frequent cases I've already seen, type enforcement would leave the
 bugs unseen.

 > they are only a BC_break for hooked-in functions already doing it wrong
 and likely causing problems already.

 With a quick scan of Core code, I found that `determine_current_user`
 already returns `string|boolean`, and more may exist. Maybe this is
 broken, but I think that the prevalence of `null|other_type` is really
 //extremely// common. In fact, maybe it's more like
 `null|false|other_type`.

 In the case of crawling before walking, I think some empirical evidence
 could still help, because maybe single-typed filters don't provide the
 value we'd hope for, aren't applicable as frequently as we suspect, and
 only introduce breakage where existing code worked fine (sadly the primary
 result I've seen of adding strict types into existing PHP code).

 ----

 Perhaps we could start collecting this data with the Playground and the
 plugin previews in the Directory, or setup a test trying to run through
 various flows and code paths to see the extent of how types vary and how
 those are used. Without plugins installed most filters don't have attached
 functions, so it'd only really be possible to judge by integrating with
 plugins, even many plugins at once. Maybe we could use something like this
 to sample real-world sites and get more realistic data.

 In summary, I wonder what the situation in practice looks like, and if
 it's prevalent that plugins are returning //the wrong type// and that the
 wrong type //causes defects// then it should be easier to consider
 introducing a new primitive as fundamental and exposed as the proposed
 ones would be.

 My script, which took only a few minutes to write, prints a text file for
 visual inspection and produces a JSON file with actual call counts. For
 each filter name, the type of the initial `$value` is an array key, and
 then under each of those initial value types is a key/value array of
 filtered value types and the number of times a filter returned that type.

 [[Image(https://cldup.com/xu0P2hE82E.png)]]

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