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 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.
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.
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.
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.