|
|
|||||||||
|
|||||||||
| |||||||||
|
|
|
| |||||||||
![]() |
|
|
«
Previous Thread
|
Next Thread
»
|
Thread Tools | Search this Thread | Rate Thread | Display Modes |
|
|
|
SlickEdit: Code in over 40 languages across 7 platforms. SlickEdits unmatched power, speed, and flexibility allows even the most accomplished developers to write better code faster. Download a free trial today! |
|
#1
|
|||
|
|||
|
Perseverence furthers
Does anyone have a forecast for how long it will be before system administrators (particularly for shared web hosting services) will disable register_globals, which causes numerous problems, not the least of which with sessions, in CGI installlations of PHP, which deny individual users the ability to disable it themselves?
|
|
#2
|
|||
|
|||
|
i guess itīs impossible to see when it will come to your application. but in general i think administrators will postpone to switch that off as long as possible cause it will cause some problems with their clients who run old applications and thatīs exactly what they want to avoid.
but i better keep that in mind - iīve to change one application at least too:-) in the long run cheers, jens |
|
#3
|
|||
|
|||
|
I suppose it will start to dwindle as administrators setting up new servers/PHP installations will start them off (at some point) with register_globals Off. Frankly I don't see the incentive for people currently using register_globals to stop if they can expect it to be enabled forever. As I've stated before in another thread, I learned my lesson to select a hosting company that will meet my needs.
However, I still have one big site kind of "trapped" on a system with register_globals On and no way for me to shut it off. Running PHP as CGI is a popular set-up and has some sometimes desirable features such as running your scripts with your user permissions, but has the undesirable feature that you can not change certain PHP settings for yourself, such as register_globals, which all mainstream shared hosting services seem to have on, so it really cuts down on the selection of hosting services. The register_globals situation also makes it impossible to write portable PHP code using certain features, such as sessions. I'd like to see it go away completely, but there is this vicious circle of system administrators that won't turn it off and users who are never going to change because they know it is not getting turned off, or worse yet because they would be forced to change hosting services to be able to write code that doesn't rely on it. So your prediction that the change will be postponed as long as possible is grim. |
|
#4
|
||||
|
||||
|
JMM,
You are being persistant. You just got flamed on your other thread for posting a thread that does not belong in this forum or section, and you are posting another. Maybe it is just me, but you are trying to drag this register_globals crap out and cause another flame war. As I stated, and I am sure that you read my post on your other thread, this is a technical forum for technical issues or problematic issues concerning PHP applications. You are posting another chit-chat thread the needs to be posted elsewhere, like in the DevShed Lounge as a number of the PHP application developers here post in that forum with chit chat crap as this.
__________________
~ Joe Penn |
|
#5
|
||||
|
||||
|
[Subject Edited]
|
|
#6
|
||||
|
||||
|
How are we supposed to know what 1000s of people are going to do? A better question would be if the PHP developers are going to make it so that it can't ever be turned on, leaving an SA no choice. But, that would be a question for the developers and would be better suited on a mailing list where the developers talk.
---John Holmes... |
|
#7
|
|||
|
|||
|
Sepodati,
It's easy to say "how are we supposed to know", and you have a point, but in many cases, such as if you want to write portable code, you can't just ignore it. Despite your sarcastic attitude and indirectness I can see that your answer to the question is "not until thay are forced to because it does not exist in PHP". Did you change my subject? |
|
#8
|
||||
|
||||
|
JMM,
as we've stated in your other thread, it is the developer's/programmer's job to write portable code. a lot of people here have had no problems doing that with sessions. i for one have developed one with register_globals off then ported it to a server with register_globals on, and i've had no problems with my codes so far. if you are a good programmer, you have to have patience in writing your codes until you get it right. as for sepodati's reply, i dont find his post sarcastic in any way - he's just stating his own opinion. you have a very aggressive attitude, and my advice to you is dont try to tick off people who are trying to help you. |
|
#10
|
|||
|
|||
|
roninblade,
Let's have a look at your code then. I have had problems, so I'd be interested to see how you avoided problems. Sepodati, You can change it to your hearts content, but you could never put a word in my mouth, let alone a sentence. You missed a spot too. Please don't change what I write. I accept the consequences of what I write -- I'll take my chances about getting helped. You'll notice that my subject does not use gimmicks to attempt to attract undue attention, the activity that the guidelines in that thread discourage. |
|
#11
|
||||
|
||||
|
Hey JMM,
What exactly are you haveing problems with. I seen in your other post a gripe about unset() and $_SESSION and how it does not work with register_globals on, is this where you are having problems because I have no problems with using unset() with $_SESSION and it does work fine without a problem...... Let us know where you are having problems........ Quote:
unset( $_SESSION[ 'some_var' ] works fine...... Last edited by jpenn : September 20th, 2002 at 10:45 AM. |
|
#12
|
||||
|
||||
|
Just use both, session_unregister and unset(). What's the big deal?
Or set a flag to determine if register_globals is on/off and call the appropriate function. ---John Holmes... PS: About your subject, get over it. It's my opinion that your doing it on purpose. Use a subject that describes your problem. |
|
#13
|
|||
|
|||
|
Quote:
If that's not possible, people, please stop replying to any of JMM topics. This kid just doesn't deserve to be here. |
|
#14
|
||||
|
||||
|
The rules say you must post a descriptive topic title that relates directly to the content of the topic. Due to the huge volume of topics, this is extremely important. You can not ignore the rules because you think you are above them. You |