Or, in this case, replace “dream” with “framework.”

"You created a work-around by over-riding a function to reference a function that wrapped around a function that we were over-riding? Genius!"

In Inception, the movie, if you die in a dream within a dream within a dream you are stuck in limbo – never to wake up. When dealing with a template with a custom framework that interfaces with Joomla that has its own framework, what happens if you have an error deep in the middle of all that code?

Most of the time PHP sends out friendly errors telling you what is broken, where and why. However, if code is stuck in infinite recursion you end up timing out and/or exhausting your available memory. In simpler times, you would only have to sift through one or two scripts to find the break. With frameworks within frameworks it’s a whole different story. Good times…

My client wanted to move to the cloud. I was happy to set them up on an instance with Amazon’s EC2 service. Their site uses Joomla (1.5.22) along with a YooTheme template which, in turn, uses Warp (5.5.15, developed by the YooTheme folks). Everything was moving along nice and smooth until I started to test the newly migrated site with the Joomla module caching turned on.

I load up the home page, no problem. Then, refreshing the home page to pull it from cache…

Crash.

Memory exhausted?

PHP Fatal error: Allowed memory size of xxxxxxxxx bytes exhausted (tried to allocate xxxxxx bytes)…

It really didn’t matter how much memory I gave PHP by updating the “memory_limit” parameter in /etc/php.ini. The application had a voracious appetite for memory. Nothing could satisfy it. That told me that I was dealing with either recursion or some ridiculous database issue (like pulling a million records into memory). I ruled out the database issue and started to focus on infinite recursion as the culprit.

Poking around the code, I found the break point was in the Warp framework’s directory in ./yoo_enterprise/warp/systems/joomla.1.5/helpers/system.php with the following code:

if (!function_exists('mb_strpos')) {
     function mb_strpos($haystack, $needle, $offset = false) {
     return JString::strpos($haystack, $needle, $offset);
     }
}

