lime icon

Phosphorus and Lime

A Developer's Broadsheet

This blog has been deprecated. Please visit my new blog at
PHP: PHP 4 Array Namespace Bug
note: the code examples below do not reproduce the problem. For code that does reproduce it, see this post

This drives me crazy. Until it was fixed in PHP 5 (or a late version of PHP 4), PHP had a problematic namespace conflict involving associative arrays that shared their key names with other variables or arrays.

Consider this code:

$_SESSION['ARRAY'] = array( 1, 2, 3, 4);
$ARRAY = array( 'new', 'values' );

if ( !$_SESSION['ARRAY'] ) echo "you've been victimized by the PHP4 array namespace bug";

That summarizes it. I don't know if that will actually cause the error, or if it requires some other factor. But it's a variation on this theme and I'm always running into this problem because I like to do neat-freakish things like use consistent key names for related arrays. For instance, the code I was working on today:

$_DATA[$kid] = array();
$_SESSION[$kid] = $_DATA[$kid];
$_HTML[$kid] = 'html goes here';

What's even more maddening for me is that the problem doesn't occur in PHP 5, which I have on my local development server. So I won't run into the problem until I load it up to one of my remote host servers still running PHP 4.

I did come up a solution for a project today that was rather far along in development and I didn't have time to more fully refactor. It uses the serialize function.

The problem was that some session variables that I was depending on to be present after a form got submitted were being overwritten. So I serialized the session array, stuffed it in a hidden form tag and unserialized it on the next page.

page 1
// Prior to redirect to problematic page
$_serial_session_data = htmlentities(serialize($_SESSION['DATA']), ENT_QUOTES);
$_MHTML['workaround_tag'] = '<input type="hidden" name="serial_session_data" value="' . $_serial_session_data . '" />';

page 2
$_decode_data = html_entity_decode($_POST['serial_session_data'], ENT_QUOTES);
$_SESSION['DATA'] = unserialize($_decode_data);

This worked for me. Probably not the most secure technique, but this wasn't especially sensitive data. I'm hoping it's a somewhat unique situation that won't have to be repeated ad infinitum. A better solution -- only sign up with hosts using PHP 5!

keywords: PHP, array, namespace, conflict, solution, session, clash