If you're new to PHP or are working to enhance your skills, chances are you've at least heard of the PHP-FIG and the several PSRs that it has released to help provide structure around common functionality. In this article from StarTutorial they walk you through some of the basics of the more widely adopted PSRs including PSR-0/PSR-4 and PSR-3/PSR-4.

Prior to PHP Standards Recommendation (PSR), there were no truly uniformed standards for writing PHP code. For instance, for coding style, some people preferred Zend Framework Coding Standard, and some liked PEAR Coding Standards, and still others chose to create their own naming conventions and coding style.

[...] At the time of this writing, there are six accepted PSRs: two of them are about autoloading, two of them are related to PHP coding style and the remaining are about interfaces. In this chapter, we will discuss each PSR briefly. The purpose of this chapter is to introduce you to the ideas of PSRs. For further details on each one, the respective link are provided.

The post then goes through each of the major PSRs, describing them and providing code examples where relevant:

• PSR-0 & PSR-4 for autoloading
• PSR-1 & PSR-2 for coding standards
• PSR-3 for logging interfaces
• PSR-7 for HTTP message stricture

The post finishes with links to each of the PSRs on the PHP-GIF site for more information.

Alejandro Celaya has posted a new tutorial on his site showing how you can customized the "not found" and "not allowed" responses in a Zend Expressive v2 application based on the needs of your application.

Sometimes the nature of an application requires you to change the default framework's way to structure error responses (like 404 and 405).

On this article I'm going to explain how to customize those responses when working with Zend Expressive 2. [...] In Expressive 1, error handling was different. [...] In expressive 2, the error handler is gone, replaced by a middleware which catches exceptions and lets you generate error responses.

He notes that this new middleware approach (moving away from the error handler) doesn't deal with 404 and 405 errors anymore, they've been split out into other functionality. As these other middleware options allow for a custom PSR-7 response object to be injected, he sets up two "delegates" that will more correctly handle the response. He includes the examples code for these and shows how to hook them into the current Expressive execution flow.

On of the standards that have come out of the PHP-FIG (PHP Framework Interoperability Group) in the past few years has been PSR-7, a standards definition for working with HTTP requests and responses as PHP objects. While those that have worked with most of the PHP frameworks out there may be familiar with the concept, it can be confusing if you're just getting started with the idea. In this post on the Dotkernel site they introduce PSR-7, talking about its goals and what it defines to help bring everyone on the same page for HTTP requests.

PSR-7 is a set of common interfaces defined by PHP Framework Interop Group. These interfaces are representing HTTP messages, and URIs for use when communicating trough HTTP.

Any web application using this set of interfaces is a PSR-7 application.

