Nuke integration moving right along

I'm about to check in a change to the system that is not earthshaking, but it is far reaching. I'm changing the way that we handle session variables to fix the conflicts that we've had with our PHP-Nuke integration. A little background: We handle sessions in a very simplistic manner. This is not a bad thing, IMO -- we want developers to be able to drop Gallery into their websites as cleanly as possible.Unfortunately, one of the session variables that I chose to use ($user) conflicts with a variable by the same name in PHP-Nuke.

Most of our variables are defined and used in a single .php file, so there are few or no conflicts. However, there are several variables that we use in a global context that can possibly interfere with other applications. These variables are defined in init.php or config.php:

$app 


$userDB 


$album 


$user 

These variables are used in the session:

$albumName 


$galleryVersion 


$albumListPage 


$username 


$fullOnly 

To avoid these clashes, I've decided to put all of our eggs in one basket. There is now a single global variable called $gallery that contains all of the variables above, in the following structure:
app is now gallery->app.
userDB, album, user are now gallery->XXX
albumName, albumListPage, username, fullOnly are now gallery->session->XXX
galleryVersion is now gallery->session->version (I removed the redundant "gallery")

This required changes in practically every single file. I made all these changes using perl scripts and Emacs macros around 2 AM last night, so it's entirely possible that I've introduced some bugs. I spent about 45 minutes today going through most of the functionality and then after I tested it all I realized that I had to do merge in some other changes from CVS. So what I'm saying is that the CVS trunk will be a bit unstable till we track down any issues that result from this. But on the bright side, we're now ready to start Nuke integration!