Use array_merge to concatenate two numerically-indexed arrays; not array_push and not the array union operator: +.

$first = array('doh', 'ray', 'me');
$second = array('fah', 'soh', 'lah', 'te', 'do');

echo "Union: ", var_export($first + $second, true), "n";
echo "Merge: ", var_export(array_merge($first, $second), true), "n";

// array_push returns int, not an array:
array_push($first, $second);
echo "Push: ", var_export($first, true), "n";

The output:

Union: array (
  0 => 'doh',
  1 => 'ray',
  2 => 'me',
  3 => 'te',
  4 => 'do',
)
Merge: array (
  0 => 'doh',
  1 => 'ray',
  2 => 'me',
  3 => 'fah',
  4 => 'soh',
  5 => 'lah',
  6 => 'te',
  7 => 'do',
)
Push: array (
  0 => 'doh',
  1 => 'ray',
  2 => 'me',
  3 =>
  array (
    0 => 'fah',
    1 => 'soh',
    2 => 'lah',
    3 => 'te',
    4 => 'do',
  ),
)

Sessions are quite easy to use in PHP. One call to @session_start(), and you have a magic global called $_SESSION to store data in; associated with the user using a cookie called PHPSESSID. PHP takes care of reading and writing the session data for you, and you think no more about it.

Simple.

Time passes, and you haven’t given sessions another thought. Your site’s evolving, using more and more AJAX, and seems to be performing ‘OK’. But, there’s a niggling doubt that something’s not quite right.

For us, we realized something was wrong when we opened multiple search-results in separate windows. We could see the tabs were loading one by one, slowly.

I guess we should have paid more attention to start with. Our previous web development background revolved around enterprise-class application servers. Sessions just worked, no concurrency worries. If you happened to run into a race-condition, you worked around it using threading and locking facilities provided by the implementation language. It never occurred to us that PHP would be so different.

PHP, the way we’re running it (via mod_php) couldn’t be further from the application-server model if it tried. (By default) sessions are implemented using file-based storage, not held in shared memory ready for use by multiple threads.

Storing sessions in files means PHP has to take heavy-handed precautions against concurrent read/write access to the session – it locks the session file for the duration of a request.

The idea never occurred to us – that session management would block user-requests, stopping concurrent requests completing (think AJAX.) Fortunately the quick-fix solution is simple: call session_write_close() as soon as you’ve finished writing to the session. Depending how you use sessions, you may find a number of actions only need read-access to the session, in which case you may want to open and close the session together: @session_start(); session_write_close()

That’s the quick fix, but there are plenty of other options to explore to. A quick code-audit could identify a ton of actions, controllers and pages that simply don’t need session access at all. Now you know PHP locks the session file, you probably want to avoid calling session_start() unless absolutely necessary.

Secondly, PHP allows you to choose what type of session-management you use. You can use memcached either on its own, or with a database backing-store. You could use a MySQL back-end, or roll your own session management registered using session_set_save_handler. It’s really up to you.

Perhaps that’s the problem right there. All the session-management hooks are there because the default session management sucks. The simplicity of using sessions lulls you into a false sense of security, but make no mistake – sessions need to be handled with care if you’ve any hope of running a high-volume website.

Are your sessions managed properly?

Maybe that’s harsh: nothing’s perfect, every language has it’s strength and weaknesses, and noone ever suggested using PHP for everything.

Bearing that in mind, I’m using PHP daily, and you get used to a lot of quirks and foibles, and it’s easy to forget how truly shit it is.

Take arrays for example. Please; please take ‘em.

Skipping the “needle, haystack” parameter ordering farce, there are two things I dislike.

1. array access warnings
2. array access

First, the warnings.

The language designers must have made a choice between checked vs. unchecked array access: should this throw a warning, or shouldn’t it:

$titles = array("Philosopher's Stone", "Chamber of Secrets");

// accessing an element that doesn't exist:
$title = $titles[2];

They decided it should – it’s just a “Notice”; easily hidden with appropriate php.ini settings. I can live with that; it’s been a while, but doesn’t Java throws a wobbly when you fall off the end of an array too?

My grievance is here, when you make a typo:

$titles = array("Philosopher's Stone", "Chamber of Secrets");
$tiltes[2] = "Prisoner of Azkaban";

No errors, no warnings, no notices. Idiot-fingers just created a new array $tiltes, assigning a vitally important piece of information to a variable that shouldn’t exist!

That’s a bit stupid, isn’t it? Bit of a design-decision inconsistency?

Onto array access: it would be nice – and when I say nice, I mean obvious, natural and expected – to write:

$head = $dom->get_elements_by_tagname('head')[0];

PHP’s getElementsByTagName returns an array; we’re expecting a single <head> element, so try to skip the bullshit and access it straight-off. But we can’t, because PHP’s compiler can’t handle array-access on function return-values.

Object access? Sure, no problem. Calling a method of an object in an array inside another array is no problem:

$book['chapter']['title']->display('html')

But if you want to access an array element returned from a function, choose a different language.

Switching to MySQLi was easy and worked as described, except for one thing: I couldn’t upgrade WordPress. After a bit of sleuthing I found there’s a MySQL version check buried in the upgrade process. For the current version (WordPress 2.1.3) it’s checking that MySQL is version 4.0.0 or higher. According to the PHP documentation for mysqli, it needs to run on MySQL 4.1 or above – so the version check is redundant.

Short-term fix: follow the first few steps of the WordPress upgrade process but before running the upgrade program edit wp-admin/upgrade-functions.php and gut this function:

function wp_check_mysql_version() {
    // (version-check removed)
}

You should be able to run the upgrade program fine now.

Sadly, after only a few months our pristine code-base has become spotted with this, over and over again:

if (DEBUG) {
    echo "New user object: "; var_dump($user); echo "\\n";
}

After discovering var_export I felt like I’d improved things by switching to:

if (DEBUG) {
    printf("New user object: %s\\n", var_export($user, true));
}

I still didn’t like the fact that if (DEBUG) was appearing all over the place. So, after stumbling across call_user_func_array I’ve implemented by own debug function:

function debug()
{
    if (DEBUG)
    {
	$args = func_get_args();
	$args[0] = "<pre>" . $args[0] . "</pre>\\n";
	for ($i = 1, $l = count($args); $i < $l; $i++) {
	    $args[$i] = htmlspecialchars(var_export($args[$i], true));
	}
	call_user_func_array('printf', $args);
    }
}

Which means I can remove all the if (DEBUG) statements, leaving only:

debug("New user object: %s", $user);

I think that’s much cleaner.