Neos is on the road to PSR-7 compatibility

PSR-7 compatibility within Flow is a complex task that will take a while to complete. This blog post may sheds some light on the complexities and explains our further steps to achieve an entirely PRS-7 compatible framework.

– Written by

With Neos 4.1 / Flow 5.1 (read the release article here) and the following releases up to the next major version of Flow, we are transitioning internal code to be properly compatible with PSR-7 standards. This also affects public interfaces and API methods that you use. To make sure you understand the steps we are taking, I wanted to sketch out what you need to be aware of.
First of all, we want to have a clear separation between the Flow application internals and PSR-7. Currently we see this line at the Dispatcher. Essentially, the HTTP components would only use PSR-7 request and response objects in the future, while the dispatcher and everything below that in the stack (which includes controllers and Fusion) might get syntactic sugar around requests and responses.

To get a grip on these changes we deprecated all non PSR-7 methods in request and response, but please do not act on those deprecations just yet. They are merely a friendly heads up at this point to indicate that changes are coming. This was necessary in order to make sure there is a full understanding of which methods would be affected by these changes. Specifically, we needed to get an idea of methods that are currently API but not compatible with PSR-7 and will need to change in the next major version. In the next release, we will probably make the separation between HTTP components and "internal" request cycle clearer and might remove deprecation from some of the syntactic sugar methods. That is why you shouldn't act on these deprecations just yet. Our plan is to provide requests and responses internally that are fully PSR-7 compatible but at the same time add some useful helper methods to ease your life. Eventually, you will be able to choose to stay fully PSR-7 compatible or to use those helpers if you need them while making your code closer bound to Flow.

One big change we need to facilitate for the next release is making sure that immutable requests and responses (as prescribed by PSR-7) are properly handled in the Flow chain. That is another important change you need to be aware of that we try to get a grip on in a non-breaking way. Currently our chain does NOT properly work with immutable requests and responses so be aware: If you start using PSR-7 methods, you might need to replace the respective request/response instance for example in the controller.

We are aware that the PSR-7 changes upset some very deeply ingrained parts of Flow and might make it necessary for you to change code that worked for years but we hope to quickly follow with PSR-15 support and the respective interoperability with the wider PHP community in terms of requests and responses. This makes it much easier to embed a Flow or Neos instance with other PHP applications for example.