On 09/11/14 21:59, Rowan Collins wrote:
> None of which has anything to do with E_STRICT. Strict notices aren't
> indications that behaviour has changed; since we have E_DEPRECATED, they
> shouldn't even indicate behaviour is about to change; they just indicate
> that there might be a better way of
On 03/11/2014 22:10, Stas Malyshev wrote:
I'd like to put to vote my proposal about the filtered unserialize():
Hi,
After discussing this RFC with a few other people, we seem to agree that
allowing some level of security-related filtering when unserializing is
a nice idea -- so, we would be
On 09/11/2014 20:48, Lester Caine wrote:
On 07/11/14 01:59, Christoph Becker wrote:
Nobody suggested to switch off error reporting. IMO, E_STRICT is
supposed to be a weak form of E_DEPRECATED, i.e. a hint for the
developer to modernize the code in the near future. Until this can be
done, it se
On 07/11/14 01:59, Christoph Becker wrote:
> Nobody suggested to switch off error reporting. IMO, E_STRICT is
> supposed to be a weak form of E_DEPRECATED, i.e. a hint for the
> developer to modernize the code in the near future. Until this can be
> done, it seems to be perfectly fine to suppress
On 09/11/2014 15:10, Rowan Collins wrote:
On 6 November 2014 00:31:18 GMT, Andrea Faulds wrote:
On 5 Nov 2014, at 22:29, Sherif Ramadan
wrote:
From all the people I've spoken with that have a problem with
handling PUT
requests in PHP, it seems that they'd rather have PHP populate
$_FILES/
On 6 November 2014 00:31:18 GMT, Andrea Faulds wrote:
>
>> On 5 Nov 2014, at 22:29, Sherif Ramadan
>wrote:
>>
>> From all the people I've spoken with that have a problem with
>handling PUT
>> requests in PHP, it seems that they'd rather have PHP populate
>> $_FILES/$_POST automatically in this c
