Do you need Zend Framework training or consultancy? Get in touch!

Installing 32 bit packages on Ubuntu 14.04

This had me stumped for a bit, so I've written it down. If you have a 64 bit version of Ubuntu and want to install a 32-bit package, you simply add :i386 to the end of the package name like this:

$ sudo apt-get install libstdc++6:i386

However, this didn't initially work for me as apt-get couldn't find the package:

$ sudo apt-get install libstdc++6:i386
Reading package lists... Done
Building dependency tree       
Reading state information... Done
E: Unable to locate package libstdc++6
E: Couldn't find any package by regex 'libstdc++6'

It turned out that my installation only had the 64 bit architecture configured which you can tell by running:

$ sudo dpkg --print-architecture
$ sudo dpkg --print-foreign-architectures

Note that there are no foreign architectures, which is the problem.

The solution is to add the i386 architecture first:

$ sudo dpkg --add-architecture i386
$ sudo dpkg --print-foreign-architectures

That's better! Now we need to run an update:

$ sudo apt-get update

Don't forget this update! I did and wondered why I still had the problem…

Now the installation of the 32-bit package works:

$ sudo apt-get install libstdc++6:i386
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following extra packages will be installed:
  gcc-4.8-base:i386 gcc-4.9-base:i386 libc6:i386 libgcc1:i386
Suggested packages:
  glibc-doc:i386 locales:i386
The following NEW packages will be installed:
  gcc-4.8-base:i386 gcc-4.9-base:i386 libc6:i386 libgcc1:i386 libstdc++6:i386
0 upgraded, 5 newly installed, 0 to remove and 1 not upgraded.
Need to get 4,342 kB of archives.
After this operation, 11.3 MB of additional disk space will be used.
Do you want to continue? [Y/n] Y
... lots of lines as the library installs ...

All done!

Slim 3.0 RC2 Released

I released Slim 3 RC 2 today after a longer than expected gap from RC1. The gap was caused by two things:

  • Real LifeTM was busy for all the core team members
  • People test RCs, but not betas!

Obviously, the important one here was testing. Thank your everyone who tested RC1!

As a result, a number of important issues were raised after RC1 was released which we had to address. Two key BC-breaking ones involved potential security issues around trusting X-Forwarded headers:

  • #1559 – `Request::getIp()` has been removed
  • #1570 – Inspection of `X-Forwarded-Proto` and `X-Forwarded-Host` headers in `Uri` have been removed

As these are related to the headers, the obvious solution to was to replace with middleware. I created rka-ip-address-middleware and rka-scheme-and-host-detection-middleware to provide the same functionality in a more controlled manner, though I'm sure other alternatives will arise as more people write PSR-7 middleware.

We also made a few improvements. My favourite one is with the way errors are handled when the Accept header is JSON or XML; our response is now in the correct format! This is very important for APIs and it is important to us that out-of-the-box, we are a good API citizen. Note that the error handler's determination of the current accept header is simplistic and so is not exposed to your application. Please use Ryan Szrama's NegotiationMiddleware for your application's needs.

In this cycle we fixed a lot of issues, and are happy with the state of Slim 3. So happy, in fact, that we intend to release final next week unless someone finds a show-stopper!

If you have any interest in Slim or micro-frameworks, please test this release and report any issues that you find. We'd appreciate it!

Writing PSR-7 middleware

Within Slim 3's Request object, there's a method called getIp() which is determines the client's IP address. However it's rather simplistic and potentially risky as it checks the X-Forwarded-For header with no ability to ignore this header or whitelist whether we trust the final proxy in the chain.

Determining the client's IP address is an ideal use-case for middleware as we can inspect the headers in the request and then set an attribute so that middleware further down the chain can use it. Following my rather unimaginative naming, I've called it rka-ip-address-middleware.

However, in this article, I want to look at how easy it is to write useful PSR-7 middleware.

Minimal valid middleware

Writing middleware is really easy, so lets look at the basics of how I built this. You simply need to provide a callable that has this function signature:

function(RequestInterface $request, ResponseInterface $response, callable $next) : ReponseInterface

We are given a request and response object along with the next middleware in the chain and must return a response. Our middleware function must also be a callable itself and this is easy to do with a class by using the __invoke() magic method.

A minimal class that acts as PSR-7 middleware therefore looks something like this:

namespace RKA\Middleware;

use Psr\Http\Message\ServerRequestInterface;
use Psr\Http\Message\ResponseInterface;

