Enrico just returned from phpDay, where he spoke about Expressive and the upcoming Zend Framework 3. One piece of feedback he brought back had to do with how people perceive they should be building Expressive applications: many think, based on our examples, that it's completely configuration driven!

As it turns out, this is far from the truth; we developed our API to mimic that of traditional microframeworks, and then built a configuration layer on top of that to allow making substitutions. However, it's not only possible, but quite fun, to mix and match the two ideas!

A month or two ago, we pushed a new release of zend-mvc that provides a number of forwards-compatibility features to help users prepare their applications for the upcoming v3 release.

One of those was, evidently, quite controversial: in v3, zend-servicemanager no longer defines the ServiceLocatorAwareInterface, and this particular release of zend-mvc raises deprecation notices when you attempt to inject a service locator into application services, or pull a service locator within your controllers.

The arguments go something like this:

• "Dependency injection is too hard to understand!"
• "This feature simplifies development!"
• "If this is so bad, why was it in there in the first place?"

These are usually followed by folks:

• saying they'll switch frameworks (okay, I guess?);
• asking for re-instatement of the feature (um, no);
• asking for removal of the deprecation notices (why? so you can delay your pain until upgrading, when you'll ask for re-instatement of the feature?); or
• asking for a justification of the change.

So, I've decided to do the last, justify the change, which addresses the reasons why we won't do the middle two, and addresses why the assumptions and assertions about ServiceLocatorAware's usefulness are mostly misguided.

I've been intending to play with React for some time, but, for one reason or another, kept putting it off. This past week, I carved some time finally to experiment with it, and, specifically, to determine if serving PSR-7 middleware was possible.

One of the final tasks in prepping for the Expressive 1.0 release was setting up the documentation site. We'd decided to use GitHub Pages for this, and we wanted to automate builds so that as we push to the master branch, documentation is deployed.

The process turned out both simple and bewilderingly difficult. This post is intended to help others in the same situation.

A few hours ago, we pushed Expressive 1.0.

This is a huge milestone for the ZF3 initiative; I've even called it the cornerstone. It signals a huge shift in direction for the project, returning to its roots as a component library. Expressive itself, however, also signals the future of PHP applications we envision: composed of layered, single-purpose PSR-7 middleware.

For a variety of reasons, I've been working on a utility that is best distributed via PHAR file. As has been noted by others (archive.is link, due to lack of availability of original site), PHAR distribution, while useful, is not without security concerns, and I decided to investigate how to securely create, distribute, and update PHAR utilities as part of this exercise.

This is an account of my journey, as well as concrete steps you can take to secure your own PHAR downloads.

10 years ago, as I write this, I was on a plane from Burlington, VT, to San Jose, CA, where I'd be starting work at Zend Technologies the next day as a PHP Developer.

For the Zend Framework component repositories, we occasionally need to backport changes to the 2.4 LTS releases. This requires checking out a branch based off the last LTS tag, applying patches (often with edits to translate PHP 5.5 syntax to PHP 5.3), and running tests against PHP 5.3 and 5.4.

Of course, to run the tests, you need the correct set of dependencies installed. If you have any component dependencies, that means running a composer update to ensure that you get the 2.4 versions of those components.

And that's where my story begins.

Yesterday, a question tagged #psr7 on Twitter caught my eye:

#psr7 Request::getHeader($name) return array of single string instead of strings in #Slim3? cc: @codeguy pic.twitter.com/ifA9hCKAPs

@feryardiant (tweet)

The image linked provides the following details:

When I call $request->getHeader('Accept') for example, I was expected that I'll get something like this:

Array(
    [0] => text/html,
    [1] => application/xhtml+xml,
    [2] => application/xml,
)

but, in reallity I got this:

Array(
    [0] => text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
)

Is it correct?

In this post, I'll explain why the behavior observed is correct, as well as shed a light on a few details of header handling in PSR-7.