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
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 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 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
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
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
[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] PHP 4.2 - Win32 - command line PHP buffering output?
Hi all, I'm trying to make the script below run, it is supposed to print a message and then wait for user input and then print another message and wait again. Instead, what it is doing is waiting for all the user input to be entered before printing anything, and once entered printing all of the messages and all of the input... I associated php-cli.exe with all .php files and have tried running it from command line with -a, -f, -q and < testscript.php ... What am I doing wrong? (I remember I once had this type of thing working back around PHP 4.04) Thanks, -Garth -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] PHP 4.2.ORC1 - SID gets deleted
Hi, I'm not sure where to post this, neither if I should report this as a bug, because I'm not sure if it is one at all. I installed php 4.2 ORC1 lately and encountered a strange session problem. The following script reproduces this problem: Link"; echo ''. SID.""; echo session_id(); ?> As you can see, the script starts a session and then generates a link to itself. When I call this script the first time, the session gets created as expected. Also the link is generated correctly, if I block the session cookie. But when I click on that link, SID is empty on the following page (that's the same script again, of course), although the session still exists. So the output gives me an empty SID, but a correct session id. The same script does work with 4.1.2. Does any explanantion for this behaviour exist? Or is it a bug? trans-sid is disabled and not even compiled in. But that shouldn't be a problem I think, because SID is the alternative to trans-sid. Can anybody confirm this behaviour? Or should I submit a bug report? Greetings Carsten -- Carsten Saathoff ...powered by Linux ICQ #52558095 The gods are great, I am the greatest! (Borknagar) -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
