View RemoveDevPrefixMiddleware.php
use Interop\Http\ServerMiddleware\DelegateInterface;
use Interop\Http\ServerMiddleware\MiddlewareInterface;
use Psr\Http\Message\ServerRequestInterface;
class RemoveDevPrefixMiddleware implements MiddlewareInterface
private $prefix;
View Module.php
// In a module class somewhere...
use Zend\EventManager\LazyListener;
use Zend\Mvc\MvcEvent;
class Module
public function onBootstrap(MvcEvent $e)

[RFC] zend-expressive-router (and related) changes for Expressive 1.1.

Proposed zend-expressive-router changes include:

  • Adding a $path parameter to RouteResult::fromRouteMatch().

    What if instead we were to add a new static method, RouteResult::fromRoute(), and a new instance method, RouteResult::getRoute()? (as I have suggested in zendframework/zend-expressive#398)? This would allow consumers to then pull the path from the Route instead, and provide access to the path, name, allowed methods, options, etc. (e.g., $result->getRoute()->getPath())

    This could even be done in a new 1.3.0 minor release; users who depend on that new feature would need to update their project to pin to the new minor release or later; otherwise, everything continues working as normal.


[Expressive] RFC: Programmatic pipelines

When we originally created the API for Expressive, it was programmatic:

We had pipelines:


[zend-stratigility] RFC: Implement PSR-15

PSR-15 proposes a standard around PHP middleware that consumes PSR-7 HTTP message instances. One goal of the standard is to create interfaces that can co-exist with existing projects, which would allow adoption without necessarily leading to backwards compatibility breaks.

The most recent proposal has the following interfaces:


[zend-stratigility] RFC: Remove request, response decorators

Currently, we have a Zend\Stratigility\Http namespace that contains:

  • Request, a decorator for PSR-7 requests that provides access to the original request instance at server invocation.
  • ResponseInterface, which provides the methods write(), end(), and isComplete().
  • Response, which decorates a PSR-7 response to provide access to the original response instance at server invocation, and implements the above ResponseInterface.

These are used internally specifically in the FinalHandler, but nowhere else. If the proposal to remove the FinalHandler and error middleware is approved, there is no longer an internal use case for them.


[zend-stratigility] RFC: Remove FinalHandler, ErrorMiddlewareInterface

The FinalHandler concept in zend-stratigility comes essentially whole cloth from Sencha Connect (with the primary difference being the arguments passed to it). It's unique in the PHP ecosystem, and provided an early, catchall way to handle both 404 conditions and server errors.

However, it also introduces some cognitive overhead, does not play well with middleware-based error handling, and can lead to unexpected results due to how pipeline ordering works once an error handler is invoked.

The idea I present is to do the following:

  • Remove the FinalHandler class entirely.
  • Rename the $out argument to $next in both MiddlewareInterface and MiddlewarePipe::__invoke(); additionally, make it required.
// config/autoload/
$provider = new Zend\Db\ConfigProvider();
return $provider();
use Zend\Expressive\Container\ApplicationFactory;
use Zend\Expressive\Helper;
return [
'middleware_pipeline' => [
'always' => [
'middleware' => [

I received this comment on twitter earlier today, in response to

"recommended for literally years developers not [lazy load]" - official Zend certification taught it depends on situation!

To this, I have two responses.

When was the certification created?

The certification was created within the first year of the first ZF2 stable release, and is current to ZF 2.2.0. That release was almost three years ago,