I recently upgraded my webserver to Debian Jessie, which included an upgrade for Apache and PHP. This resulted in a few gotchas…

Mod_python and WSGI don’t play nicely

See my previous post on the subject…

Some PHP extensions not installed

Some PHP extensions didn’t seem to be automatically upgraded/reinstalled (these may have been ones previously only available through PECL), so:

apt-get install php5-gnupg php5-mongo
/etc/init.d/apache2 restart

New permissions

Apache 2.4 uses a different permissions (access / deny) arrangement than before, so you need to change these over.

So for example, where you have:

Order deny,allow
Allow from all

You’d now have:

Require all granted

Apache have a good guide here.

Random crashes with XCache

If you have XCache installed, you might start getting random crashes, often with an error about:

“`PHP Fatal error: Cannot redeclare class …“`

This is caused because the installer installs and activates the Zend Opcache module automatically, and you can’t run two opcode caches safely.

php5dismod opcache; /etc/init.d/apache2 restart

Anyone who has done any development with PHP will be familiar with the infamous White Screen of Death; a blank browser window indicating that something horrible has gone wrong. A common cause, for me at least, is making a method call on a null object – easy to do in an object oriented architecture.

The exact reason as to why your script has gone splat will be reported in the log file, but from a UX standpoint, giving a blank screen to your customers is far from ideal. It is particularly problematic in complicated platforms like Elgg and Known, which use output buffering and have a plugin architecture.

Here’s a quick bit of code which can catch many (all?) of these fatal errors, and at least echo something. A variation of this is already in Known. Place the code somewhere towards the start of your script…

register_shutdown_function(function () {
        $error = error_get_last();
        if ($error["type"] == E_ERROR) {
            
            // If you use output buffering, chuck away any existing buffer
            ob_clean();

            // Set an appropriate HTTP error code
            http_response_code(500);

            // Construct your error message
            $error_message = "Fatal Error: {$error['file']}:{$error['line']} - \"{$error['message']}\", on page {$_SERVER['SERVER_NAME']}{$_SERVER['REQUEST_URI']}";

            // Display a friendly message to your customers, giving them an option to email you about it!
            echo "

Sorry, FizzBuzz experienced a problem!

"; echo "FizzBuzz experienced a problem with this page and couldn't continue. The technical details are as follows:

"; echo "$error_message"; echo "

If you like, you can email us for more information

."; // You'll also want to write the error to your log error_log($error_message); exit; } });

Hope this is useful to you!

Here is the latest in a series of libraries I’ve been releasing which package up some of my often used, cut and pasted code, into reusable modules for myself and others to use.

So here is the companion piece to my previously released Web Services client library, a web services API endpoint library.

Usage

The library allows you to expose a Callable type (function, object method or static function, closure, and call it via a built in Simple Page Handler endpoint that you can attach to a virtual page (e.g. http://example.com/api).

The library will then use reflection to extract the required and optional parameters, and any default values to pass, and then pass them accordingly.

Once the code has run it’ll trigger an event which you should listen to and determine what format to output the results in based on the 'format' parameter. You might want to look at the Simple Template Library to help you here!

I’ve written an example handler that exposes a single API, but feel free to fire over any comments or questions!

» Visit the project on Github…