RE: [PHP] Re: Your script possibly relies on a session side-effect which existed until PHP 4.2.3
I would have thought a genius would be able to spell geniuses. -Original Message- From: Justin French [mailto:[EMAIL PROTECTED] Sent: Thursday, March 13, 2003 2:46 AM To: chris; [EMAIL PROTECTED] Subject: Re: [PHP] Re: Your script possibly relies on a session side-effect which existed until PHP 4.2.3 on 13/03/03 11:23 AM, chris ([EMAIL PROTECTED]) wrote: Now, if any other geniouses would like to help me (or any other frustrated 4.3.1 users) figure out a solution for this vague error message, don't follow Justin's very unhelpful footsteps. Well I'll certainly never make the mistake of attempting to help you again. People make mistakes. I sincerely apologise for ruining your whole day by not reading the rest of your thread. Shsh. Justin -- 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] Re: Your script possibly relies on a session side-effect which existed until PHP 4.2.3
LOL! :D -Original Message- From: Rudolf Visagie [mailto:[EMAIL PROTECTED] Sent: 13. maaliskuuta 2003 10:56 To: [EMAIL PROTECTED] Subject: RE: [PHP] Re: Your script possibly relies on a session side-effect which existed until PHP 4.2.3 I would have thought a genius would be able to spell geniuses. -Original Message- From: Justin French [mailto:[EMAIL PROTECTED] Sent: Thursday, March 13, 2003 2:46 AM To: chris; [EMAIL PROTECTED] Subject: Re: [PHP] Re: Your script possibly relies on a session side-effect which existed until PHP 4.2.3 on 13/03/03 11:23 AM, chris ([EMAIL PROTECTED]) wrote: Now, if any other geniouses would like to help me (or any other frustrated 4.3.1 users) figure out a solution for this vague error message, don't follow Justin's very unhelpful footsteps. Well I'll certainly never make the mistake of attempting to help you again. People make mistakes. I sincerely apologise for ruining your whole day by not reading the rest of your thread. Shsh. Justin -- 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 ### This message has been scanned by F-Secure Anti-Virus for Internet Mail. For more information, connect to http://www.F-Secure.com/ ### This message has been scanned by F-Secure Anti-Virus for Internet Mail. For more information, connect to http://www.F-Secure.com/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] Re: Your script possibly relies on a session side-effect which existed until PHP 4.2.3
-Original Message-
From: chris [mailto:[EMAIL PROTECTED]
Sent: 13 March 2003 00:24
To: [EMAIL PROTECTED]
1. Registered globals are off.
2. Using super globals ($_SESSION instead of $HTTP_SESSION_VARS)
3. Setting via $_SESSION['var'] = $var instead of
session_register('var')
4. Always calling $_SESSION['var'] instead of $var
(registered globals are
off, so it really isn't an option, now is it?)
5. Unsetting via unset($_SESSION['var']) instead of
session_unregister('var')
Well, all of that is exactly what you need to do to avoid the buggy behaviour. Are
you using *any* other session_*() calls apart from session_start()?
If not, and you are 101% certain that all your pages are coded in the style you've
enumerated, then your best bet is just to change the setting of one or both of the
session.bug_compat_* configure options. If you only turn bug_compat_warn off, you
will suppress the warning whilst still retaining the old behaviour (just in case!).
But if you're sure you're not relying on the buggy behaviour, why not just turn
bug_compat_42 off? If you've got it right, your scripts will still work; if not, then
you should at least have some clues to help you find and fix the erroneous code.
As to why you're still getting the warning, even though your session code appears to
be safe, I think there's a clue in the first few words of the message itself: Your
script possibly relies Note that possibly. Why the changes you refer to
should determine whether or not the warning is evoked I have no idea, but something in
there is triggering it. Again, if you're sure that that possibly doesn't apply to
you, just turn off one or both of the configure options.
Cheers!
Mike
-
Mike Ford, Electronic Information Services Adviser,
Learning Support Services, Learning Information Services,
JG125, James Graham Building, Leeds Metropolitan University,
Beckett Park, LEEDS, LS6 3QS, United Kingdom
Email: [EMAIL PROTECTED]
Tel: +44 113 283 2600 extn 4730 Fax: +44 113 283 3211
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: Your script possibly relies on a session side-effect which existed until PHP 4.2.3
On Thu, 13 Mar 2003 10:35:29 +1100, Justin French [EMAIL PROTECTED]
wrote:
My *GUESS* is that you're using:
session_register('var')
session_unregister('var2')
rather than
$_SESSION['var'] = 'something';
unset($_SESSION['var2']);
Either that, or you're referring to session vars as $var instead of
$_SESSION['var']
Give that a go and see what happens.
Justin
on 13/03/03 8:40 AM, Dave Myron ([EMAIL PROTECTED]) wrote:
Warning: Unknown(): Your script possibly relies on a session
side-effect
which existed until PHP 4.2.3. Please be advised that the session
extension
does not consider global variables as a source of data, unless
register_globals is enabled. You can disable this functionality and
this
warning by setting session.bug_compat_42 or session.bug_compat_warn to
off,
respectively. in Unknown on line 0
register_globals = off
(error reporting set to highest possible at runtime)
I'd really like to know the cause of this too. I don't want to set
bug_compat_42 on... If there's a proper way of coding the PHP then
that's what I'd rather do, not just make PHP accept my buggy code. What
is the root cause of this problem?
-Dave
Justin apparently missed the message Dave replied to (which was mine). You
know what happens when you assume Justin? You make an ass out of you and
me. So here's a repost for you:
1. Registered globals are off.
2. Using super globals ($_SESSION instead of $HTTP_SESSION_VARS)
3. Setting via $_SESSION['var'] = $var instead of session_register('var')
4. Always calling $_SESSION['var'] instead of $var (registered globals are
off, so it really isn't an option, now is it?)
5. Unsetting via unset($_SESSION['var']) instead of
session_unregister('var')
Now, if any other geniouses would like to help me (or any other frustrated
4.3.1 users) figure out a solution for this vague error message, don't
follow Justin's very unhelpful footsteps.
Here's another odd tidbit: I was able to get rid of the message on one
page by taking out one of the selects in my MS SQL query. It mattered
specifically which column it was that I removed from the query and there
are no other variables throughout the entire project that match the
column's name. The warning only pops up on very specific pages, despite
the consistent coding style throughout the project.
Maybe I'll have better luck posting to bugs.
--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
