6 May 2005 - 7:04Mambo PHP Error Messages With Fix

Recently I was getting some strange PHP errors from my Mambo site. The problem was an attempt to call a member function on a variable that was not an object. The actual error was:

[client 192.168.0.3] PHP Fatal error:  Call to a member function
   getAroGroup() on a non-object in
   /usr/local/www/mambo-4.5.2/includes/mambo.php on line 347

It was obvious that this was a Mambo issues since it’s in their includes folder, and after some digging I managed to find the problem.

Problem

NOTE: This refers to a very old Mambo version. This is for information purposes only.

First we look at the offending line:

$grp = $acl->getAroGroup( $row->id );

Seems simple enough. Since PHP is painful to debug, we can simply backtrack on the code to find the issue. We look a little deeper and find that we’re inside mosMainFrame::login(…) defined on line 319. Right after that we see:

global $acl;

A simple command line search of where $acl is set should tell us more. We also need to know where the mosMainFrame object is created:

> grep -n '$acl = ' `find .`
./administrator/index2.php:26:$acl = new gacl_api();
./administrator/index3.php:26:$acl = new gacl_api();
./administrator/index.php:23:$acl = new gacl_api();
./index2.php:59:$acl = new gacl_api();
./index.php:48:$acl = new gacl_api();

> grep -n 'new mosMainFrame' `find .`
./administrator/index2.php:37:$mainframe =
                 new mosMainFrame( $database, $option, '..', true );
./administrator/index3.php:35:$mainframe =
                 new mosMainFrame( $database, $option, '..', true );
./administrator/index.php:28:$mainframe =
                 new mosMainFrame( $database, $option, '..', true );
./index2.php:33:$mainframe = new mosMainFrame( $database,
                                               $option, '.' );
./index.php:106:$mainframe = new mosMainFrame( $database,
                                               $option, '.' );

We can ignore the Administrator instances for now, since the error was occurring when I was not using the Administrator page. Now last we have to find out where our function $mainframe->login(…) is called:

> grep -n '$mainframe->login' `find .`
./index2.php:47:        $mainframe->login();
./index.php:119:        $mainframe->login();

And here is where our problem lies. If you look closely at the line numbers, the variable $acl is set after the function login is called in the file index2.php. This is unacceptable.

Solution

After some digging through the gacl_api object, it’s clear it does not use the $mainframe variable. I am still unsure of the purpose of the index2.php page, but this seems to be where the issue lies.

After changing the location of the $acl assignment to above the $mainframe assignment, our error message appears to stop.

The patch for the modified file can be found here. More information on the other patches can be found in my Mambo examples folder. For information on using the patch command, see my other atricle The Patch Command and OSS.

As expected, after a day or so of quick testing, I have not received the error again, and no other functionality seems to be hurt by the movement of this assignment.