PHP is running more restrictive in the free hosting section, and for a good reason. too.
If someone wants an idea why, this is a god starting point:
http://cl.php.net/manual/en/features.safe-mode.php#features.safe-mode.functions
Sadly, even the providers of BB's, CMS's and Blogs often seek the quick and dirty way that just won't do in a multiple user environment. So I consider it a good idea to work together in finding ways to make that software run in a safer PHP environment.
In order to achieve this, everyone who finds blacklisted functions in distributions could check them out and if possible provide an evaluation or maybe even a code snippet that works around those security risks.
For a start, PHPWiki uses putenv() in it's lib/config.php to set the language environment. That's obviously a no-go in a multiuser environment, but as far as it seems they do that optionally. If anyone uses PHPWiki in a multilingual context and sees a good reason not to drop the setting of the global environment vars, shoot.
If there is a problem with not being able to change the environment variable, a first idea would be to look for the functions that pick the proper language for the client, and change the method to getting the user agents language setting and choose the language over a session variable maybe.
There are prolly a lot more of such cases, if anyone finds more, here might be the place.
Cheers, Stefan
If someone wants an idea why, this is a god starting point:
http://cl.php.net/manual/en/features.safe-mode.php#features.safe-mode.functions
Sadly, even the providers of BB's, CMS's and Blogs often seek the quick and dirty way that just won't do in a multiple user environment. So I consider it a good idea to work together in finding ways to make that software run in a safer PHP environment.
In order to achieve this, everyone who finds blacklisted functions in distributions could check them out and if possible provide an evaluation or maybe even a code snippet that works around those security risks.
For a start, PHPWiki uses putenv() in it's lib/config.php to set the language environment. That's obviously a no-go in a multiuser environment, but as far as it seems they do that optionally. If anyone uses PHPWiki in a multilingual context and sees a good reason not to drop the setting of the global environment vars, shoot.
If there is a problem with not being able to change the environment variable, a first idea would be to look for the functions that pick the proper language for the client, and change the method to getting the user agents language setting and choose the language over a session variable maybe.
There are prolly a lot more of such cases, if anyone finds more, here might be the place.
Cheers, Stefan