Interesting (read: BAD) side effect, with caching on

On http://drupal.org/node/213867, what file did you add that first block of code? (I've included it below):

global $user, 
        $ip_subnet_check_arr,
        $ip_subnet_check;

$ip_subnet_check_arr = explode(".", $GLOBALS['user']->hostname);

$ip_subnet_check = $ip_subnet_check_arr[0] . "." . $ip_subnet_check_arr[1];

// If we're not on user/login or node/357 and we have the correct IP, then set the user;
if ($_GET['q'] != "user/login" && 
   $_GET['q'] != "node/357" && 
   $GLOBALS['user']->uid == "0" && 
   $ip_subnet_check == "192.168"
) {
   $GLOBALS['user']->uid = "29";
}

if ($title == 'Access Denied') { 
  header( 'Location: http://www.engr.sjsu.edu/admin/login/?destination=' . substr($_SERVER['REQUEST_URI'],1) ); 
  exit; 
}

Did you get a chance to look at: http://drupal.org/node/316052#comment-1064286

Beekerstudios,

It looks like I may be changing the ipAuthenticator's authentication towards your solution where the UID is assigned. It seems that there are two issues going on here. One with the aggressive caching, and the other with the menu caching. I have a workable solution at (http://drupal.org/node/316052) for the aggressive caching issue. But to solve the menu caching issue, I may have to go the route of assigning a UID. My last comment at: http://drupal.org/node/316052 describes the process of how to do that.

A note, just to summarize the current situation I am facing:

With the 5.x-1.x-dev version, the menu caching issue is fixed - menus show when they are supposed to - even when used in conjunction with the menu_per_role module. I thought that maybe I could disable the settings.php code suggested in http://drupal.org/node/316052#comment-1084735 with this new UID-based authentication, but a PHP error concerning the url() function not existing caused me to go back to including that code. Emptying my caches worked sometimes, but ultimately I went back to including the cache code in the settings.php.

Is there a "cleaner" way to force the cache to be ignored/emptied? Perhaps something I can include in my template.php or in the .module file itself?

Otherwise, the dev version is a great improvement and is working really well for myself and about 40,000 others here at my school district!

Kudos.

PCorbett,

In terms of there being a cleaner way of implementing a work around other than fooling around with the settings.php file, I haven't seen one yet. The reason being is that in the bootstrap of Drupal when aggressive caching is enabled, all of the module's are circumvented completely. Meaning that an anonymous person, not logged in, will only receive content pulled directly from the cache table in the database. No hooks are called to alter or add to any content. The result is a significantly speedier page load, but also takes away the possibility of having dynamic content for anonymous website visitors.

So the way around this is to temporarily disable the aggressive caching if an IP Authenticated user is accessing the site. We can do this by adding code/logic early enough in the Drupal bootstrap process that disables the aggressive caching. The settings.php file is the perfect place for this outside of any core Drupal files that are over written during an update.

Do you think your server will be too taxed if you turn the aggressive caching off? How many people visit and explore your site who are not authenticated in anyway? If it is 50 percent, then you may want to keep aggressive caching on. But if it is lower like 5%, then you may not need to have aggressive caching turned on.

I'll have to look into the error that you received. Please keep in touch, I'd like to understand better how you are using the module.

Thank you,
Jonathan

Thanks for your help. I actually don't have AGRESSIVE caching turned on... just "Normal." CPU usage becomes an issue for my server when caching (normal) isn't turned on... I understand the agressive issue, but for whatever reason, it's giving me issues just being on normal...