This file is added to the Register Globals Patch Files
because Richard Bentley added this file to v1.3 of the
original Register Globals patch instructions.  You may find
it useful if you have problems getting certain contributions
to work when Register Globals is set to 'Off' in php.ini

Rhea (Vger)

---------------------------------------------------------------

Register Globals contribution for OSCommerce - Richard Bentley 13/01/2005

--------------------------------------------------------------------------------
SOME HINTS AND TIPS FOR FINDING REGISTER GLOBALS PROBLEMS IN OTHER CONTRIBUTIONS
--------------------------------------------------------------------------------

For anyone who is wanting to make some other contribution (or their own code) work when register_globals is switched off, you might find the following bit of code very useful. All it does is print out the global data arrays. Then, when you exercise your code, it allows you to see which variables are being used and so may need attending to in your code. I usually add this to the end of the application_top.php file. As you can see, you select which arrays to print simply by commenting the appropriate lines in/out. Most of the time you will only need to monitor the POST and GET variables, but it's always worth checking the COOKIE array too if you still have problems.

-CODE------------------------------------------------

function px(&$arr, $arr_name)
{
 if (sizeof($arr))
 {
   print "---------- <br />";
   print $arr_name . "<br />";
 }

 foreach($arr as $key => $v)
 {
   print " ".$key." -> '".$v."'<br />";
 }
}

px($_GET, "GET");
px($_POST, "POST");
// px($_COOKIE, "COOKIE");
// px($_SERVER, "SERVER");
// px($_ENV, "ENV");
// px($_FILES, "FILES");

-----------------------------------------------------

AN EXAMPLE OF HOW TO MAKE SOME OTHER CONTRIBUTION WORK WITH REGISTER GLOBALS SWITCHED OFF
-----------------------------------------------------------------------------------------

Let's say, I've just added the 'Really Annoying Flash Animation' contribution to my OSC code and I'm finding that there are problems in the admin section which iI suspect are due to register_globals issues. OK, what do I do ?

Well, first thing is to add the above code snippet to the bottom of .../admin/includes/application_top.php (if my problem was in the catalog section, I would add it to .../catalog/includes/application_top/php). I then bring up the page that is causing me problems.

My ficticious problem is that when I edit the settings for this contribution, things seem to not be quite right - say I find that the 'Annoyance Factor' setting seems to be getting ignored. To see what is going on, I exercise the page concerned by changing some settings, one of which is the 'Annoyance Factor' value. I really hate my customers and want to drive them all away, so I set the 'Annoyance Factor' it to its maximum value of 100%

Ok, I then hit the 'save' button.

The bit of code that I added to application_top now prints out the global variables. I see that in the POST section there is a variable called 'annoy_factor', and look - it has a value of '100' - Looks like this is my candidate !

So....

I now go to the admin configuration page code and look for this variable name. And there it is !.....

-CODE------------------------------------------------

if (isset($annoy_factor))
{
  ..bla bla bla....
}

-----------------------------------------------------

I may well find that it's used in a couple of other places too.

OK, so now I've found the variable, what's the problem ?

The problem is that the variable $annoy_factor won't exist ! Why ? Because we have switched off register_globals ! What enabling register_globals does is to take the global variables defined in the arrays $_POST, $_GET, etc and give them all individual global names. So, when we switch register_globals off, this mechanism is suppressed. For more information, go to the PHP support site.

To fix this problem we can do one of two things, thus :

--------
OPTION 1
--------
Somewhere (probably near the top of the file, but not necessarily - I'm afraid you are on your own here), you could add the following line...

-CODE------------------------------------------------

link_post_variable('annoy_factor');

-----------------------------------------------------

This will basically do the job that having register_globals enabled would have done (ie - it will create the $annoy_factor variable).
This option is possibly the one to go for if it all starts to look very complicated and you loose your bottle !

Note that the function 'link_post_variable' is provided by the 'Register Globals' contribution, so this fix is no good if I wanted to email the author of the 'Really Annoying Flash Animation' contribution with my fix so (s)he could include it into the next version of their contribtution.

If you find the code complains and tells you that the function link_post_variable() is not defined, then you will need to include the file .../includes/functions/general.php or .../includes/functions/general.php, but I think it is unlikely you will have this problem because general.php is included by default by application_top.php so unless you are doing something odd, you'll include it anyway in your code.

--------
OPTION 2
--------
If you can do it, this is a better option than OPTION 1; it is much tidier and it is more 'correct'. It involves changing the existing variable reference(s) to point to the globals arrays (which is what the author of the 'Really Annoying Flash Animation' contribution should have done in the first place). For example, change this...

-CODE------------------------------------------------

if (isset($annoy_factor))
{
  ..bla bla bla....
}

-----------------------------------------------------

...to this...

-CODE------------------------------------------------

if (isset($_POST['annoy_factor']))
{
  ..bla bla bla....
}

-----------------------------------------------------

You may find that some code uses the global variable array name $HTTP_POST_VARS[...] instead of $_POST[...]. The two are basically the same thing but $_POST is the preferred method. $_POST also has one advantage of using $HTTP_POST_VARS, and that is that with $HTTP_POST_VARS you will have to declare its use if you use it within a function. So, if our example code above was actually within a function, and we used $HTTP_POST_VARS instead of $POST, we would also have to add the line...

-CODE------------------------------------------------

global $HTTP_POST_VARS;

-----------------------------------------------------

...before we referred to it elsewhere in our code. This 'global' statement must be within the body of the function. With $_POST, you don't have to do this because it's done automatically for you by the PHP engine (actually, it's just not needed !).

--------------------
After applying one of the above fixes I should find that this variable will work. Of course, there could be other variables that are also causing problems and one or more of the other variables that I have not adjusted yet could still mean that our annoy_factor function is still broken until I also fix those.

--------------------
The above example refers to a POST variable, but exactly the same thing applies to GET variables. You may also find that a contribution adds a new SESSION variable or even a new COOKIE variable, though this is rare.

Anyway, I hope this gives you some pointers. If you find a fix for a particular contribution then feel free to post it to the support forum so it can help others who are using the same code. Be sure to mention the version of the' register globals' contribution that you are using and the version of the other contribution you are fixing ! Better still, get the author of the contribution to fix his / her code and put up a fixed version.

-- end --

