Calling my own function inside Custom Header / Custom Footer

[JohnDBush]

Hello all,

I am running 1.6.08.   

I have a custom header and custom footer.   

I know how to access $_SERVER variables using the "superCage".   

My custom header STOPPED WORKING, I think, when I installed 1.6.08, but I am not sure.    
(perhaps it's been broken for a while but nobody told me until now)   

Below is the code with personal data replaced by joke data.  The function, geo_test is failing, whereas it works perfectly outside the scope of CPG within other pages on the site, using the same "require" statement.   I think that CPG is shutting off all error messages so I can't see what's going on.   Inside CPG, in this custom header, the geo_test function ALWAYS fails.   However the function is in fact called, and the $LOGFILE does get written to, but rejecting every IP address as un-allowed.   It's not a logic problem because the function works properly everywhere else.   

Does anyone know what might be causing the problem?  Certain variable scopes?  Does CPG expect server variables in my own included functions to be pulled out of the superCage also?   The geo_test function has one $_SERVER[] variable and one reference to "__DIR__".    Should they be caged?

Any tips for how to debug this more effectively?  Thanks in advance!

CUSTOM HEADER:

Code Select Expand

     
     <?php
      
         global $superCage;
         global $GEOSTRING;
      
      // Without this, Gallery is UTC time
      
         $TIMEZONE = "America/New_York";
         date_default_timezone_set( $TIMEZONE );
         
      // Replace $_SERVER references with caged Inspekt references:
      
      // $myROOT = $_SERVER["DOCUMENT_ROOT"];
         $myROOT = $superCage->server->getEscaped('DOCUMENT_ROOT');
      // $myIP = $_SERVER["REMOTE_ADDR"];
         $myIP = $superCage->server->getEscaped('REMOTE_ADDR'); 
      // $myURL = $_SERVER["REQUEST_URI"];
         $myURL = $superCage->server->getEscaped('REQUEST_URI'); 
         
         require $myROOT."/LyBrary/PHPFunctions.php";
      
         $LOGSTUB = "GALLERY";
         $LOGFILE = $myROOT."/Dada/".$LOGSTUB."_Visits.log";

     // This redirects to a 403 page and writes to $LOGFILE if user is not allowed:

         $GEOSTRING = geo_test ( $myIP, $LOGFILE, $myURL );    // <---------------- IS CALLED BUT ALWAYS FAILS WITHIN
  
     // Otherwise it continues...

       print '<br><table width="100%">';
        print '<tr>'; 
       print '<td valign="middle" align="left">';
        print '<a href="http://www.mycrazywebsite.wheee/">';
        print '<img src="/Pics/lion-orange-medium.png" height="100"></img></a></td>'; 
        print '<td valign="middle" align="center" >';
        print '<span style="font-size:225%; font-weight:bold;">Our Class Gallery</span>';
        print '<br></td>';
       print '<td valign="middle" align="right">';
        print '<a href="http://www.mycrazywebsite.wheee/">';
        print '<img src="/Pics/lion-orange-medium-left.png" height="100"></img></a></td>'; 
       print '</tr>';
        print '</table>';
      
      ?>
     

FYI, the CUSTOM HEADER calculates the GEOSTRING and the CUSTOM FOOTER displays the value of GEOSTRING.    But if the GEOSTRING is not valid the user is bounced before getting to download them.   (I've seen too many Huawei and OPPO cell phones scraping the site so these measures are required.  I don't want my friends' faces showing up on fake passports.)

-JB

[ron4mac]

You can set debug mode on the maintenance settings.

Then also make a temporary modification to include/debugger.inc.php. Just put a return right after the start and stop functions.

Code Select Expand

    function start() { return;

Code Select Expand

    function stop() { return;

Those things should allow you to see any errors.

[JohnDBush]

Thanks ron4mac!

This was tricky because I had to disable my custom header and footer just to get logged in as the Admin to change the debug settings, because those two pieced of code get executed even when loggin in as Admin.    But your suggestion worked.  :-)

Then I re-enabled the header/footer code and hit refresh to learn that the $_SERVER['DOCUMENT_ROOT'] reference failed, producing "" (Null string) instead of the name of the document root directory.   Therefore all my pathnames for subsequent file_get_contents calls were bogotoid.   I guess part of the blame is mine for not having adequate error handling.

EG:

Code Select Expand



$ROOT = $_SERVER['DOCUMENT_ROOT'];

// The lists below are 2 dimensional non-associative arrays:
//   [ [ "0", "1" ], [ "0", "1" ], ... [ "0", "1" ] ]
//   Column 0 is the value, column 1 is a description.

// FORBIDDEN_ASNS
   $JSON_ARRAY = json_decode (file_get_contents($ROOT."/xxx/yyyy/FORBIDDEN_ASNS.json"),TRUE);
   $FORBIDDEN_ASNS = array_column ($JSON_ARRAY, "0" );
   $FORBIDDEN_ISPS = array_column ($JSON_ARRAY, "1" );

// ALLOWED_ASNS
   $JSON_ARRAY = json_decode(file_get_contents($ROOT."/xxx/yyyy/ALLOWED_ASNS.json"),TRUE);
   $ALLOWED_ASNS = array_column ($JSON_ARRAY, "0");
   $ALLOWED_ISPS = array_column ($JSON_ARRAY, "1");

// VALID_COUNTRIES
   $JSON_ARRAY = json_decode(file_get_contents($ROOT."/xxx/yyyy/VALID_COUNTRIES.json"),TRUE);
   $VALID_COUNTRIES = array_column ($JSON_ARRAY, "0");



So as I suspected the "Inspekt" superCage was still in effect within the function that was called from within the Custom Header php.

Now, if I update the code to use Inspekt semantics to extract the name of the root directory, everything else on the website will break, so I am going to have to maintain two separate versions of the above code from now on...   one for use inside CPG, using superCage to get the DOCUMENT_ROOT, and one for use everywhere else.  I'm not going to adopt Inspekt at my root level because I personally think it's useless.    I might just become willing to say to hell with it and just hard code the name of the Document Root.   As Johnny Carson would say, "Weird crazy wonderful stuff, let's welcome a great wacky comedian who can always stir things up, 'superCage' !!!"

[ron4mac]

In your CPG custom header, you could just reconstitute what you need in the external code.

Code Select Expand


// restore things needed externally
$_SERVER['DOCUMENT_ROOT'] = $superCage->server->getEscaped('DOCUMENT_ROOT');

require $myROOT."/LyBrary/PHPFunctions.php";
// etc


[JohnDBush]

Thanks again, ron4mac!

Since many accesses to the $_SERVER variables in my PHP library do not occur from CPG, I created the following function to resolve the issue:

Code Select Expand


function SERVER_GET ($indexname)
{
   global $superCage;
   
   if ( isset ($superCage) )   // this will be set if called from within CPG
   {
        $data = $superCage->server->getEscaped($indexname);
   }
   else
   {
     $data = $_SERVER[$indexname];  // cannot use this form when called from within CPG due to global variable containment
   }

return ($data);

}


now, all instances of obtaining the value of DOCUMENT_ROOT (or any other server global) are replaced with, FOR EXAMPLE,

Code Select Expand


$ROOT = SERVER_GET ("DOCUMENT_ROOT"); 


Thus it won't matter whether the function was called from within CPG or a different page.

So far, this little interlude function is working fine.

I appreciate the help you provided.

-JDB