Deprecate filter_input() or not? View as Markdown

Hi all!

There is some discussion on a recent bug report[1] about filter_input()
and related functionality. The bug report had been closed, because this
functionality has already been added to the general deprecation RFC for
PHP 8.5[2]. Then the OP raised a point regarding the usefulness of
filter_input() to get at the original input, to avoid working with
possibly modified superglobals.

In my opinion, this topic should be discussed here, and not in a bug
report. So, has anybody thoughts about the filter_input() deprecation?

[1] https://github.com/php/php-src/issues/17543
[2]
https://wiki.php.net/rfc/deprecations_php_8_5#deprecate_filter_input_filter_input_array_and_filter_has_var

Christoph

Hey Christoph,

I don’t know why they are focusing on WordPress specifically, but this function is vital for any software that runs untrusted code (plugins, anything exec’d from /tmp — ie, templates, compiled containers, etc). Gina suggests using psr7 which suffers from the same problem in most frameworks, which allow setting a new request object or mutating it in some way.

I’m not sure it should be deprecated and I’d even argue not closing tickets just because they are in the mass-deprecation rfc that hasn’t been voted on yet.

— Rob

While the filter API wasn't designed with this in mind, the use of
filter_input to get the unmodified data is probably the only good
reason to ever use this API. If possible, it would be better to have
dedicated functions in standard for reading the unmodified input data
and then deprecate this function. I wouldn't even mind unbundling the
whole filter extension.

Hi,

On Wed, Feb 5, 2025 at 2:15 PM Christoph M. Becker cmbecker69@gmx.de
wrote:

Hi all!

There is some discussion on a recent bug report[1] about filter_input()
and related functionality. The bug report had been closed, because this
functionality has already been added to the general deprecation RFC for
PHP 8.5[2]. Then the OP raised a point regarding the usefulness of
filter_input() to get at the original input, to avoid working with
possibly modified superglobals.

It was actually closed because of misunderstanding of the requested envs
that are supplied by SAPI. So it's now re-open. We should also never close
anything because it got to the drafted deprecation list. It can be closed
only if it really gets deprecated.

In my opinion, this topic should be discussed here, and not in a bug
report. So, has anybody thoughts about the filter_input() deprecation?

I don't think we should deprecate it. It's used in many applications.

Cheers

Jakub

There is some discussion on a recent bug report[1] about
filter_input() and related functionality. The bug report had been
closed, because this functionality has already been added to the
general deprecation RFC for PHP 8.5[2]. Then the OP raised a point
regarding the usefulness of filter_input() to get at the original
input, to avoid working with possibly modified superglobals.

In my opinion, this topic should be discussed here, and not in a bug
report. So, has anybody thoughts about the filter_input()
deprecation?

I don't think they need to be deprecated, just because it is
"confusing". They were added specifically so that you could operate on
the original raw data.

cheers,
Derick