Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:35293
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain bitxtender.com from 80.237.132.12 cause and error)
Message-ID: <2ED7DEA0-7F0F-4969-A918-BE8C9782B877@bitxtender.com>
To: PHP Internals <internals@lists.php.net>
In-Reply-To: <1202378529.26463.19.camel@localhost.localdomain>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v915)
Date: Thu, 7 Feb 2008 12:50:36 +0100
References: <47AA5354.7020806@zend.com>  <47AA88A9.4000802@lerdorf.com> <1202376366.26463.3.camel@localhost.localdomain> <47AAD2BD.1030804@lerdorf.com> <1202378529.26463.19.camel@localhost.localdomain>
Subject: Re: [PHP-DEV] _REQUEST and variable_order
From: dz@bitxtender.com (=?ISO-8859-1?Q?David_Z=FClke?=)

Am 07.02.2008 um 11:02 schrieb Jani Taskinen:

> On Thu, 2008-02-07 at 01:43 -0800, Rasmus Lerdorf wrote:
>>
>> Well, plenty of people know about this feature and make use of it.
>> Especially since it has been documented to work this way for a long  
>> time.
>> See: http://php.net/manual/en/ini.core.php#ini.variables-order
>
> But was it really designed to work like that? :)
>
> Anyway, I guess there's no other way out of this than creating another
> ini option, say "request_variables_order" which controls whatever goes
> in $_REQUEST. But would the "variables_order" still control the overal
> situation? For example when it is set to "GP" and
> "request_variables_order" is set to "GPC", would $_REQUEST have all of
> $_GET / $_POST / $_COOKIE regardless what "variables_order" has in it?

Mh, "request_variables_order" is probably not the best idea given it  
can be pretty confusing when compared to "variables_order" - and nore  
so if you look at what "variables_order" really does; the only "order"  
it defines is that of the $_REQUEST merging, but I doubt many people  
know that removing something from that var also suppressed the  
respective superglobal entirely.
Maybe "request_populate_order" or so?


- David