Skip to content

Instantly share code, notes, and snippets.

Working on a transition plan

Matthew Weier O'Phinney weierophinney

Working on a transition plan
Block or report user

Report or block weierophinney

Hide content and notifications from this user.

Learn more about blocking users

Contact Support about this user’s behavior.

Learn more about reporting abuse

Report abuse
View GitHub Profile
weierophinney / Dockerfile
Created Nov 1, 2018
Getting ext-tidy to work on alpine-based PHP images
View Dockerfile
FROM php:7.2-cli-alpine3.8
# Compile-time dependencies
RUN echo '' >> /etc/apk/repositories
RUN apk update && \
apk add --no-cache 'tidyhtml-dev==5.2.0-r1'
# Install the extension
weierophinney / UserCollection.php
Created Jun 5, 2018
Example of casting an array of entities to a collection
View UserCollection.php
namespace App\Entity;
use ArrayIterator;
class UserCollection extends ArrayIterator
weierophinney / index.html
Created May 31, 2018
Prototype for auto-populating the component dropdown and making it searchable.
View index.html
<!doctype html>
<html lang="en">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<meta charset="utf-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width, initial-scale=1, shrink-to-fit=no">
<title>Choices example</title>
<link rel="stylesheet" href="" integrity="sha384-WskhaSGFgHYWDcbwN70/dfYBj47jz9qbsMId/iRN3ewGhXQFZCSftd1LZCfmhktB" crossorigin="anonymous">
weierophinney / RemoveDevPrefixMiddleware.php
Created Sep 14, 2017
Demonstrates stripping a path prefix prior to routing.
View RemoveDevPrefixMiddleware.php
use Interop\Http\ServerMiddleware\DelegateInterface;
use Interop\Http\ServerMiddleware\MiddlewareInterface;
use Psr\Http\Message\ServerRequestInterface;
class RemoveDevPrefixMiddleware implements MiddlewareInterface
private $prefix;
weierophinney / Module.php
Created Aug 17, 2017
Demonstrates a zend-mvc listener that short-circuits, and how to register it
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:

weierophinney /
Last active Oct 26, 2016
Proposal to implement PSR-15 in zend-stratigility

[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:

weierophinney /
Created Sep 22, 2016
Proposal to remove request, response decorators from zend-stratigility v2.

[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.

weierophinney /
Last active Sep 22, 2016
Idea for removing the final handler concept from Stratigility

[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.
You can’t perform that action at this time.