I was a bit surprised as well, as there were no hints on making old scripts compatible to PHP's new behaviour. In fact, a simple import_request_variables("gpc"); inserted somewhere at the beginning of your script (usually every script has a config.php, which is included by all other files) would be a good workaround until these scripts are rewritten to "register_globals=off".

Using import_request_variables() is close, but since it became available in PHP 4.1.0 it's not ideal, and it only deals with GPC.  Using extract() will be closer, something like:

  // register a lot of vars if register_globals = off
  if (!ini_get('register_globals')) {
    $types_to_register = array('GET','POST','COOKIE',
                               'SESSION','SERVER');
    foreach ($types_to_register as $type) {
      if (@count(${'HTTP_' . $type . '_VARS'}) > 0) {
        extract(${'HTTP_' . $type . '_VARS'}, EXTR_OVERWRITE);
      }
    }
  }

This does not rely on the variable_order directive, which I prefer not to do, but it could :)  Maybe someone wants to add ENV, or subtract some, or add a prefix.  All possabilities to think about.

Also note that default for register_globals became "off" in PHP 4.2.0 but as of PHP 4.1.0 it was recommended to have it off.

This is a website problem (not in docs) and is rather critical as the explanations in tut.php make it sound as if register_globals is always on in PHP (like in the old days).

But the example code now uses predefined vars, which is good.  Although it should mention that superglobals came into existence in PHP 4.1.0

fixed.

This page needs a complete rewrite, this is still open.  Many paragraphs are outdated and written during a time when the register_globals directive didn't even exist (always on).  A simple note on the bottom that essentially says: "the above method is not preferred." isn't enough. Complete newbies read tut.php

Also, superglobals becaming available in 4.1.0 should be mentioned and linked.  And, all examples should work with register_globals = off.  Also, for example, $HTTP_USER_AGENT is mentioned in a few places yet this isn't available with register_globals off.

And lastly, tut.php needs more links to related man pages.  Like the used functions and predefined variables, if statement, forms, etc.

I'm currently going to fix this page now.  I'm going to ensure that all the examples on the page work.  Expect a commit a bit later this morning.

Okay I've just done a cvs commit on tut.php which has links to the strstr manual page and the control structure page, as well as changed the variables listed to way they would be set if register_globals=off in the php.ini file.

I've implemented some of philip@php.net's suggestions so far.  I'll get around to going thru the entire phpweb and
changing all the code to use the register_globals=off since newbies also like to view the source code to see how the webteam do various things on the site.

can we please stop with the Register Globals bashing? there is nothing wrong with it. We simply switch it of by default as there __could__ be security risks if users are not aware of it's awesome power.

Please also do not 'fix' phpweb to not use register globals. if you must, add a comment on the show source page.

It's not a matter of being bashed, it's a matter of tut.php working with register_globals on or off.  The example code  should work with the default settings of php.ini-dist, and it will (but does not currently as of PHP 4.2.0).  Users can read about register_globals if they want to enable, and code accordingly.

This bug has been fixed in CVS. You can grab a snapshot of the
CVS version at http://snaps.php.net/. In case this was a documentation 
problem, the fix will show up soon at http://www.php.net/manual/.
In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites.
Thank you for the report, and for helping us make PHP better.

On a related note, today tut.php was moved to phpdoc (chapters/tutorial.xml).  It has been reworded to not rely on register_globals.