SitePoint PHPQuick Tip: Install Zephir and Phalcon 2 on Vagrant (23.8.2014, 08:25 UTC)

This quick tip will show you how to install Phalcon on a Homestead Improved instance, and will help you get a sample Phalcon app up and running.

The version of Phalcon we’ll be using in this Quick Tip will be 2.0 - a pre-release. If you read this when Phalcon is already in a mature 2.x stage, let us know and we’ll update the post. To install the stable 1.x version, just run sudo apt-get install php5-phalcon and it should work.

Continue reading %Quick Tip: Install Zephir and Phalcon 2 on Vagrant%

SitePoint PHPBuild a New App with Laravel and EmberJS in Vagrant (22.8.2014, 16:00 UTC)

Nowadays, everything is turning into a web application. Even simple websites have a mobile app relying on a REST Api. Web applications are accessible everywhere - on a laptop, desktop, tablet, mobile, and recently on wearable devices like smartwatches. Everything is becoming smaller and faster - front ends are becoming separated from back ends, and only communicate with the server through APIs.

What will we be building?

In these series, we are going to create a photo uploading app. For the front-end, we will use EmberJs and Foundation 5. EmberJs is a front-end framework featuring good integration with REST Apis. Foundation 5 will help us make a fast prototype of our front end. For hosting, we will use Heroku’s free tier (for more information about PHP on Heroku, see here). For the back-end, we will use Laravel. The source code will be available per-part, and in final shape in the final part of this series. You can download the code for part 1 here.

Let’s get started

A good way to start a new project in PHP is using Vagrant. Vagrant gives us the space to experiment a lot from project to project. I can have different PHP versions if I want with Apache for one project, Nginx for another. If something goes bad, I revert all my work and simply vagrant up after that - and I never pollute my host operating system with various other installations.

The easiest way to get started is by following this quick tip, which will take you through a fast installation process and show you a working Laravel app in a matter of minutes so you can start hacking away. If you’re still not convinced why you should use Homestead and Vagrant, see here.

Continue reading %Build a New App with Laravel and EmberJS in Vagrant%

Paul ReinheimerManaged Accounts at WonderProxy (22.8.2014, 01:14 UTC)

I’ve made plenty of mistakes in the code powering WonderProxy, perhaps most famously equating 55 with ∞ for our higher-level accounts (issues with unsigned tinyint playing a close second). Something I think I got right though, was the concept of “managed accounts”. It’s a simple boolean flag on contracts, and when it’s set, the regular account de-activation code is skipped.

Having this flag allows us to handle a few things gracefully:

  • Large value contracts
    By marking them as managed, they don’t expire because someone was on vacation when the account expired. They stay happy, the revenue continues, the expiry date remains accurate.
  • Contracts with tricky billing processes
    The majority of our contracts pay us with PayPal or Stripe. A selection of contracts however have complex hoops involving anti-bribery policies, supplier agreements etc. This gives us some time to get this ironed out.
  • Contracts where we’ve failed to bill well
    We occasionally make mistakes when billing our clients. When we’ve screwed up in the past, this helps ensure that there’s time for everything to resolve amicably.

This doesn’t mean the system has been without flaw. We currently get daily emails reporting on new signups, expired accounts, etc. It mentions all accounts that were not expired because of the managed flag.

Like most features, that was added after mistakes were made: we’d left some managed accounts unpaid for months. With better reporting, though, now, we couldn’t be happier with it.

PHP: Hypertext PreprocessorPHP 5.5.16 is released (22.8.2014, 00:00 UTC)
The PHP Development Team announces the immediate availability of PHP 5.5.16. This release fixes several bugs against PHP 5.5.15 and resolves CVE-2014-3538, CVE-2014-3587, CVE-2014-2497, CVE-2014-5120 and CVE-2014-3597. All PHP users are encouraged to upgrade to this new version.For source downloads of PHP 5.5.16, please visit our downloads page. Windows binaries can be found on The list of changes is recorded in the ChangeLog.
Matthew Weier O'PhinneyTesting Code That Emits Output (21.8.2014, 19:30 UTC)

Here's the scenario: you have code that will emit headers and content, for instance, a front controller. How do you test this?

The answer is remarkably simple, but non-obvious: namespaces.


For this approach to work, the assumptions are:

  • Your code emitting headers and output lives in a namespace other than the global namespace.

That's it. Considering that most PHP code you grab anymore does this, and most coding standards you run across will require this, it's a safe bet that you're already ready. If you're not, go refactor your code now, before continuing; you'll thank me later.

The technique

PHP introduced namespaces in PHP 5.3. Namespaces cover classes, as most of us are well aware, but they also cover constants and functions -- a fact often overlooked, as before 5.6 (releasing next week!), you cannot import them via use statements!

