One concern that I have is the requirement of magic_quotes_gpc to Off during installation. If you have a flexible host and they allow you to modify or override the php.ini, everything's OK (after a bit of work to make the code changes). However, if you don't have a flexible host you might be stuck or have to migrate hosts. Additionally, what happens when some of the 2.5 users start upgrading to 3.0? We currently do not have a pre-upgrade check for magic_quotes_gpc = Off, so that would result in strange bugs.
In Joomla 2.5, magic_quotes_gpc to Off was not a requirement, but rather just a recommendation. In Joomla 3, it is a requirement. I recommend that we make magic_quotes_gpc = Off a recommendation (rather than a requirement) for Joomla 3.
The con to making it a recommendation (rather than a requirement): 1) Those sites with magic_quotes_gpc = On, wouldn't run as fast as they would if it was Off.
The Pros to making it a recommendation (rather than a requirement): 1) Those sites with magic_quotes_gpc = On, would be able to use Joomla 3.
To me, the pro definitely outweighs the con. Also, if they wanted to, they could go through the work of turning off magic_quotes_gpc (it just wouldn't be a requirement).
In short, it's a win/win situation for everyone if magic_quotes_gpc to Off was not a requirement, but rather just a recommendation.
If we decided to go that route, basically it would involve unescpaing all input data before we start to handle the request.
Since i recommended Nick ask this question on the Platform list, I wanted to throw in a couple of followup questions of my own - for clarity.
1. Is it true that the platform version that will be part of 3.0 will required magic quotes gpc to be off?
2. If not, (meaning if the platform continues to support this directive on) and since it sounds like strong consideration has been given to moving the Installer into the CMS, is it within the CMS Team's decision making structure to determine whether or not the requirement can be removed?
3. If so (meaning that the platform does not accommodate magic quotes), might it make sense that the code to unescape magic quotes gpc be added until PHP 5.4 is the base requirement? (It appears that the directive is deprecated in PHP 5.3 and removed in 5.4.)
3. B. If the platform simply no longer accommodates magic quotes gpc, can this be handled with a system plugin? Or, is the best way to deal with this to link to a wiki document that explains how to deal with a hoster that has this enabled.
> Joomla 3 is looking great! Great job to everyone!
> One concern that I have is the requirement of magic_quotes_gpc to Off > during installation. If you have a flexible host and they allow you to > modify or override the php.ini, everything's OK (after a bit of work to > make the code changes). However, if you don't have a flexible host you > might be stuck or have to migrate hosts. Additionally, what happens when > some of the 2.5 users start upgrading to 3.0? We currently do not have a > pre-upgrade check for magic_quotes_gpc = Off, so that would result in > strange bugs.
> In Joomla 2.5, magic_quotes_gpc to Off was not a requirement, but rather > just a recommendation. In Joomla 3, it is a requirement. I recommend that > we make magic_quotes_gpc = Off a recommendation (rather than a requirement) > for Joomla 3.
> The con to making it a recommendation (rather than a requirement): > 1) Those sites with magic_quotes_gpc = On, wouldn't run as fast as they > would if it was Off.
> The Pros to making it a recommendation (rather than a requirement): > 1) Those sites with magic_quotes_gpc = On, would be able to use Joomla 3.
> To me, the pro definitely outweighs the con. Also, if they wanted to, they > could go through the work of turning off magic_quotes_gpc (it just wouldn't > be a requirement).
> In short, it's a win/win situation for everyone if magic_quotes_gpc to Off > was not a requirement, but rather just a recommendation.
> If we decided to go that route, basically it would involve unescpaing all > input data before we start to handle the request.
On 21.08.2012, at 21:39, Amy Stephen <amystep...@gmail.com> wrote:
> Since i recommended Nick ask this question on the Platform list, I wanted to throw in a couple of followup questions of my own - for clarity.
> 1. Is it true that the platform version that will be part of 3.0 will required magic quotes gpc to be off?
Yes. On all PHP options that change the runtime behavior of PHP we basically opted for the one that works like PHP 5.4.
> 2. If not, (meaning if the platform continues to support this directive on) and since it sounds like strong consideration has been given to moving the Installer into the CMS, is it within the CMS Team's decision making structure to determine whether or not the requirement can be removed?
Not sure I understand the question. What does this have to do with the installer?
> 3. If so (meaning that the platform does not accommodate magic quotes), might it make sense that the code to unescape magic quotes gpc be added until PHP 5.4 is the base requirement? (It appears that the directive is deprecated in PHP 5.3 and removed in 5.4.)
We could but I don't think that's a good idea. The code involved could not only cause a decent performance I wouldn't wanna make any guarantees about its stability either.
> 3. B. If the platform simply no longer accommodates magic quotes gpc, can this be handled with a system plugin? Or, is the best way to deal with this to link to a wiki document that explains how to deal with a hoster that has this enabled.
It can be handled in the application. A system plug-in may not be a good choice, depends on how much input has been processed at that point and whether it includes any escaped parameters.
Best regards
Rouven
PS: Those developers using JInput should be aware that it never was aware of magic_quotes, you'd have to handle that yourself.
Thank you for clarifying this. The installer question was only relevant if
this wasn't a real requirement, so, just set that aside.
To summarize: Yes, it's a real requirement due to JInput and platform PHP
runtime options that magic quotes gpc cannot be enabled. However, something
can be done on the Application side of things, so, Nick was right to
discuss it on the CMS list.
I am sorry, Nick, for wasting your time and recommending to bring the
discussion here. You had the right place to begin with.
On Tue, Aug 21, 2012 at 2:57 PM, Rouven Weßling <m...@rouvenwessling.de>wrote:
> On 21.08.2012, at 21:39, Amy Stephen <amystep...@gmail.com> wrote:
> > Since i recommended Nick ask this question on the Platform list, I
> wanted to throw in a couple of followup questions of my own - for clarity.
> > 1. Is it true that the platform version that will be part of 3.0 will
> required magic quotes gpc to be off?
> Yes. On all PHP options that change the runtime behavior of PHP we
> basically opted for the one that works like PHP 5.4.
> > 2. If not, (meaning if the platform continues to support this directive
> on) and since it sounds like strong consideration has been given to moving
> the Installer into the CMS, is it within the CMS Team's decision making
> structure to determine whether or not the requirement can be removed?
> Not sure I understand the question. What does this have to do with the
> installer?
> > 3. If so (meaning that the platform does not accommodate magic quotes),
> might it make sense that the code to unescape magic quotes gpc be added
> until PHP 5.4 is the base requirement? (It appears that the directive is
> deprecated in PHP 5.3 and removed in 5.4.)
> We could but I don't think that's a good idea. The code involved could not
> only cause a decent performance I wouldn't wanna make any guarantees about
> its stability either.
> > 3. B. If the platform simply no longer accommodates magic quotes gpc,
> can this be handled with a system plugin? Or, is the best way to deal with
> this to link to a wiki document that explains how to deal with a hoster
> that has this enabled.
> It can be handled in the application. A system plug-in may not be a good
> choice, depends on how much input has been processed at that point and
> whether it includes any escaped parameters.
> Best regards
> Rouven
> PS: Those developers using JInput should be aware that it never was aware
> of magic_quotes, you'd have to handle that yourself.
> Thank you for clarifying this. The installer question was only relevant if
> this wasn't a real requirement, so, just set that aside.
> To summarize: Yes, it's a real requirement due to JInput and platform PHP
> runtime options that magic quotes gpc cannot be enabled. However,
> something
> can be done on the Application side of things, so, Nick was right to
> discuss it on the CMS list.
> I am sorry, Nick, for wasting your time and recommending to bring the
> discussion here. You had the right place to begin with.
> On Tue, Aug 21, 2012 at 2:57 PM, Rouven Weßling
> <m...@rouvenwessling.de>wrote:
>> On 21.08.2012, at 21:39, Amy Stephen <amystep...@gmail.com> wrote:
>> > Since i recommended Nick ask this question on the Platform list, I
>> wanted to throw in a couple of followup questions of my own - for
>> clarity.
>> > 1. Is it true that the platform version that will be part of 3.0 will
>> required magic quotes gpc to be off?
>> Yes. On all PHP options that change the runtime behavior of PHP we
>> basically opted for the one that works like PHP 5.4.
>> > 2. If not, (meaning if the platform continues to support this
>> directive
>> on) and since it sounds like strong consideration has been given to
>> moving
>> the Installer into the CMS, is it within the CMS Team's decision making
>> structure to determine whether or not the requirement can be removed?
>> Not sure I understand the question. What does this have to do with the
>> installer?
>> > 3. If so (meaning that the platform does not accommodate magic
>> quotes),
>> might it make sense that the code to unescape magic quotes gpc be added
>> until PHP 5.4 is the base requirement? (It appears that the directive is
>> deprecated in PHP 5.3 and removed in 5.4.)
>> We could but I don't think that's a good idea. The code involved could
>> not
>> only cause a decent performance I wouldn't wanna make any guarantees
>> about
>> its stability either.
>> > 3. B. If the platform simply no longer accommodates magic quotes gpc,
>> can this be handled with a system plugin? Or, is the best way to deal
>> with
>> this to link to a wiki document that explains how to deal with a hoster
>> that has this enabled.
>> It can be handled in the application. A system plug-in may not be a good
>> choice, depends on how much input has been processed at that point and
>> whether it includes any escaped parameters.
>> Best regards
>> Rouven
>> PS: Those developers using JInput should be aware that it never was
>> aware
>> of magic_quotes, you'd have to handle that yourself.
