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
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.
Today, 20 years ago, Rasmus Lerdorf publicly released PHP. Ben Ramsey has issued a call-to-action for people to blog the event and the impact PHP has had on their lives and careers; this is my entry.
I'm pleased to announce that as of 22:00 CDT on 18 May 2015, http://www.php-fig.org/psr/psr-7 PSR-7 (HTTP Message Interfaces) has been accepted!
Today we accomplished one of the major goals towards Zend Framework 3: splitting the various components into their own repositories. This proved to be a huge challenge, due to the amount of history in our repository (the git repository has history going back to 2009, around the time ZF 1.8 was released!), and the goals we had for what component repositories should look like. This is the story of how we made it happen.
PSR-7 is now accepted!!!
~~I'm still hearing some grumbles both of "simplify!" and "not far enough!" so I'm writing this posts to demonstrate usage of the currently published interfaces, and to illustrate both the ease of use and the completeness and robustness they offer.~~
First, though I want to clarify what PSR-7 is attempting.
As I've surveyed the successes and failures of ZF1 and ZF2, I've started considering how we can address usability: how do we make the framework more approachable?
One concept I've been researching a ton lately is middleware. Middleware exists in a mature form in Ruby (via Rack), Python (via WSGI), and Node (via Connect / ExpressJS); just about every language has some exemplar. Even PHP has some examples already, in StackPHP and Slim Framework.
The basic concept of middleware can be summed up in a single method signature:
function (request, response) { }
The idea is that objects, hashes, or structs representing the HTTP request and HTTP response are passed to a callable, which does something with them. You compose these in a number of ways to build an application.
This is the final in a series of eight posts detailing tips on deploying to Zend Server. The previous post in the series detailed using the Zend Server SDK to deploy your Zend Server deployment packages (ZPKs) from the command line.
Today, I'll detail how I automate deployment with zf-deploy and zs-client (the Zend Server SDK), and wrap up the series with some closing thoughts.
This is the seventh in a series of eight posts detailing tips on deploying to Zend Server. The previous post in the series detailed setting up and clearing page caching.
Today, I'm sharing how to use the Zend Server SDK to deploy your Zend Server deployment packages (ZPKs) from the command line.
This is the sixth in a series of eight posts detailing tips on deploying to Zend Server. The previous post in the series detailed setting job script status codes.
Today, I'm sharing some tips around setting up page caching, and jobs for clearing the Zend Server page cache.