That does not mean they cannot be defined and used, however -- it just means that you need to manually import them, typically via a require or require_once statement. These are usually anathema in libraries, but for testing, they work just fine.

Here's an approach I took recently. I created a file that lives -- this is the important bit, so pay attention -- in the same namespace as the code emitting headers and output. This file defines several functions that live in the global (aka PHP's built-in) namespace, and an accumulator static object I can then use in my tests for assertions. Here's what it looks like:

namespace Some\Project;

abstract class Output
    public static $headers = array();
    public static $body;

    public static function reset()
        self::$headers = array();
        self::$body = null;

function headers_sent()
    return false;

function header($value)
    Output::$headers[] = $value;

function printf($text)
    Output::$body .= $text;

A few notes:

  • headers_sent() always returns false here, as most emitters test for a boolean true value and bail early when that occurs.
  • I used printf() here, as echo cannot be overridden due to being a PHP language construct and not an actual function. As such, if you use this technique, you will have to likely alter your emitter to call printf() instead of echo. The benefits, however, are worth it.
  • I marked Output abstract, to prevent instantiation; it should only be used statically.

I place the above file within my test suite, usually under a "TestAsset" directory adjacent to the test itself; since it contains functions, I'll name the file "Functions.php" as well. This combination typically will prevent it from being autoloaded in any way, as the test directory will often not have autoloading defined, or will be under a separate namespace.

Inside your PHPUnit test suite, then, you would do the following:

namespace SomeTest\Project;

use PHPUnit_Framework_TestCase as TestCase;
use Some\Project\FrontController;
use Some\Project\Output;                 // <-- our Output class from above
require_once __DIR__ . '/TestAsset/Functions.php'; // <-- get our functions

class FrontControllerTest extends TestCase
    public function setUp()
        /* ... */

    public function tearDown()
        /* ... */

From here, you test as normal -- but when you invoke methods that will cause headers or content to emit, you can now test to see what those contain:

public function testEmitsExpectedHeadersAndContent()
    /* ... */

    $this->assertContains('Content-Type: application/json', Output::$headers);
    $json = Output::$body;
    $data = json_decode($json, true);
    $this->assertArrayHasKey('foo', $data);
    $this->assertEquals('bar', $data['foo']);

How it works

Why does this work?

PHP performs some magic when it resolves functions. With classes, it looks for a matching class either in the current namespace, or one that was imported (and potentially aliased); if a match is not found, it stops, and raises an error. With functions, however, it looks first in the current namespace, and if it isn't found, then looks in the global namespace. This last part is key -- it means that if you redefine a function in the current namespace, it will be used in lieu of the original function defined by PHP. This also means that any code operating in the same namespace as the function -- even if defined in another file -- will use that function.

This technique just leverages this fact.

Bradley HoltNortheast PHP Conference 2014 (21.8.2014, 15:58 UTC)

The Northeast PHP Conference 2014 in Cambridge, Massachusetts is just over two weeks away (Saturday, September 6th and Sunday, September 7th). We’ve got a great lineup of talks this year including talks on coding standards, content strategy, unit testing, PHP 5.6 (and beyond), leadership and teamwork, object-oriented programming, profiling (Xdebug and Cachegrind), Internet of Things, code quality, continuous integration, web security, Composer dependency management, Hip Hop Virtual Machine (HHVM), responsive emails, REST APIs, automated web testing (Jenkins and Selenium RC), API first development, and much more. We also have two awesome keynote speakers. Steve Krug, author of “Don’t Make Me Think” and “Rocket Surgery Made Easy”, will be giving the opening keynote. Frances Berriman of Code for America and former front-end development lead for GOV.UK will be delivering the closing keynote.

Important Notes:

Derick RethansOn Backwards Compatibility and not Being Evil (21.8.2014, 15:31 UTC)

On Backwards Compatibility and not Being Evil

This is a repost of an email I sent to PHP internals as a reply to:

And since you're targetting[sic] the next major release, BC isn't an issue.

This sort of blanket statements that "Backwards Compatibility is not an issue" with a new major version is extremely unwarranted. Extreme care should be taken when deciding to break Backwards Compatibility. It should not be "oh we have a major new version so we can break all the things"™.

There are two main types of breaking Backwards Compatibility:

  1. The obvious case where running things trough php -l instantly tells you your code no longer works. Bugs like the two default cases, fall in this category. I have no problem with this, as it's very easy to spot the difference (In the case of allowing multiple "default" cases, it's a fricking bug fix too).

  2. Subtle changes in how PHP behaves. There is large amount of those things currently under discussion. There is the nearly undetectable change of the "Uniform Variable Syntax", that I already wrote about, the current discussion on "Binary String Comparison", and now changing the behaviour on << and >> in a subtle way. These changes are not okay, because they are nearly impossible to test for.

    Changes that are so difficult to detect, mean that our users need to re-audit and check their whole code base. It makes people not want to upgrade to a newer version as there would be more overhead than gains. Heck, even changing the $ in front of variables to £ is a better change, as it's immediately apparent that stuff changed. And you can't get away with "But Symfony and ZendFramework don't use this" either, as there is so much code out there

