Building and testing the upcoming PHP7

The GoPHP7-ext project aims to ensure that all the known PHP extensions out there work with the upcoming PHP 7. This is non-trivial as some significant changes have occurred in the core PHP engine (related to performance) that mean that extensions need to be updated.

In order to help out (and prepare my own PHP code for PHP 7!), I needed the latest version of PHP7 working in a vagrant VM.

Fortunately Rasmus has created a such a VM called php7dev, so let's start there.

Firstly we make a new directory to work in:

$ mkdir php7dev
$ cd php7dev

Within this directory, we can set up the vagrant vm:

$ vagrant box add rasmus/php7dev
$ vagrant init rasmus/php7dev
$ vagrant up

If you are asked to enter the vagrant@127.0.0.1's password, then it's "vagrant".

We can now work within the VM to Update to the latest PHP 7 and work with extensions:

$ vagrant ssh

PHP versions within the VM

Rasmus' box comes with PHP versions 5.3, 5.4, 5.5, 5.6 and 7. For each of these versions, it provides four variants: release, debug, zts-release and zts-debug. A script, called newphp is provided that allows us to change between them like this:

$ newphp {version number} {type}

Where {version number} is one of: 53, 54, 55, 56, or 7 and {type} is one of: debug, zts or debugzts.

The ones I use are:

$ newphp 7
$ newphp 7 debug

The newphp script sets up PHP in both the CLI and nginx and rather usefully, sets up the correct phpize, so that when you build an extension, it will set it up for the current PHP.

Update PHP 7 to the latest version

PHP 7 is actively in development, so we're going to have to update it regularly to pick up the new changes. Rasmus has helpfully provided a script that, makephp, that does this for us:

$ makephp 70

This will grab the latest source code for PHP 7 and then compile and install both the release and debug versions. The makephp script can also compile zts and other PHP versions – run it without arguments to find out how.

Activate your new PHP build:

  • For PHP 7 release: $ newphp 7
  • For PHP 7 debug: $ newphp 7 debug

Check that the "built" date is correct by viewing the output of php -v

In my case, I see:

PHP 7.0.0-dev (cli) (built: Mar 29 2015 11:33:44) 
Copyright (c) 1997-2015 The PHP Group
Zend Engine v3.0.0-dev, Copyright (c) 1998-2015 Zend Technologies
    with Zend OPcache v7.0.4-dev, Copyright (c) 1999-2015, by Zend Technologies

Building an extension

Building an extension is easy enough. Let's walk through the apfd extension that's in PECL:

$ cd ~/src
$ git clone https://git.php.net/repository/pecl/http/apfd.git
$ cd apfd
$ make distclean; phpize && ./configure && make
$ make test
$ sudo make install

To install for any other PHP versions that you are using, change the current PHP installation via newphp and then repeating these steps.

