On Wed, 2 Jul 2025, Gina P. Banyard wrote: > Some should be non-controversial, others a bit more. If such, they > might warrant their own dedicated RFC, or be dropped from the proposal > altogether.
The changes to filter continue to undermine what the extension was meant to do. The filter.default INI setting was deprecated in PHP 8.1, which was already a mistake. The intention behind the filter extension was that admins can set a default filter for *all* data coming in through this `filter.default` setting as a "safe" fallback. That could/should probably even be a filter that just makes all data "☺" for example, to indicate you're working with unsanitised data. (I don't think there is such a filter though). This fallback could then be 'circumvented' by using the filter_input/input_array() functions, so that each of them can employ its own unique, and useful, filter on that specific element in the GET/POST/etc arrays. Saying that "The filter_input() and filter_input_array() functions operate on the original values provided by the SAPI that populate the superglobals for $_GET, $_POST, $_SERVER, $_ENV, and $_COOKIE. " is basically documenting the *original intention of these functions*. If there is anything odd with your example, is that you can modify the values in GET/POST/etc superglobals to begin with. "As it is easy and straight forward to have the same behaviour by using filter_var($_GET['a'], /* other params */) and filter_var_array($_GET, /* other params */), we propose to deprecate filter_input() and filter_input_array()." No. The whole point is that these functions read the raw data, the one that wasn't filtered by the default filter (which has been inadvisably deprecated). I would therefore *undeprecate* filter.default, and allow these filter functions are they currently are, because they implement the original design idea behind this extension. cheers, Derick