class IpAddress
    public function __invoke(
        ServerRequestInterface $request,
        ResponseInterface $response,
        callable $next = null
    ) {
        if ($next) {
            $response = $next($request, $response);
        return $response;

This middleware doesn't actually do anything by itself, but does do the minimum required:

  1. Call the $next middleware in the chain
  2. Return a $response object

Doing something interesting

For a piece of middleware to be useful, it has to do something. Generally, this means that we should look at the $request or $response objects that we have received and do something with them. For this example, we need to look at the request's headers to determine the client's IP address and then store it back into the request for use by subsequent middleware.

Obviously, if there is no subsequent middleware to call, then we don't need to do this work anyway as there's nobody to use it, so our code becomes:

    public function __invoke(
        ServerRequestInterface $request,
        ResponseInterface $response,
        callable $next = null
    ) {
        if (!$next) {
            return $response;

        $ipAddress = $this->determineClientIpAddress($request);

        return $next($request, $response);

(The implementation details of determineClientIpAddress are irrelevant for this discussion.)

We have to store the $ipAddress back into the $request object. The way to do this is to use the server attributes which exists to provide messaging between the middleware in the chain.

We'll call our new attribute "ip_address" and as PSR-7 messages are immutable, we use the withAttribute() method to create a new Request object:

$request = $request->withAttribute('ip_address', $ipAddress);

So our middleware handler is complete:

    public function __invoke(
        ServerRequestInterface $request,
        ResponseInterface $response,
        callable $next = null
    ) {
        if (!$next) {
            return $response;

        $ipAddress = $this->determineClientIpAddress($request);
        $request = $request->withAttribute('ip_address', $ipAddress);

        return $next($request, $response);

Configuring middleware

One nice thing about using a class for your middleware is that it's easy to configure. Let's say that we want the user to be able to pick the name of the attribute to store the IP address into. We can do this quite easily by introducing a property and a constructor:

class IpAddress
    protected $attribName = 'ip_address';

    public function __construct($attribName = null)
        if (!empty($attribName)) {
            $this->attribName = $attribName;

    public function __invoke(
        ServerRequestInterface $request,
        ResponseInterface $response,
        callable $next = null
    ) {
        if (!$next) {
            return $response;

        $ipAddress = $this->determineClientIpAddress($request);
        $request = $request->withAttribute($this->attribName, $ipAddress);

        return $next($request, $response);

Adding middleware to your application

There are a number of PSR-7 middleware-aware frameworks, that have different method names for adding middleware:

  • Slim 3: $app->add(new RKA\Middleware\IpAddress('client_ip'));
  • Radar: $adr->middle(new RKA\Middleware\IpAddress('client_ip'));
  • Expressive: $app->pipe(new RKA\Middleware\IpAddress('client_ip'));

To sum up

Middleware is a powerful way to inspect and act upon HTTP messages in your application. The PSR-7 standard is feature rich enough that with the attributes in ServerRequestInterface it provides a way to add additional information that can be used by subsequent middleware which is very useful and allows for a lot of flexibility in building your applications.

Changing Apigility's auth token expiry

By default, the OAuth 2 token that is generated in an Apigility app expires in 1 hour. Upon expiry, the client is expected to use the refresh token to get a new access token.

You can see this when you authenticate via a POST to /oauth as you get this response back:

    "access_token": "3812aaea7640a2567c66e21e2587450821103552",
    "expires_in": 3600,
    "token_type": "Bearer",
    "scope": null,
    "refresh_token": "72d5df08c971526a4ba7c83ec2a7b92d82d9715b"

If you need longer than 1 hour, then simply add this top level configuration setting:

    'zf-oauth2' => [
        'access_lifetime' => 7200,

The access_lifetime key controls the expiry time and is in seconds, so in this case I've set it to 2 hours.

Render an array based on accept header

I'm currently working on an API using Slim 3 and needed a generic way to render arrays to XML, JSON or HTML based on the Request's Accept header.

This is just good practice. The Accept header is used by a client to specify the media types that it accepts. Therefore if our client would like XML, I'd like to give it XML. Similarly for JSON. I also like to support an HTML rendering on my API if I can as it makes exploration much easier.

This seemed like an ideal thing for a component and so I wrote rka-content-type-renderer! (One day I'll work out how to name things, but for now, if it starts with rka, then it's probably a reusable component!)

It's PSR-7 compliant because if you're going to write something that deals with HTTP nowadays, PSR-7 is the only sensible interface to target. Therefore, this component renders to a PSR-7's Response object's body.

Usage is really simple:

$data = [
    'items' => [
            'name' => 'Alex',
            'is_admin' => true,
            'name' => 'Robin',
            'is_admin' => false,
            'link' => '',
$renderer = new \RKA\ContentTypeRenderer\Renderer();
$response  = $renderer->render($request, $response, $data);
return $response->withStatus(200);

The $request and $response objects must implement PSR-7's RequestInterface and ResponseInterface respectively. This makes it very easy to use within say Radar, Expressive, Slim or any other system that can bridge to PSR-7.

In this case, the output for JSON is:

    "items": [
            "name": "Alex",
            "is_admin": true
            "name": "Robin",
            "is_admin": false,
            "link": "http:\/\/"

& for XML:

<?xml version="1.0"?>

Finally, it will also render the array as an HTML unsigned list if the content-type is text/html which makes examining an API using a web browser very easy and worth doing:

Obviously, in the HTML, we link any links so that the user can explore the API data, simply by clicking.

Hal support

While doing this, I also added support for rendering Nocarrier/Hal objects too as the HAL specification supports both JSON and XML, so it seems logical to send the correct format back to the client based on what they've asked for.

All in all, I've found this to be a useful component and if you have a similar need, then maybe this will help.


Today is Ada Lovelace day which exists to highlight the many amazing and talented women in STEM. I'm bending the rules a little as I'm going to talk about Kathy today though she is not in STEM.

I've never known anyone so excited by what's new in technology.

She has always embraced technology to do her job better, she was one of the first in her office to be assigned a computer (back in the '80s!). Right from the beginning she could see that it would make her life easier and became an expert. Wherever she has worked, she has been the go-to person in the office for getting tech support. After she retired, she has continued to be so interested in computers and what they offer that she qualified to teach adult-education night classes in computing.

Over the years, her enthusiasm for tech has, if anything, increased. She has been an early adopter of every Microsoft operating system from Vista, all the way through to Window 10 as she is excited about what's next. I clearly remember her scorn at the idea of returning to Windows 7 as she was quite clear that the future was forwards, not backwards. She has also found time to investigate OS X and determine whether that operating system would improve her computing life or not. it didn't!

The smartphone revolution hasn't passed her by either. Firstly with Blackberries (for BBM) and now iPhones, Kathy has continued to ensure that she keeps up with the latest in mobile tech. Technology is there to make our lives easier and Kathy embraces it as fast as anyone that I know.

It's very easy to become jaded and take the tech around us for granted. It's also easy to assume that older people have less interest, however Kathy's enthusiasm for what's coming in the future inspires me.

The beginner's guide to rebasing your PR

You've successfully created a PR and it's in the queue to be merged. A maintainer looks at the code and asks you to rebase your PR so that they can merge it.

Say what?

The maintainer means that there have been other code changes on the project since you branched which means that your branch cannot be merged without conflicts and they would like to you to sort this out.

These are the steps you should take.


Read the summary.

1. Update your target branch from upstream

I assume you already have an upstream repository as described in The beginner's guide to contributing to a GitHub project. The target branch you want to update can be found at the top of the PR on the GitHub site.

For example:

Pr title

The target branch in this example is develop, though I see master a lot too.

$ git checkout develop
$ git pull upstream develop && git push origin develop

2. Rebase your branch

The next step is to change to your branch which is the other branch listed in the PR details (feature/validator-result-interface in this example) and then perform a rebase:

$ git checkout feature/validator-result-interface
$ git rebase develop

This will rewind all your commits on this branch and then replay them against the tip of the branch you are rebasing against.

As you have been asked to do this, you'll get conflicts. Don't panic!

$ git status will show you which files are in conflict. For each one, follow this process:

  1. Open in editor and search for "<<<<<<" (that's 6 <) to find the conflict
  2. Inspect and fix so that you end up with the correct text. Remove the lines starting with <<<<<<, ====== and >>>>>>.
  3. Press find-next in your editor to find the next conflict in the file.
  4. Once all conflicts in the file have been fixed, exit your editor
  5. Add this file to the staging index: git add {filename}
  6. Continue until git status shows that all conflicting files have been added to the index

Once all conflicting files are fixed you can continue the rebase:

$ git rebase --continue

3. Push your newly rebased branch to origin

Finally, all you need to do is push your branch back to origin. Note that this will require a force push and you've probably been told to never do such a thing. This is the one exception to that rule because the maintainer asked you to do it.

So go ahead:

$ git push -f origin

It's a good idea to leave a comment on the PR that you've done the rebase and the PR is ready for re-review.

All done

To summarise the steps required:

  1. $ git checkout {target branch}
  2. $ git pull upstream {target branch} && git push origin {target branch}
  3. $ git checkout {victim branch}
  4. $ git rebase {target branch}
  5. Fix conficts and continue rebasing
  6. $ git push -f origin

That's it. Being asked to rebase your PR isn't scary or (usually) difficult as long as you pay attention to what you're doing. However, if you're not fully comfortable with git, then I recommend buying the Git Workbook and working through all the exercises.

The beginner's guide to contributing to a GitHub project

This is a guide to contributing to an open source project that uses GitHub. It's mostly based on how I've seen Zend Framework, Slim Framework and operate. However, this is a general guide so check your project's README for specifics.


Skip to the summary.

Step 1: Set up a working copy on your computer

Firstly you need a local fork of the the project, so go ahead and press the "fork" button in GitHub. This will create a copy of the repository in your own GitHub account and you'll see a note that it's been forked underneath the project name:


Now you need a copy locally, so find the "SSH clone URL" in the right hand column and use that to clone locally using a terminal:

$ git clone

Which will do something like this:


Change into the new project's directory:

$ cd zend-validator

Finally, in this stage, you need to set up a new remote that points to the original project so that you can grab any changes and bring them into your local copy. Firstly clock on the link to the original repository – it's labeled "Forked from" at the top of the GitHub page. This takes you back to the projects main GitHub page, so you can find the "SSH clone URL" and use it to create the new remote, which we'll call upstream.

$ git remote add upstream

You now have two remotes for this project on disk:

  1. origin which points to your GitHub fork of the project. You can read and write to this remote.
  2. upstream which points to the main project's GitHub repository. You can only read from this remote.

Step 2: Do some work

This is the fun bit where you get to contribute to the project. It's usually best to start by fixing a bug that is either annoying you or you've found on the project's issue tracker. If you're looking for a place to start, a lot of projects use the "easy pick" label (or some variation) to indicate that this issue can be addressed by someone new to the project.


The number one rule is to put each piece of work on its own branch. If the project is using git-flow, then it will have both a master and a develop branch. The general rule is that if you are bug fixing, then branch from master and if you are adding a new feature then branch from develop. If the project only has a master branch, the branch from that. Some projects, like Slim use branches named after the version number (2.x and 3.x in Slim's case). In this case, pick the branch that's relevant.

For this example, we'll assume we're fixing a bug in zend-validator, so we branch from master:

$ git checkout master
$ git pull upstream master && git push origin master
$ git checkout -b hotfix/readme-update

Firstly we ensure we're on the master branch. Then the git pull command will sync our local copy with the upstream project and the git push syncs it to our forked GitHub project. Finally we create our new branch. You can name your branch whatever you like, but it helps for it to be meaningful. Including the issue number is usually helpful. If the project uses git-flow as zend-validator does, then there are specific naming conventions where the branch is prefixed with "hotfix/" or "feature/".

Now you can do your work.

Ensure that you only fix the thing you're working on. Do not be tempted to fix some other things that you see along the way as your PR will probably be rejected. Make sure that you commit in logical blocks. Each commit message should be sane. Read Tim Pope's A Note About Git Commit Messages.

Step 3: Create the PR

To create a PR you need to push your branch to the origin remote and then press some buttons on GitHub.

To push a new branch:

$ git push -u origin hotfix/readme-update

This will create the branch on your GitHub project. The -u flag links this branch with the remote one, so that in the future, you can simply type git push origin.

Swap back to the browser and navigate to your fork of the project ( in my case) and you'll see that your new branch is listed at the top with a handy "Compare & pull request" button:

Pr button

Go ahead and press the button!

If you see a yellow box like this:


Click the link which will take you to the project's CONTRIBUTING file and read it! It contains valuable information on how to work with the project's code base and will help you get your contribution accepted.

On this page, ensure that the "base fork" points to the correct repository and branch. Then ensure that you provide a good, succinct title for your pull request and explain why you have created it in the description box. Add any relevant issue numbers if you have them.

Create pr

If you scroll down a bit, you'll see a diff of your changes. Double check that it contains what you expect.

Once you are happy, press the "Create pull request" button and you're done.

Step 4: Review by the maintainers

For your work to be integrated into the project, the maintainers will review your work and either request changes or merge it.

Lorna Mitchell's article Code Reviews: Before You Even Run The Code covers the things that the maintainers will look for, so read it and ensure you've made their lives as easy as possible.

To sum up

That's all there is to it. The fundamentals are:

  1. Fork the project & clone locally.
  2. Create an upstream remote and sync your local copy before you branch.
  3. Branch for each separate piece of work.
  4. Do the work, write good commit messages, and read the CONTRIBUTING file if there is one.
  5. Push to your origin repository.
  6. Create a new PR in GitHub.
  7. Respond to any code review feedback.

If you want to contribute to an open source project, consider!

On blocking ads

There's been a discussion on Twitter this evening about ad-blockers now that Apple has enabled users of iOS to install ad-blocking plugins into their Safari browser. Note that this is not at the OS level and there is no default ad-blocker. The user has to choose to go to the App Store, install an ad-blocker app and then go to Settings->Safari and enable the app.

As we all know, Twitter isn't ideal for conversations requiring even a little bit of nuance, so I'm writing my thoughts here on my blog where I have more room!

Personally, I draw parallels with the older printed medium of a magazine. A magazine has adverts printed on the same physical piece of paper as the article and also comes with lots of separate ads that are inserted into the magazine. I think that reader of the magazine is free to remove the paper inserts without looking at them, put them in the bin and then read the magazine.

Translating to the web, I think that an ad that's served as part of the HTML from the web server is conceptually similar to being printed on the same piece of paper as the advert. Similarly, any ad that is served from a different server and inserted via JavaScript can be considered to be like an insert and may be removed without reading. This argument holds for me as the ad is distinct from the HTML content to such an extent that DNS may not even resolve to the other server or the user's web browser may not support JS (e.g. lynx) and the original article is still provided to the user. As such, an ad-blocker is conceptually the same as a personal assistant that removes the inserts before putting the magazine on the boss' desk. However, with computers, we can all afford a PA if we want one.

Hence, if you're an content producer and want to serve ads on the web, then serve them as HTML with your article and do not use JavaScript. If you do this, then your add will be visible to your readers as content blockers won't catch it.

In this particular case, I see it as no different from the Pop-ups section in Chrome:

Chrome pop-ups

Like ads served from a different domain, I see popups as "inserts", so I'm happy to have the browser not show them. Other people feel that disabling pop-ups interferes with the publisher's right to monetise and so allow all sites to show pop-ups.

It's all about where you draw the line.

Thanks @CalEvans, @codeguy, @Oramius & @JT_Grimes for the civilised discussion. Please feel free to continue the discussion via Twitter or write an article your own blog and ping back!

Simple Ansible file for Z-Ray preview

Recently, Zend made available a Z-Ray Technology Preview which takes the Z-Ray feature of Zend Server and makes it stand-alone.

This is very interesting as it means that I can run it with the PHP 5.6 on Ubuntu 14.04 LTS Vagrant set up that I prefer. I decided to create an Ansible playbook to install Z-Ray into my VM. The Z-Ray instructions are clear enough, so it was simply a case of converting them to a set of YAML steps as who wants to do manual installation nowadays?!

This is what I came up with:


- name: Downloading Z-Ray for PHP 5.6
    url: ""
    dest: "/home/vagrant/zray-php5.6-Ubuntu-14.04-x86_64.tar.gz"

- name: Extract Z-Ray archive
  unarchive: src=/home/vagrant/zray-php5.6-Ubuntu-14.04-x86_64.tar.gz dest=/opt copy=no creates=/opt/zray/INSTALL_ZRAY.TXT

- name: Set Z-Ray ownership
  shell: chown -R vagrant:vagrant /opt/zray

- name: Add the Z-Ray UI virtual host
  file: src=/opt/zray/zray-ui.conf dest=/etc/apache2/sites-available/zray-ui.conf

- name: Enable the Z-Ray UI virtual host
  shell: a2ensite zray-ui.conf

- name: Install Z-Ray PHP extension (Apache)
  file: src=/opt/zray/zray.ini dest=/etc/php5/apache2/conf.d/zray.ini state=link

- name: Install Z-Ray PHP extension (CLI)
  file: src=/opt/zray/zray.ini dest=/etc/php5/cli/conf.d/zray.ini state=link

- name: Link Z-Ray PHP 5.6 extension
  file: src=/opt/zray/lib/ dest=/usr/lib/php5/20131226/ state=link

I've set this up for PHP 5.6 which is what I'm using nowadays. If you're using 5.5, then you need to download zray-php5.5-Ubuntu-14.04-x86_64.tar.gz and the link needs to be to /usr/lib/php5/20121212/

Changing the file ownership to vagrant was important – I couldn't get it work without doing this step and I have no idea why its needed…

The standalone Z-Ray looks to be very similar to the one supplied as part of Zend Server and is equally as helpful in terms of getting a grip on what's going on with your application when developing it.

It has improved since I wrote about before and is even more useful now as it's been improved and has plugins!

With the standalone version of Z-Ray, there's really no excuse to not be using it.