As I said, the first type isn't much of a problem, as it's easy to find what causes such Backwards Compatibility break, but the second type is what causes our users an enormous amount of frustration. Which then results in a lot slower adoption rate—if they bother upgrading at all. Computer Science "purity" reasons to "make things better" have little to no meaning for PHP, as it's clearly not designed in the first place.

Can I please urge people to not take Backwards Compatibility issues so lightly. Please think really careful when you suggest to break Backwards Compatibility, it should only be considered if there is a real and important reason to do so. Changing binary comparison is not one of those, changing behaviour for everybody regarding << and >> is not one of those, and subtle changes to what syntax means is certainly not one of them.

Don't be Evil

Brandon SavagePHP 5.6 is coming next week (21.8.2014, 13:46 UTC)
According to, PHP 5.6 will be released next Thursday. This is an incremental release of the PHP language, offering a few new features. Yet even though this release is relatively small in features, the features included are powerful and will change the way each one of us develops. PHP 5.6 is easy to install, […]
Liip Integrate Varnish and Nginx into PHP applications with FOSHttpCache (21.8.2014, 12:23 UTC)

Earlier this week, I released version 1.0 of the caching proxy library FOSHttpCache and the Symfony2 FOSHttpCacheBundle. The library implements talking to caching proxies to invalidate cache, the bundle integrates the library into Symfony2 and adds other caching related features to Symfony2.

The library is all about talking to caching proxies to do active cache invalidation. It also provides the foundations for the User Context caching scheme that allows to share caches that do not depend on individual credentials but common roles or permissions of users.

The Symfony2 bundle FOSHttpCacheBundle integrates those features into Symfony2, using the configuration, providing annotations for invalidation, invalidating by Symfony2 routes and a default user context implementation based on the user roles. On top of this, the bundle allows to configure caching headers on request patterns, similar to the Symfony2 security component, and adds support for cache tagging.

Both library and bundle are well documented and thoroughly tested. The testing setup includes integration tests running a Varnish or Nginx instance. The test cases can also be reused for functional testing in your applications.

The cache header rules concept has been ported over from the LiipCacheControlBundle which is now deprecated. A migration guide is provided to update your projects.

Development of this started when I met David de Boer from driebit at last years SymfonyCon in Warsaw. He presented DriebitHttpCacheBundle which started from the cache invalidation, while the LiipCacheControlBundle started at caching headers. But both bundles had started to overlap already. We decided to build one common codebase that does both tasks. After more than half a year of writing better tests, refactoring and properly documenting, the code is now in a very good state. Besides David, a shoutout has to go to Joel Wurtz for contributing the user context implementation, Simone Fumagalli for the Nginx integration, Christophe Coevoet (stof) for his valuable feedback and reviews, and all the other contributors of the library and the bundle (some of those coming from the LiipCacheControlBundle git history).

Symfony CMF1.2 first release candidate (21.8.2014, 04:00 UTC)

It is time for another update. The release process for 1.2 has begun with RC1 releases of all of our components and bundles. We expect final releases in the next few weeks, certainly before the end of Q3. Note that the documentation on is still for 1.1, as currently we can unfortunately only render a single version. So please check the dev branch on the symfony-cmf-docs repository to see the updated docs. That being said, as the main code development efforts are now complete, we will now focus our energy on fixing any bugs reported for these releases as well as documentation. So expect to see much better documentation to be added on the dev branch for all the new features and changed.

However, the biggest new feature in this release is that we finally are preparing a stable release of RoutingAutoBundle. This Bundle automates the creation of routes based on rules. For example the Bundle can automatically create a route to any new content that was created. Or it can be used to automatically create redirect routes whenever a route is moved. Also we moved everything to use PSR-4 autoloading, which will likely not have a big impact for development except for shorter directory names.

In parallel we are also working on improvements for Jackalope and PHPCR ODM. Especially Jackalope Doctrine DBAL as well as PHPCR ODM will see major performance improvements with the next releases. PHPCR ODM also has many improvements related to events. If you want to keep up with work on PHPCR related topics we recommend you keep an eye on the news section on the newly designed PHPCR homepage.

LinksRSS 0.92   RDF 1.
Atom Feed   100% Popoon
PHP5 powered   PEAR
ButtonsPlanet PHP   Planet PHP
Planet PHP