Hi All, If there are no objections, I am planning to start the voting on this RFC over the weekend.
Regards, Kamil On Fri, 9 Jan 2026 at 10:55, Tim Düsterhus <[email protected]> wrote: > > Hi > > Am 2026-01-08 21:43, schrieb Kamil Tekiela: > > Despite receiving some criticism, I would like to bring it to a vote > > still. > > > > If this method doesn't get added, then it means that this SQL > > injection vulnerability will never be patched. Sure, most users have > > probably switched to prepared statements and we should encourage > > others to do so, but as long as manual escaping exists, it should be > > reliable and not prone to hidden SQL injection. > > I'm in favor. It's a localized addition with a clear purpose and > value-add, a good name and precedent in related extensions. I'm also in > favor of using deprecations to steer users away from unsafe APIs - even > when the functionality in question will never be removed. Unfortunately > getting those voted in is complicated, I've had my fair share of > experience with that in the past few PHP versions. But I agree that the > deprecation must not happen in the same version where the replacement is > added, since this makes incremental roll-outs of the new PHP version > annoying since there is no version of the code base that is cleanly > supported by both PHP versions. > > With regard to the RFC itself: Please clean up the “Voting Choices” > section, including properly filling in the vote title. The latter then > triggers a 14 day cooldown (since changes to the voting widgets are > Major changes): > https://github.com/php/policies/blob/main/feature-proposals.rst#types-of-changes > > Best regards > Tim Düsterhus