To install the extension:

  • $ echo "extension=apfd.so" | sudo tee /etc/php7/conf.d/mysql.ini > /dev/null

    (Change php7 to the appropriate directory that's in /etc/ for other PHP versions)
  • $ php -m to check that the module is loaded.

Writing tests and upgrading an extension

As the internal C API has changed significantly, code changes are required to make an extension work on PHP7.

The process for tackling this is to "adopt" an extension on the GoPHP7-ext Extensions catalogue and then read the Compiling and testing extensions article on the GoPHP7-ext site, followed by the Testing Extensions page.

If you want to tackle fixing the C code, then the key changes that need to be made can be found on the Upgrading PHP extensions from PHP5 to NG wiki page.

Testing that your PHP code works on PHP7

To test my PHP code, I share it into the VM. This is done in the Vagrantfile using the config.vm.synced_folder directive.

I want to share my Zend Framework 1 source, so I edit Vagrantfile and after the config.vm.box line, I add this line:

config.vm.synced_folder "/www/zendframework/zf1", "/www/zf1"

This maps my local source code which is at /www/zendframework/zf1 into the VM at the /www/zf1 directory.

Run vagrant reload after changing the Vagrantfile in order to effect the change.

I can now vagrant ssh into the VM, cd /www/zf1 and run my unit tests (after installing PHPUnit, of course). If you want to run a website, then you need to set up a vhost as appropriate within the VM.

Fin

Rasmus has provided a PHP 7 VM that's very easy to keep up to date, so none of us have any excuse and need to be testing our PHP sites with it, reporting regressions and fixing our code!

WordCamp London, 2015

One of my recent goals has been to attend different conferences from the PHP-community-centric ones that I usually attend. I want to expose myself to different ideas, mindsets and communities. To this end, I attended WordCamp London last weekend and had a blast.

Everyone I spoke to was enthusiastic, friendly and welcoming which made for a very pleasant weekend and the selection of talks meant that I managed to learn about WordPress too!

The first day started with a talk by Laura Kalbag and on the potential pitfalls of using free products which harvest user data. I then followed this up by listening to Jack Lenonx talk about how to build themes with the new REST API that's coming to WordPress. This was a very interesting talk that showed how to use React in the browser to load data from the WordPress backend and display it as separate "pages" on the website without having to do a round-trip. Front-end development isn't one of my core skills, so I found this fascinating, though given that my clients sill need IE7 support, I wondered how practical it was…

Discussion of the new REST API was a consistent topic over the conference. The community is clearly very excited by this feature that's coming to WordPress core "soon". I think that being able to access data in a WordPress install via an API that gives back JSON is very useful and could potentially extend the uses of WordPress into the bespoke application world where I am. We'll have to see.

In the afternoon, Bruce Lawson spoke about how do to HTML responsive images with <picture> and the changes to <img> which I understood! As I've noted, front-end isn't really my bag, so Bruce's ability to put across these ideas in such a way that I thought that I could actually implement them was a god-send. We had more API stuff from Joe Hoyle who talked about how to implement your own endpoints in WordPress so that they were accessible to the new REST API and we finished the day with Simon Wheatley discussing how to write URL handlers. These two talks were quite WordPress specific; I found them interesting as background-knowledge about what's going on in a WordPress site.

The London WordCamp is a two day talk, so we did it all again on Sunday. You could certainly tell that it was an early start on the day after a late-night party! First up for me was Kathryn Reeve talking about JavaScript. I really liked this talk as it was easily digestible with a "this is the problem; this is the solution" format which worked really well. I then listened to Lorna Mitchell talk about more modern versions of PHP and what has changed. I've seen the slide before, but the performance improvements from PHP 5.2 to 5.6 are still very impressive!

After lunch, which was excellent both days, there were lightning talks in all three tracks. I went to the dev ones in the big room and we have 5 interesting short talks along with a few questions. I liked these a lot and liked that none ran over their allowed 5 minutes. It ran very smoothly and I learnt about the Codebug OS X client for Xdebug!

The final talk that I attended was the Q&A with three core developers. John, Helen & Mark answered questions from the audience intelligently and honestly. It gave us a good insight into the way the project "thinks" and if you want to help out, they would really appreciate some help with the Trac system!

At this point, I went to catch my train home. My thanks to Jenny for her excitement and enthusiasm which persuaded me to buy a ticket and attend. Hopefully, I'll get to attend more events like this.

Also, I got a new scarf!

RKA 2015 03 23 18 25 22

Run Slim 2 from the command line

If you need to run a Slim Framework 2 application from the command line then you need a separate script from your web-facing index.php. Let's call it bin/run.php:

bin/run.php:

#!/usr/bin/env php
<php

chdir(dirname(__DIR__)); // set directory to root
require 'vendor/autoload.php'; // composer autoload


// convert all the command line arguments into a URL
$argv = $GLOBALS['argv'];
array_shift($GLOBALS['argv']);
$pathInfo = '/' . implode('/', $argv);


// Create our app instance
$app = new Slim\Slim([
    'debug' => false,  // Turn off Slim's own PrettyExceptions
]);

// Set up the environment so that Slim can route
$app->environment = Slim\Environment::mock([
    'PATH_INFO'   => $pathInfo
]);


// CLI-compatible not found error handler
$app->notFound(function () use ($app) {
    $url = $app->environment['PATH_INFO'];
    echo "Error: Cannot route to $url";
    $app->stop();
});

// Format errors for CLI
$app->error(function (\Exception $e) use ($app) {
    echo $e;
    $app->stop();
});

// routes - as per normal - no HTML though!
$app->get('/hello/:name', function ($name) {
    echo "Hello, $name\n";
});

// run!
$app->run();

We set the script to be excutable and then we can then run it like this:

$ bin/run.php hello world

and the output is, as you would expect:

Hello, world

This works by converting the command line parameters into the URL path for Slim to route by imploding $argv with a '/' separator. Slim needs an environment that looks vaguely web-like. This is quite easy to do via the Slim\Environment::mock() method which will set up all the array keys that the framework expects to have access to. It's used for unit test, but also works really well here. All we need to do is set PATH_INFO to our previously created $pathInfo and Slim can now route.

We also need to stop Slim creating HTML errors, so we set our own closures for notFound and error and we're done.

The rest of the file is simply setting up the routes we need and then calling run().

Ally

One thing I've noticed as I try to learn how to become more aware of the diversity issues in my world is that it's really hard for someone to "get it" if they don't "live it". I think this occurs at all levels.

For my position in society, I don't get how it feels to be a black man with the constant assumption that "I'm up to no good". Similarly, I lack that fundamental understanding for other groups of people with fewer advantages than I have.

Walking-the-walk is the only way to become intimately immersed in something and fully understand it. I love listening to music and I know a lot about how it is created, but I'm not a musician.

This is why those who support people who are subject to discrimination and prejudice are called allies. I like this term as it fundamentally understands the difference between someone who lives the situation daily and someone who wants the world to change so that she doesn't have to.

I call myself a feminist and think that I'm an ally. Becoming an ally is a journey. It starts with noticing the discrimination. Common steps along the path are to learn about it, and then change your behaviour. Over time I've learnt to listen to what women tell me without trying to justify to myself or tell them about why they are misunderstanding. I've learnt to shut-up. I've been trying to change my language to be less patronising; I don't joke about the kitchen. At a conference, I start with the assumption that every woman I meet there is a developer and I don't ask if they have children because I assume that we can talk about dev subjects.

I make mistakes often.

Changing habits is hard and this is a journey. I'm moving in the right direction; I would like you to come along with me.

Convert PHP Warnings and notices into fatal errors

Xdebug version 2.3 was released last week and includes a feature improvement that I requested back in 2013! Issue 1004 asked for the ability to halt on warnings and notices and I'm delighted that Derick implemented the feature and that it's now in the general release version.

It works really simply too.

Turn on the feature by setting xdebug.halt_level either in your php.ini or via ini_set():

<php
ini_set('xdebug.halt_level', E_WARNING|E_NOTICE|E_USER_WARNING|E_USER_NOTICE);

Now cause a warning:

<php
echo "Before";
imagecreatefromstring(null); // Don't pass null into imagecreatefromstring()!
echo "After";

The result is that "Before" is displayed and then we get the standard Xdebug notice, but "After" is not displayed as the script is halted on the due to the warning.

Xdebug halt-level example

I used to have a error handler in place solely to do this, but now I don't need it!

The most common use-case I have for it is a warning that occurs during a POSTed request that redirects to another page. Other people are dedicated log-checkers, but I'm not and vastly prefer seeing the big orange box telling what's gone wrong.

As I said, I'm really happy to see this feature; it's worth considering turning on your development set up too!

Git submodules cheat sheet

Note: run these from the top level of your repo.

Clone a repo with submodules:

    $ git clone git@bitbucket.org:akrabat/dotvim.git .vim
    $ git submodule update --init

View status of all submodules:

    $ git submodule status

Update submodules after switching branches:

    $ git submodule update

Add a submodule:

    $ git submodule add git://github.com/tpope/vim-sensible.git bundle/vim-sensible

Update all submodules to latest remote version

    $ git submodule update --remote --merge
    $ git commit -m "Update submodules"

Update a specific submodule to the latest version (explicit method):

    cd bundle/vim-sensible
    git pull origin master
    cd ../..
    git add bundle/vim-sensible
    git commit -m "update vim-sensible"

Remove a submodule:

    edit .gitmodules and remove this submodule's section
    $ git rm --cached bundle/vim-sensible
    $ rm -rf bundle/vim-sensible
    $ git commit -m "Remove vim-sensible"

or

    git submodule deinit bundle/vim-sensible    
    git rm bundle/vim-sensible
    git commit -m "Remove vim-sensible"

Docs:

Routing to a controller with Slim 2

In a couple of projects that I've written using Slim Framework 2, I've found it beneficial to organise my code into controllers with injected dependencies; probably because that's how I'm used to working with ZF2.

To make this easier, I've written an extension to the main Slim class and packaged it into rka-slim-controller which will dynamically instantiate controllers for you for each route.

Defining routes is exactly the same as normal for a Slim controller, except that instead of a closure, you set a string containing the controller's classname and method that you want to be called, separated by a colon:

$app = new \RKA\Slim();
$app->get('/hello/:name', 'App\IndexController:hello');
$app->map('/contact', 'App\ContactController:contact')->via('GET', 'POST');

Behind the scenes, this will create a closure for you that will lazily instantiate the controller class only if this route is matched. It will also try to retrieve the controller via Slim's DI container which allows me to inject relevant dependencies into my controller class.

For example, you could group the functionality for authentication:

$app->get('/login', 'User\AuthController:login')->name('login');
$app->post('/login', 'User\AuthController:postLogin');
$app->get('/logout', 'User\AuthController:logout')->name('logout');

The controller needs to interact with a service class, say UserService, which is injected into the controller:

namespace User;

final class AuthController extends \RKA\AbstractController
{
    private $userService;

    public function __construct(UserService $userService)
    {
        $this->userService = $userService;
    }

    public function login()
    {
        // display login form
    }

    public function postLogin()
    {
        // authentication & redirect
    }

    public function logout()
    {
        // logout functionality
    }
}

In order to inject the service, we define a factory for the DI container and we're done:

$app->container->singleton('User\AuthController', function ($container) {
    return new \User\AuthController($container['UserService']);
});

The nice thing about this approach is that I can group functionality that requires the same dependencies into a single class and be sure that I only instantiate the classes that I need in order to service the request.

Sending test emails from PHP

I've written before about redirecting email while developing using a trap mail script on my development system. Other people also like MailCatcher.

I've recently switched to using a simple PHP script that creates a elm file on disk that can be opened by Apple's Mail client. This solution is much faster as there is no SMTP processing involved.

Adam Royle came up with this solution in his article Setup a testing mail server using PHP on Mac OS X, so thank you Adam!

In summary:

  • Create ~/smtp_out
  • Create ~/smtp_out/smtp_catcher.php with these contents:
    #!/usr/bin/php
    *lt;?php
    
    // create a filename for the emlx file
    list($ms, $time) = explode(' ', microtime());
    $filename = __DIR__ . '/' . date('Y-m-d h.i.s,', $time) . substr($ms,2,3) . '.eml';
    
    // write the email contents to the file
    $email_contents = fopen('php://stdin', 'r');
    $fstat = fstat($email_contents);
    file_put_contents($filename, $fstat['size'] . "\n");
    file_put_contents($filename, $email_contents, FILE_APPEND);
    
    // open up the eml file (using Apple Mail)
    exec('open ' . escapeshellarg($filename));
    
  • Make ~/smtp_out/smtp_catcher.php executable
  • Update php.ini and set:
    sendmail_path = sudo -u rob /Users/rob/smtp_out/smtp_catcher.php

    (Change rob to your username!)

  • Restart Apache
  • Give Apache permission to open Mail, by updating sudoers:
    • sudo visudo
    • Add this to the end:
      %www    ALL=(ALL)   NOPASSWD: /Users/rob/smtp_out/smtp_catcher.php

      (Again, change rob to your username!)

Read Adam's post for the full details on what's going on.

It's a nice solution and I'm liking it!

Customising Bootstrap 3

I'm sure everyone already knows this, but it turns out that you can customise Bootstrap 3 without having to understand Less.

Part of the reason that I didn't realise this is that I run my web browser windows quite small and regularly don't see the main menu of getbootstrap.com as it's hidden being the "three dashes" button. However, there's an option called Customize on it.

This page gives you a massive form where you can configure lots of Bootstrap settings.

For one project, I have tightened the spacing to suit the customer's requirements. This was easily done by changing:

	@grid-gutter-width: 16px
	@modal-inner-padding: 10px
	@modal-title-padding: 10px
	@panel-body-padding: 10px
	@panel-heading-padding: 10px 10px

The Compile and Download button at the bottom rather helpfully puts your configuration file into a gist so you can find it again too.

Dependency injection in Slim framework 2

Slim framework comes with a Dependency Injection container called Set.

The basics

The DIC is accessed via the container property of $app.

To set, you use the set() method:

$app->container->set('foobar', function() { return new Foo\Bar(); } );

If you need a given resource to be shared, then use the singleton method:

$app->container->singleton('foobar', function() { return new Foo\Bar(); } );

And then to retrieve from the container, there are multiple ways to do it:

$fooBar = $app->container->get('foobar');
$fooBar = $app->container['foobar'];
$fooBar = $app->foobar;

The shortcut version ($app->foobar) only works if the key is a valid PHP variable name.

Dependent dependencies

The callback is passed the container instance, you can also retrieve dependencies and use them to configure the object that you are instantiating as shown in this example:

$app = new \Slim\Slim(
    [
        'db.dsn' => 'mysql:host=localhost;dbname=something',
        'db.username' => 'user',
        'db.password' => 'pass',
    ]
);

// Add dependencies
$app->container->singleton('PDO', function ($container) {
    $settings = $container['settings'];
    return new PDO($settings['db.dsn'], $settings['db.username'], $settings['db.password']);
});

$app->container->singleton('UserMapper', function ($container) {
    $pdo = $container['PDO'];
    return new User\UserMapper($pdo);
});

// Routes
$app->get('/', function ($name) use ($app) {
    // (Using the DIC as a service locator here...)
    $userMapper = $app->container['UserMapper'];
    // etc...
});

In this example the '/' route uses an instance of User\Mapper, which requires a PDO object. We therefore add two resources to the container: one for PDO and one for the UserMapper.

Slim uses its own DIC

Note that Slim uses it's own DIC for all its dependencies which means that you can override them. It even uses it for the configuration settings that you pass in to the Slim constructor which is accessible via $app->container['settings'] (or $app->settings).

The classic example is that Slim creates its own instance of Slim\Log and attaches it to the log key in the container. If you wanted to use monolog instead, you can simply do:

$app->container->singleton('log', function () {
    $log = new \Monolog\Logger();
    $log->pushHandler(new \Monolog\Handler\StreamHandler('path/to/log.txt'));
    return $log;
});

We have now replaced Slim's own log system with monolog.

Fin

I know that it's tempting to grab $app directly, but Slim makes is nearly as easy to configure your objects using dependency injection which will make your life much easier in the long-run!