Date: Wed, 04 Jun 2014 02:12:30 -0700 From: Daniel Friesendaniel@nadir-seen-fire.com
On 2014-06-04, 1:29 AM, Legoktm wrote:
== Extension locations == We agreed that we should require extensions to all be in the same directory, but that directory should be configurable. By default it will point to $IP/extensions.
I still do NOT like this idea.
By all means there should be one directory for extensions that are managed by a web/cli installer and the method of loading extensions from that one directory should be simple even when we're still using a php settings file. But when someone is intentionally not using that and doing complex config then we shouldn't stop them from saying to load an extension from a specific directory.
+1
What do people think of stopping caring about register_globals
I don't see any reason to continue supporting register_globals at any level. It's been turned off by default in 4.2.0 (circa 2002), deprecated in 5.3.0 and removed in 5.4.0. There's no reason to keep supporting it, it's not a good use of our resources to maintain that support.
On Wed, Jun 4, 2014 at 6:23 PM, Lee Worden worden.lee@gmail.com wrote:
Date: Wed, 04 Jun 2014 02:12:30 -0700
From: Daniel Friesendaniel@nadir-seen-fire.com
On 2014-06-04, 1:29 AM, Legoktm wrote:
== Extension locations == We agreed that we should require extensions to all be in the same directory, but that directory should be configurable. By default it will point to $IP/extensions.
I still do NOT like this idea.
By all means there should be one directory for extensions that are managed by a web/cli installer and the method of loading extensions from that one directory should be simple even when we're still using a php settings file. But when someone is intentionally not using that and doing complex config then we shouldn't stop them from saying to load an extension from a specific directory.
+1
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Hey,
I don't see any reason to continue supporting register_globals at any
level. It's been turned off by default in 4.2.0 (circa 2002), deprecated in 5.3.0 and removed in 5.4.0. There's no reason to keep supporting it, it's not a good use of our resources to maintain that support.
I very much agree with this. Having a check for register_globals being on that exits the code seems like a good way to address the issue with minimal effort.
Cheers
-- Jeroen De Dauw - http://www.bn2vs.com Software craftsmanship advocate Evil software architect at Wikimedia Germany ~=[,,_,,]:3
wikitech-l@lists.wikimedia.org