I commented out that function to discover I hadn’t set up the new box with multibyte support (http://php.net/manual/en/book.mbstring.php).

Call to undefined function mb_strpos()

Oops. However, it would seem the developers of Warp had accounted for this. After all, the comment right above that nifty function stated the following: “mb_strpos function for servers not using the multibyte string extension”

How thoughtful. So why was this failing?

Digging deeper, I looked into the JString method in the Joomla libraries in ./libraries/joomla/utilities/string.php and found this bit of useful code:

function strpos($str, $search, $offset = FALSE)
{
     if ( $offset === FALSE ) {
          return utf8_strpos($str, $search);
     } else {
          return utf8_strpos($str, $search, $offset);
     }
}

Ah, I see. Joomla devs seemed to have created a useful function for dealing with utf8. I wonder what that function looked like…

Digging into ./libraries/phputf8/mbstring/core.php I found the following:

function utf8_strpos($str, $search, $offset = FALSE) {
     if(strlen($str) && strlen($search)) {
          if ( $offset === FALSE ) {
               return mb_strpos($str, $search);
          } else {
               return mb_strpos($str, $search, $offset);
     }
} else
     return FALSE;
}

At this point in the movie Leonardo Dicaprio spins his totem and you wonder if it will ever stop spinning. Well, it will… when it runs out of memory. Yes, Warp’s mb_strpos calls Joomla’s utf8_strpos which, in turn, calls mb_strpos which, of course, has been overwritten by Warp’s mb_strpos which calls Joomla’s utf8_strpos and so on and so on…

Satisfied that I figured out what was the causing the error, I ran the following commands on the box:

sudo yum install php-mbstring.i686
sudo /etc/init.d/httpd restart

And… it works. The site — not the code. I left that broken and tried to report the bug to the devs. Now that I have multibyte support the site bypasses that first function that started this bad dream in the first place.

Of course, I could have just installed php-mbstring as soon as I figured out I needed it but where’s the fun in that when finding recursive black hole code is so much more fun and time consuming?

Update… 5/6/2011 @ 9:25AM
After emailing the devs (I could find no bug tracking system), the devs replied that there actually is a core Joomla function to deal with this issue in libraries/phputf8/native/core.php.

function utf8_strpos($str, $needle, $offset = NULL) {
    if ( is_null($offset) ) {
        $ar = explode($needle, $str);
        if ( count($ar) > 1 ) {
            return utf8_strlen($ar[0]);
        }
        return FALSE;
    } else {
        if ( !is_int($offset) ) {
            trigger_error('utf8_strpos: Offset must be an integer',E_USER_ERROR);
            return FALSE;
        }
        $str = utf8_substr($str, $offset);

        if ( FALSE !== ( $pos = utf8_strpos($str, $needle) ) ) {
            return $pos + $offset;
        }
        return FALSE;
    }
}

He went on to tell me that the decision to include native/core.php resides in libraries/phputf8/utf8.php

Looking at utf8.php, I find the following:

/**
* Load the smartest implementations of utf8_strpos, utf8_strrpos
* and utf8_substr
*/
if ( !defined('UTF8_CORE') ) {
    if ( function_exists('mb_substr') ) {
        require_once UTF8 . '/mbstring/core.php';
    } else {
        require_once UTF8 . '/native/core.php';
    }
}

Yes, that’s right… the native implementation is loaded if mb_substr is defined. Since the Warp code is calling the JString method after it defines its own version of mb_substr… well, you get it.

Update… 5/6/2011 @ 9:45AM

The devs responded with the following fix:

This should be placed in warp/systems/joomla.1.5/helpers/system.php just before the first multibyte (mb_) check:

/* Load string class */
require_once(JPATH_ROOT.'/libraries/joomla/utilities/string.php');

By loading that first, Joomla does its job by establishing the correct utf8 function call for the Warp system to use. You can now wake up.

However, it should be noted that performance takes a big hit through the Joomla utf8 work-around. If you can get multibyte support installed, do that first.

QuickTime failed to initialize. Error #0

Turning to Google (the modern equivalent of asking my dad which would usually evoke a “look in the dictionary/encyclopedia”), I found several helpful tidbits that didn’t help.

One bit of advice called for uninstalling Quicktime, using Microsoft’s Windows Installer Cleanup (which was useless since there were no remnants of Quicktime left to clean), restarting then reinstalling Quicktime.  No luck.  Same problem.

The next solution was to go to Control Panel–>Quicktime–>Browser Tab–>MIME Types and reset that.  No luck.  Same problem.

The third solution has too many specific steps to paraphrase:

1. Close Firefox or Mozilla Suite.
2. Delete all “npqtplugin*.dll” files (npqtplugin.dll, npqtplugin2.dll, etc.) from your browser’s installation directory plugins folder.
3. Delete all “npqtplugin*.dll” files from the Quicktime plugins folder (usually C:\Program Files\QuickTime\Plugins).
4. Go to “Start -> Control Panel -> Quicktime -> Browser (tab) -> Mime Settings” and reselect your preferred media types.

If you still have problems, close Firefox or Mozilla Suite, open the “Mozilla” or “Firefox” folder in the profile folder location and delete the file “pluginreg.dat”

Then, while reading through a bunch of search results, I happened to read a summary that mentioned a different problem with Firefox when set in compatibility mode.  I suddenly remembered that I changed this setting because of performance issues with Firefox.  Righ-click Firefox’s Alias, Go to Compatibility Tab, Uncheck “Run this program in compatibility mode for:” and… Fixed!  Phew!

I LOATH it when software is added without an easy way to remove it.  After much research (okay, I Googled the the heck out of it), I came across this extremely easy and helpful tip:

Start>Run…>Copy and paste the following
msiexec.exe /x{78d944d7-a97b-4004-ab0a-b5ad06839940}

Don’t forget to click, “OK.”

Ta-da and poof!

How do we know?� Our monkeys work there, of course.� But, seriously, that IS a huge sale.

“We all know the expression monkey see, monkey do. But should the saying really go monkey hear, monkey do? Recent studies are finding that the language abilities of some monkeys are more sophisticated than previously believed. Much more sophisticated.”