They start off by defining (and linking to) the different interfaces involved in the PSR-7 specification (the spec doesn't define functionality, only the structure). From there the tutorial uses the Zend Diactoros component to illustrate an implementation of the PSR-7 structure. They cover two of the main tasks when working with HTTP requests/responses: working with the headers and fetching/writing to the body.

Matthew Weier O'Phinney, lead developer on the Zend Framework project, has written up a new post for his site showing how to use anonymous classes to write middleware for your applications (several frameworks support the concept of middleware these days).

I faced an interesting question recently with regards to middleware: What happens when we go from a convention-based to a contract-based approach when programming?

Convention-based approaches usually allow for duck-typing; with middleware, it means you can write PHP callables - usually closures - and just expect them to work.

Contract-based approaches use interfaces. I think you can see where this is going.

He starts off looking at some of the currently popular methods for creating middleware basic them off of either the PSR-7 standard or the proposed PSR-15 HTTP middleware, each with code examples to illustrate. The post then gets to the point with a look at anonymous class-based middleware and some of the advantages they provide. He refactors both a PSR-7 middleware and a closure-based middleware over to PSR-15 using this method.

Alejandro Celaya has posted a new tutorial to his site covering the handling of PUT requests in PSR-7 applications for file uploads via middleware.

It has been a long time since I first realized that handling file uploads in non-POST requests (like PUT) wasn't an easy task. One could assume the $_FILES array should be populated regardless the HTTP verb, but actually, PHP doesn't do it on its own.

After a long time wanting to find a solution to this problem, I've finally dedicated the time to get something functional, that allows file uploads to be transparently handled regardless the HTTP verb (it works the same way in POST, PUT and PATCH requests).

Since nowadays I try to work with psr-7/middleware based applications, I have created a Zend Expressive app that registers a middleware capable of parsing a multipart/form-data request body, populating the request's uploaded files array and parsed body array. This way, you can call $request->getUploadedFiles() or $request->getParsedBody() in any PUT or PATCH action, the same way you would do in a POST action.

His example application shows a simple HTML form that, when submitted, changes the HTTP request type based on a radio option selected at the bottom. He walks through the steps that the application takes to handle the upload via this middleware that makes it possible to work with the body of the PUT the same way as other requests. He goes through each part of the code that's required to make the middleware flow work and finishes up the post looking at a few other things to consider (like opting for POST over PUT for file uploads).

Matthew Weier O'Phinney has written up a new post for his site covering PSR-7 request and method utilities and a package that contains some handy tools to help with just that.

Some time ago, a few folks floated the idea of creating a utility repository related to the PSR-7 psr/http-message package, but containing some useful bits such as constants for HTTP request methods and status codes.

Six months ago, we released it... but didn't publicize it. I remembered that fact today while writing some unit tests that were utilizing the package, and thought I'd finally write it up.

The package is fig/http-message-util, and is available via Composer and Packagist.

He goes on to describe the two interfaces it provides (RequestMethod and StatusCode) and what they're designed to help with. He includes an example of middleware written using these interfaces, defining allowed methods and returning a "method not allowed" status code - based on a constant - in the response message object. He ends the post with two quick points to note in this example: how the interfaces are used and his use of aliases to make using the interfaces just a bit shorter.

As a sort of follow up to their previous article showing the use of the zend-json-server component to create an XML-RPC service, the Zend blog is back with a different take on the same functionality, this time using zend-xmlrpc.

zend-xmlrpc provides a full-featured XML-RPC client and server implementation. XML-RPC is a Remote Procedure Call protocol using HTTP as the transport and XML for encoding the requests and responses.

[...] Each XML-RPC request consists of a method call, which names the procedure (methodName) to call, along with its parameters. The server then returns a response, the value returned by the procedure.

The post walks you through an example request/response flow and some of the value types allowed in the XML-RPC structure. From there it's on to the code, creating the simple server and an "add" method on the "calculator" service. The post then covers how to integrate this setup with the zend-mvc component and an application based on it. It finishes up with an example of the same kind of functionality only applied in a PSR-7 middleware instead.

Fred Emmott has a new post to his site sharing some of his experience with creating a "greenfield" project in Hack, the language Facebook developed to work with its HHVM runtime for PHP.

Until late 2015, the Hack and HHVM documentation site was a fork of PHP's own documentation site. This had many shortcomings, and ultimately we decided that the best approach would be something custom. As most of the public Hack code at that point was toy examples, we decided to also make the site itself open, and start investigating the greenfield problems.

There are 3 basic approaches to 'library code' in Hack if there isn't already a Hack version:

• Use a PHP library, without typechecker support
• Use a PHP library, and add HHI files so that Hack understands it
• Write something new

The Hack/HHVM site uses a mix of all three, though mostly #2 and #3.

He talks some about using plain PHP libraries in Hack projects and how you won't get the full benefit of Hack's features without some of the type-checking enforced (sometimes required to get some libraries working). Following this he covers the integration of three projects/structures, changed a bit for supporting Hack: FastRoute, PHPUnit and the things based on the PSR-7 request/response structure. He wraps up the post talking about writing "something new" and things to consider to make its APIs more "Hack-like".

The SitePoint PHP blog has a new tutorial posted hoping to demystify some of the confusion around HTTP and PSR-7, a standard from the PHP-FIG group around the handling of request and response messages in PHP applications.

The PHP Framework Interoperability Group (PHP-FIG) has relatively recently approved another proposal, the PSR-7: HTTP Messages Interface. The document crystallizes HTTP messages into 7 interfaces which a PHP library should implement if they subscribe to the specification. In PSR-7 By Example, Matthew Weier O’Phinney, editor of the PSR, gives an interesting overview of the specification. So what is it?

They start with the HTTP side of things, briefly covering what HTTP messages are and the format they're transmitted in. Using some example curl requests they show requests and responses involving normal responses, redirects and how they're broken down into objects implementing the MessageInterface, RequestInterface and ResponseInterface. They outline the PSR-7 specification in a UML diagram and talk about some of the challenges associated with PSR-7's handling (including the use of immutable objects and how it fits in with middleware handling).

The post ends with a listing of a few of the frameworks/libraries that already make use of the PSR-7 structure including Symfony, Slim, Guzzle and the HTTPlug client.

In this recent post to his site Robert Basic shares some of his experience integrating the Tactician command bus library into a Zend Expressive-based application.

I spent some time connecting the dots last week, so I decided to put together an example on how to get started with using Tactician in a Zend Expressive application. The example itself is not really useful, but it does show how to setup the dependencies and get started with these two libraries.

He briefly introduces the two pieces of technology here and then "dives in" immediately to the integration. He shows how, using the Zend Expressive skeleton application, to expand on the default "ping" endpoint and add in the Tactician library (and another library that makes it easily integrate with the DI container). He updates how the "ping" action is made in the routing, making it go through a factory. He then brings Tactician in, setting up the command bus and a simple "ping" command for the bus to use in handling the requests to the /api/ping endpoint. Complete code and explanations of each part are included in the tutorial to help you follow along.