Re: [PHP] PHP 4.2
On Sunday, June 23, 2002, at 09:06 AM, Pekka Saarinen wrote: Most virtual server users have no means to set PHP.INI to their liking so changes like that should be done in longer time span to let developers update the software _before_ changes in PHP happen. What about ini_set() ? http://www.php.net/manual/en/function.ini-set.php Erik Price Web Developer Temp Media Lab, H.H. Brown [EMAIL PROTECTED] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP 4.2
On Monday 24 June 2002 21:29, Erik Price wrote: On Sunday, June 23, 2002, at 09:06 AM, Pekka Saarinen wrote: Most virtual server users have no means to set PHP.INI to their liking so changes like that should be done in longer time span to let developers update the software _before_ changes in PHP happen. What about ini_set() ? There are quite a few config settings which cannot be altered using ini_set(), register_globals being one of them, although that can be set using .htaccess files. -- Jason Wong - Gremlins Associates - www.gremlins.com.hk Open Source Software Systems Integrators * Web Design Hosting * Internet Intranet Applications Development * /* Real Users find the one combination of bizarre input values that shuts down the system for days. */ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP 4.2
On Monday, June 24, 2002, at 10:55 AM, Jason Wong wrote: There are quite a few config settings which cannot be altered using ini_set(), register_globals being one of them, although that can be set using .htaccess files. I see. I must have misread this page: http://www.php.net/manual/en/function.ini-set.php The terms PHP_INI_SYSTEM and PHP_INI_ALL aren't totally clear in the right-hand column titled changeable. Erik Erik Price Web Developer Temp Media Lab, H.H. Brown [EMAIL PROTECTED] -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] PHP 4.2
You can use the HTTP_*_VARS for now, but they are depreciated. They will work right now on most any version of PHP. I would just maintain two different versions, one for PHP 4.2+ and one for earlier versions. Sure, it's a little more of a pain...though... ---John Holmes... -Original Message- From: Simon Troup [mailto:[EMAIL PROTECTED]] Sent: Sunday, June 23, 2002 7:46 AM To: [EMAIL PROTECTED] Subject: [PHP] PHP 4.2 I've written a small freeware script that gets installed on a variety of different platforms running various PHP versions. I've read through the manual about the super global arrays and how post and get vars are no longer registered by default, but am confused about when it would be a good idea to upgrade the script. If I change everything in the script and use $_GET and $_POST etc. then those people who are still using earlier versions won't be able to upgrade. Does anyone know what the uptake of the latest version is? What is everyone else doing about this? If I were developing for one client it wouldn't be a problem as obviously you'd know what you were developing for. I'd just like some feedback on when would be a good time to upgrade the scripts while causing the minimum disruption and maintaining maximum happy users. Thanks Zim -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP 4.2
At 6/23/2002, you wrote: I've written a small freeware script that gets installed on a variety of different platforms running various PHP versions. I've read through the manual about the super global arrays and how post and get vars are no longer registered by default, but am confused about when it would be a good idea to upgrade the script. If I change everything in the script and use $_GET and $_POST etc. then those people who are still using earlier versions won't be able to upgrade. Does anyone know what the uptake of the latest version is? What is everyone else doing about this? If I were developing for one client it wouldn't be a problem as obviously you'd know what you were developing for. I'd just like some feedback on when would be a good time to upgrade the scripts while causing the minimum disruption and maintaining maximum happy users. Hi, I have used if (isset($_SERVER)) $PHP_SELF = $_SERVER['PHP_SELF']; to make $PHP_SELF work on all PHP's. Then you have to use $HTTP_GET_VARS and $HTTP_POST_VARS to pass vars. This way the script will work with globals on and off. I really hate the way PHP 4.2 introduced the new default installation with globals off, as they knew it will instantly force almost all coders to update their code. It took two weeks to make those changes on my rather large application. Most virtual server users have no means to set PHP.INI to their liking so changes like that should be done in longer time span to let developers update the software _before_ changes in PHP happen. Pekka http://photography-on-the.net/ - Pekka Saarinen http://photography-on-the.net - -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] PHP 4.2
on 23/06/02 11:06 PM, Pekka Saarinen ([EMAIL PROTECTED]) wrote: Most virtual server users have no means to set PHP.INI to their liking so changes like that should be done in longer time span to let developers update the software _before_ changes in PHP happen. The changes and recommendations to make changes to your code were made in the release notes of 4.1.0 I think, which was AGES ago. My best guess is mid-February 2002, but it may have been earlier. http://www.php.net/release_4_1_0.php If you do a clean install, yes, register globals will default to OFF, but for an upgrade install of 4.2.x, it *should* pick up your old php.ini setting of ON. It took me a week or so to update my code as well, but I look at it as a good move... my code is now more secure for starters. Justin French -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
